1.1.1

Peer Client Considerations for Persistent Data
Peer clients (clients started using the host-data=false property) do not use disk stores and can never persist
the SQLFire data dictionary. Instead, peer clients rely on other data stores or locators in the distributed system
for persisting data. If you use a peer client to execute DDL statements that require persistence and there are no
data stores available in the distributed system, SQLFire throws a data store unavailable exception (SQLState:
X0Z08).
You must start locators and data stores before starting peer clients in your distributed system. If you start a peer
client as the first member of a distributed system, the client initializes an empty data dictionary for the distributed
system as a whole. Any subsequent datastore that attempts to join the system conflicts with the empty data
dictionary and fails to start with a ConflictingPersistentDataException.
Shared-Nothing Disk Store Design
Individual SQLFire peers that host table data manage their own disk store files, completely separate from the
disk stores files of any other member. When you create a disk store, you can define certain properties that specify
where and how each SQLFire peer should manages disk store files on their local filesystem.
SQLFire supports persistence for replicated and partitioned tables. The disk store mechanism is designed for
locally-attached disks. Each peer manages its own local disk store, and does not share any disk artifacts with
other members of the cluster. This shared nothing design eliminates the process-level contention that is normally
associated with traditional clustered databases. Disk stores use rolling, append-only log files to avoid disk seeks
completely. No complex B-Tree data structures are stored on disk; instead SQLFire always assumes that complex
query navigation is performed using in-memory indexes.
Disk stores also support the SQLFire data rebalancing model. When you increase or decrease capacity by adding
or removing peers in a cluster, the disk data also relocates itself as necessary.
What SQLFire Writes to the Disk Store
For each disk store, SQLFire stores detailed information about related members and tables.
SQLFire stores these items in each disk store:
• List of members that host the store and information on their status, such as running or offline and time stamps.
• List of tables that use the disk store.
For each table in the disk store, SQLFire stores:
• Configuration attributes pertaining to loading and capacity management, used to load the data quickly on
startup.
• Table DML operations.
Disk Store State
Disk store access and management differs according to whether the store is online or offline.
When a member shuts down, its disk stores go offline. When the member starts up again, its disk stores come
back online in the SQLFire cluster.
• Online, a disk store is owned and managed by its member process.
• Offline, the disk store is simply a collection of files in your host file system. The files are open to access by
anyone with the right file system permissions. You can copy the files using your file system commands, for
backup or to move your member’s disk store location. You can also run maintenance operations on the offline
disk store, like file compaction and validation using the sqlf utility.
Note: The files for a disk store are used by SQLFire as a group. Treat them as a single entity. If you
copy them, copy them all together. Do not change the file names or permissions.
vFabric SQLFire User's Guide80
Managing Your Data in vFabric SQLFire