Runtime configuration options are set either as part of the deployment file or as command line options when starting the VoltDB server process. These database configuration options are only summarized here. See the Using VoltDB manual for a more detailed explanation. The configuration options include:
Sites per host specifies the number of unique VoltDB "sites" that are created on each physical database server. The section on "Determining How Many Partitions to Use" in the Using VoltDB manual explains how to choose a value for sites per host.
You set the value of sites per host using the
sitesperhost attribute of the
<cluster> tag in the deployment file. When using the Enterprise Manager, the number of
sites per host is set in the dialog box when you create or edit the database.
K-safety defines the level of availability or durability that the database can sustain, by replicating individual partitions to multiple servers. K-safety is described in detail in the "Availability" chapter of the Using VoltDB manual.
You specify the level of K-safety that you want in the deployment file using the
attribute of the
<cluster> tag. If you are using the Enterprise Manager, there is
an input field ("kfactor") for specifying the K-safety value when you create or edit the database.
Network partition detection protects a VoltDB cluster in environments where the network is susceptible to partial or intermittent failure among the server nodes. Partition detection is described in detail in the "Availability" chapter of the Using VoltDB manual.
Use of network partition detection is strongly recommended for production systems and therefore is enabled by default. You can enable or disable network partition detection in the deployment file using the <partition-detection> tag. If you are using the Enterprise Manager, there is a check box for enabling and disabling partition detection when you create or edit the database.
Automated snapshots provide ongoing protection against possible database failure (due to hardware or software issues) by taking periodic snapshots of the database's contents. Automated snapshots are described in detail in the section on "Scheduling Automated Snapshots" in the Using VoltDB manual.
You enable and configure automated snapshots with the <snapshot> tag in the deployment file. If you are using the Enterprise Manager, you can enable automated snapshots when you create the database (using fields on the Create Database dialog box) or after the database is created from the Snapshot settings panel using the Edit Snapshots dialog.
Snapshot activity involves both processing and disk I/O and so may have a noticeable impact on performance (in terms of throughput and/or latency) on a very busy database. You can control the priority of snapshots activity using the <snapshot/> tag within the <systemsettings> element of the deployment file. The snapshot priority is an integer value between 0 and 10, with 0 being the highest priority and 10 being the lowest. The closer to 10, the longer snapshots take to complete, but the less they can affect ongoing database work.
Note that snapshot priority affects all snapshot activity, including automated snapshots, manual snapshots, and command logging snapshots. If you are using the Enterprise Manager, there is an input field for specifying the snapshot priority on the Edit Configuration dialog box.
The export function lets you automatically export selected data from your VoltDB database to an export client using SQL INSERT statements to special export tables at runtime. This feature is described in detail in the chapter on "Exporting Live Data" in the Using VoltDB manual.
You enable and disable export using the <export> tag in the deployment file. If you are using the Enterprise Manager, there is a separate panel and dialog box for configuring export, which is described in Section 4.3, “Configuring Export”.
The command logging function saves a record of each transaction as it is initiated. These logs can then be "replayed" to recreate the database's last known state in case of intentional or accidental shutdown. This feature is described in detail in the chapter on "Command Logging and Recovery" in the Using VoltDB manual.
To enable and disable command logging, use the <commandlog> tag in the deployment file. If you are using the Enterprise Manager, there is a check box for enabling command logging when you create the database and additional fields for configuring command logging on the Edit Database dialog box.
The database servers use a "heartbeat" to verify the presence of other nodes in the cluster. If a heartbeat is not received within a specified time limit, that server is assumed to be down and the cluster reconfigures itself with the remaining nodes (assuming it is running with K-safety). This time limit is called the "heartbeat timeout" and is specified as a integer number of seconds.
For most situations, the default value for the timeout (90 seconds) is appropriate. Note that if a node fails, until the heartbeat expires, any transaction requiring that server will stall.
It is possible to set a lower timeout to avoid stalling transactions. However, if your servers are susceptible to network fluctuations or intra-server process contention, it is possible that a viable node can get timed out by a too small timeout.
You can set an alternate heartbeat timeout using the
<heartbeat> tag in the deployment
file, specifying the timeout value in seconds. If you are using the Enterprise Manager, there is a input field for
specifying the timeout on the Edit Database dialog box.
VoltDB uses temporary tables to store intermediate table data while processing transactions. The default temp table size is 100 megabytes. This setting is appropriate for most applications. However, extremely complex queries or many updates to large records could cause the temporary space to exceed the maximum size, resulting in the transaction failing with an error.
In these unusual cases, you may need to increase the temp table size. You can specify a different size for the temp
tables using the
<temptables> tag in the deployment file. Note: since the temp tables are
allocated as needed, increasing the maximum size can result in a Java out-of-memory error at runtime if the system is
memory-constrained. Modifying the temp table size should be done with caution.
If you are using the Enterprise Manager, there is a input field for specifying the maximum temp table limit on the Edit Database dialog box.