1.1

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
on page 84.
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
/10.80.10.64:/export/straw3/users/jpearson/GemFireTesting/hostB/
backupDirectory created at timestamp 1270834766425 version 0 is
waiting for the data previously hosted at
[/10.80.10.64:/export/straw3/users/jpearson/GemFireTesting/hostA/
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 on page 79). Once all keys are loaded, SQLFire 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:
1. Member A (MA) exits first, leaving persisted data on disk for TableP.
2. 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.
3. MB exits, leaving the most up-to-date data on disk for Table P.
• Restart order Scenario 1:
1. MB is started first. SQLFire recognizes MB as having the most recent disk data for TableP and initializes
it from disk.
2. MA is started, recovers its data from disk, and updates it as needed from the data in MB.
• Restart order Scenario 2:
vFabric SQLFire User's Guide86
Managing Your Data in vFabric SQLFire