You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Anthony Baker (JIRA)" <ji...@apache.org> on 2019/02/08 18:46:00 UTC

[jira] [Commented] (GEODE-6361) Serve persisted region immediately after nodes restart even if indexed.

    [ https://issues.apache.org/jira/browse/GEODE-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763814#comment-16763814 ] 

Anthony Baker commented on GEODE-6361:
--------------------------------------

[~phicer] Thanks for the improvement suggestions.  For a 24x7 system, would it help to deploy multiple geode clusters connected via WAN?

> Serve persisted region immediately after nodes restart even if indexed.
> -----------------------------------------------------------------------
>
>                 Key: GEODE-6361
>                 URL: https://issues.apache.org/jira/browse/GEODE-6361
>             Project: Geode
>          Issue Type: Improvement
>          Components: persistence, regions
>            Reporter: Philippe CEROU
>            Priority: Major
>             Fix For: 1.8.0
>
>
> Hi,
> If we create a region with indexes and we insert million rows inside a full restart of the product is very long, the cluster come back quickly but the region is back after minutes (Ex : 16 minutes for a 30 nodes with 200 000 000 rows with 3 indexes) because indexes are rebuild at restart before servicing the region.
> If we create and serve a non indexed region we can stop/start quickly, if we create indexes after creating/servicing a region with a lot of rows there is no service freeze.
> Could it be possible to have a parameter that say to nodes we do not want anymore indexes on a specific region at restart, just keep their definition, and then index back again after region is serviced like when we create indexes ?
> On our need it is not a big problem if indexes are not there at restart, it won't help but it could be acceptable, because in our solution we need to be UP 24/24 to serve DATA acquisition/writing, reads/selects are for few on demand consumption which can be long in case of DRP (The time indexes are back).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)