1.1

Note: When you specify asynchronous persistence, asynchronous writes to the disk store use certain
disk store attributes. See Disk Store Persistence Attributes on page 79.
Related Topics
CREATE DISKSTORE on page 465
CREATE TABLE on page 476
Evicting table data from memoryUse eviction to remove table data from memory, or to persist the overflow data in a disk store.
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 shuts
down all data stores and accessors, but leaves locators and JMX agents running. When shutting down an entire
system, a locator should be the last member to shut down (after all data stores have successfully stopped).
• 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 85
• Startup Process on page 86
• Example Startup Scenarios on page 86
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 84.
85
Using Disk Stores to Persist Data