Starting System with Disk Stores

When you shut down a member that persists data, the data remains in the disk store files, available to be reloaded when the member starts up again. Keep in mind that peer clients are dependent on locators or data store members to persist data, as they cannot persist data on their own.

Shutdown: Most Recent Data from the Last Run

The following sections explain what happens during startup and shutdown:

If more than one member has the same persistent table or queue, the last member to exit leaves the most up-to-date data on disk.

GemFire XD stores information on member exit order in the disk stores, so it can start your members with the most recent data set:
  • For a persistent replicated table, the last member to exit leaves the most recent data on disk.
  • For a partitioned table, where the data is split into buckets, the last member to exist that hosts a particular bucket leaves the most recent data on disk for that bucket.
Note: Peer clients rely on data stores for persistence. See Peer Client Considerations for Persistent Data.

Startup Process

When you start a member with disk stores, the stores are loaded back into memory to initialize the member’s table data.

Note: Peer clients rely on data stores for persistence. See Peer Client Considerations for Persistent Data.
If the member does not hold all of the most recent data in the system:
  1. The member does not immediately join the server group, but waits for the member with the most recent data.
    If your log level is info or below, the system provides messaging about the wait. Here, the disk store for hostA has the most recent data and the hostB member is waiting for it.
    [info 2010/04/09 10:48:26.039 PDT CacheRunner <main> tid=0x1] 	
    Region /persistent_PR initialized with data from 
    backupDirectory created at timestamp 1270834766425 version 0 is 	
    waiting for the data previously hosted at 
    backupDirectory created at timestamp 1270834763353 version 0] to 
    be available

    During normal startup you can expect to see some waiting messages.

  2. When the most recent data is available, the system updates the local tables as needed, logs a message like this, and continues with startup.
    [info 2010/04/09 10:52:13.010 PDT CacheRunner <main> tid=0x1]    
       Done waiting for the remote data to be available.
Each member’s persistent tables load and go online as quickly as possible, not waiting unnecessarily for other members to complete. For performance reasons, several actions are taken asynchronously:
  • If both primary and secondary buckets are persisted, data is made available when the primary buckets are loaded without waiting for the secondary buckets to load. The secondary buckets will load asynchronously.
  • Entry keys first get loaded from the key file if this file is available (see information about the krf file in Disk Store File Names and Extensions). Once all keys are loaded, GemFire XD loads the entry values asynchronously. If a value is requested before it is loaded, the value will immediately be fetched from the disk store.

Example Startup Scenarios