1.1.1

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:
1. MA is started first. SQLFire recognizes that MA does not have the most recent disk store data and waits
for MB to start before creating TableP in MA.
2. MB is started. SQLFire recognizes MB as having the most recent disk data for TableP and initializes it
from disk.
3. MA recovers its TableP data from disk and updates it as needed from the data in MB.
Start a System with Disk Stores
When you start a SQLFire cluster with disk stores, it is recommended that you start all members with persisted
data at the same time.
Procedure
1. Start members with persisted data at the same time.
When members with persistent data boot, they determine which have the most recent table data, and they
initialize their caches using that data. If you do not start persistent data stores in parallel, some members may
hang while waiting for other members to start.
The following example bash script starts members in parallel. The script waits for the startup to finish and
exits with an error status if one of the jobs fails.
#!/bin/bash
ssh servera "cd /my/directory; sqlf server start
ssh serverb "cd /my/directory; sqlf server start
STATUS=0;
for job in `jobs -p`
do
echo $job
wait $job;
JOB_STATUS=$?;
test $STATUS -eq 0 && STATUS=$JOB_STATUS;
done
exit $STATUS;
2. Respond to any member startup hangs. If a disk store with the most recent table data does not come online,
other members wait indefinitely rather than come online with stale data. Check for missing disk stores with
the sqlf list-missing-disk-stores command. See Handling Missing Disk Stores on page 96.
a. If no disk stores are missing, your peer initialization may be slow for some other reason. Check to see if
other members are hanging or fail to start.
b. If disk stores are missing that you think should be there:
89
Using Disk Stores to Persist Data