1.0

Optimizing Availability and Performance
Be aware of what you can do to optimize availability and performance of disk stores.
Consider these guidelines:
• When you start your system, start all the members that have persistent tables in parallel. Create and use startup
scripts for consistency and completeness.
•
Shut down your system using the sqlf shut-down-all command. This is an ordered shutdown that
positions your disk stores for a faster startup.
• Decide on a file compaction policy and, if needed, develop procedures to monitor your files and execute regular
compaction.
• Decide on a backup strategy for your disk stores and follow it. You can back up by copying the files while the
system is offline, or you can back up an online system using the sqlf backup command.
• If you drop or alter any persistent table while your disk store is offline, consider synchronizing the tables in
your disk stores.
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.
The following sections explain what happens during startup and shutdown:
• Shutdown: Most Recent Data from the Last Run on page 77
• Startup Process on page 77
• Example Startup Scenarios on page 78
Shutdown: Most Recent Data from the Last Run
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.
SQLFire 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
on page 76.
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 76.
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.
77
Using Disk Stores to Persist Data