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
Network partition detection
Temp table size
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
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
kfactor attribute of the
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.
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.
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.
The export function lets you automatically export selected data from your VoltDB database to an another target database or system 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.
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.
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 (10 seconds) is appropriate. However, if your cluster is operating in an environment that is susceptible to network fluctuations or unpredictable latency, you may want to increase the heartbeat timeout period.
You can set an alternate heartbeat timeout using the
<heartbeat> tag in the deployment file.
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 and
specifying a whole number of megabytes. 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.
In general, SQL queries execute extremely quickly. But it is possible, usually by accident, to construct a query that takes an unexpectedly long time to execute. This usually happens when the query is overly complex or accesses extremely large tables without the benefit of an appropriate filter or index.
There is no way to terminate individual queries once they start. However, you can set a limit on the length of time any read-only query (or batch of queries in the case of the voltExecuteSQL() method in a stored procedure) is allowed to run. This limit is called the query timeout and is specified in milliseconds. Setting the timeout value to zero is the equivalent of the default; that is, no timeout.
For example, the following deployment file sets a query timeout value of three seconds:
<systemsettings> <query timeout="3000"/> </systemsettings>
If any query or batch of queries exceeds the query timeout, the query is interrupted and an error returned to the calling application. Note that the limit is applied to read-only ad hoc queries or queries in read-only stored procedures only. In a K-Safe cluster, queries on different copies of a partition may execute at different rates. Consequently the same query may timeout in one copy of the partition but not in another. To avoid possible non-deterministic changes, VoltDB does not apply the time out limit to any queries or procedures that may modify the database contents.