Using gfxd to Start and Stop Members / Using Additional Boot Properties |
GemFire XD uses property values to configure the behavior of the distributed system. You can specify property values in a variety of ways depending on how you start the GemFire XD server or peer.
If a system property named gemfirexd.<property-name> is defined and its value is not an empty string, then its value will be used for the named configuration attribute.
Properties can be passed in a Properties object passed to the DriverManager.getConnection method.
Otherwise, if a property is defined in a property file found by this application, and its value is not an empty string, then its value will be used for that attribute.
Otherwise a default value is used.
When running the interactive gfxd tool, you can specify the location of the properties file using the -p propertyfile option on the command line when you start gfxd.
Current directory (directory in which the process was launched)
User's home directory
Class path (loaded as a system resource)
By default, GemFire XD persists the data dictionary for any data store member (members that use the host-data=true boot property). When persistence is enabled for a GemFire XD member, the member preserves all table, index, trigger, and procedure definitions in a disk store, even when all members of the distributed system are down. When the system is brought back up, there is no need to re-execute the data definition statements (DDL).
Persistence of the data dictionary is controlled by the persist-dd boot property. By default, this property is set to true for all members that host data. You must specify a consistent persist-dd value for all data stores in the same GemFire XD cluster. You cannot enable persistence for GemFire XD accessors in a cluster.
The data dictionary is always replicated and available on each peer member of the distributed system. So, even if data dictionary persistence is turned off, the dictionary is preserved as long as there is at least one member of the distributed system running. If all members are brought down when persistence is turned off, you must re-execute the DDL to restore your database.
The persistent data is written to a disk store the directory specified by the connection property sys-disk-dir. Each member must specify its own unique directory. When a member is brought up, it looks to other members for data before reading its persistent files. That is, live data overrides persistent data.
Optimizing a System with Disk Stores provides more informationa bout starting and shutting down GemFire XD clusters that utilize disk stores for persistence.