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
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.
When you start a member with disk stores, the stores are loaded back
into memory to initialize the member’s table data.
If the member does not hold all of the most recent data in the system:
- The member does not
immediately join the server group, but waits for the member with the most
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
During normal startup you can expect to see some waiting messages.
- 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
- Stop order for a
replicated, persistent table:
- Member A (MA) exits
first, leaving persisted data on disk for TableP.
- Member B (MB)
continues to run DML operations on TableP, which update its disk store and
leaves the disk store for MA in a stale condition.
- MB exits, leaving the
most up-to-date data on disk for Table P.
- Restart order Scenario 1:
- MB is started first.
GemFire XD recognizes MB as having the most recent disk data for TableP and
initializes it from disk.
- MA is started,
recovers its data from disk, and updates it as needed from the data in MB.
- Restart order Scenario 2:
- MA is started first.
GemFire XD recognizes that MA does not have the most recent disk store data and
waits for MB to start before creating TableP in MA.
- MB is started. GemFire XD
recognizes MB as having the most recent disk data for TableP and initializes it
- MA recovers its TableP
data from disk and updates it as needed from the data in MB.