After you add a database to the dashboard, you can still change the configuration settings, as necessary. Make sure the database is being displayed in the dashboard. (If not, click on the database name in the global list of databases to the left and select View from the popup menu.) Then click on Edit next to the settings you want to modify:
The basic database settings you defined when creating database are displayed in the Configuration panel. Click on Edit in the Configuration panel to change these settings or to access the advanced settings.
The database schema is defined by the runtime catalog listed in the Catalog panel. Click on Edit in the Catalog panel to load a new catalog.
The settings for automated snapshots are defined in the Snapshots panel. Click on Edit in the Snapshots panel to change the settings for automated snapshots or to manage existing snapshots.
The settings for export are defined in the Export panel. Click on Edit in the Export panel to change the settings as described in Section 4.3, “Configuring Export”.
The catalog and snapshot settings match the settings available to you when you created the database. The configuration settings include both the basic settings you specified when creating the database, and advanced settings that let you customize the ports the database servers use at runtime, paths for runtime functions, and more. Table 4.2, “Advanced Configuration Settings” describes the additional fields on the Edit Database dialog box.
Table 4.2. Advanced Configuration Settings
The port that client applications use to connect to the VoltDB database cluster. The default client port is 21212. You can specify a different value. However, if you do, all client applications must specify that port number when creating a connection to the database.
The port used to enable and disable admin mode and issue commands while admin mode is in effect. The default admin port is 21211. See the section "Admin Mode" in Using VoltDB for more information about admin mode.
The port that the JSON interface uses to connect to the VoltDB database cluster. This port also provides basic information about the database (including version number and memory usage) if accessed by an HTTP request not directed at the JSON URL.
If your client applications use the JSON interface to access the database, you must check the box to enable JSON. The JSON interface uses the port identified in the HTTP Port field.
The port that VoltDB servers use to communicate among themselves.
The port that the Enterprise Manager uses to collect Log4J log messages from the individual servers.
The port that the VoltDB Enterprise Manager uses to retrieve status and performance statistics from the individual servers (using JMX, the Java Management Extensions).
The port that VoltDB uses to interact with Zookeeper locally. The default port is 2181.
The first of three consecutive ports on the database server that the DR agent uses to interact with the master database during database replication. The default starting port is 5555.
The path where snapshots are stored on the individual database servers, including manual, automated, and network partition snapshots. This path is relative to the VoltDB root directory on the remote nodes.
The VoltDB root directory for remote servers controlled by the Enterprise Manager is a subfolder
of the destination directory. The name of the subfolder is the database ID. So, for example, if the destination
If you specify an absolute path for the snapshot directory, the
snapshot files are stored in that directory. If you specify a relative path, the files are stored in that path
relative to the VoltDB root directory. If you do not specify a snapshot directory path, snapshots are stored in a
|Export Overflow Directory|
The path where export overflow information is stored if the export queue backs up. This path is relative to the VoltDB root directory on the remote nodes, as outlined in the description of the snapshot directory above.
If you specify an absolute path, export overflow information is stored in that directory. If you
specify a relative path, the data is stored in that path relative to the VoltDB root directory, If you do not
specify an export overflow path, export overflow data is stored in a subfolder named
|Command Log Directory|
The path where the command logs are stored if command logging is enabled. For maximum performance while logging, the command logs should be written to a disk with good response time. (For example, a disk with battery-backed caching.) It is also best to dedicate a disk to the command logs, rather than share a device for logs and other I/O such as snapshots or export overflow.
If you specify an absolute path, the command logs
are stored in that directory. If you specify a relative path, the data is stored in that path relative to the VoltDB
root directory, By default the command logs are stored in a subfolder named
|Command Log Snapshot Directory|
The path where the snapshots associated with command logs are stored, if command logging is enabled. Again, for maximum performance, it is best to write the logs and the snapshots to separate devices. Note that these are snapshots specific to command logging. If you have automated snapshots turned on, those snapshots are written to the snapshot directory (described earlier) instead.
If you specify an absolute path, the snapshots are
stored in that directory. If you specify a relative path, the snapshots are stored in that path relative to the
VoltDB root directory, By default the command log snapshots are stored in a subfolder named
|Command Logging: Log Frequency|
There are two settings available for configuring the frequency of command logging. These settings define the frequency with which the record of procedure invocations are written to the command log. The more frequently the logs are written, the less danger of losing data there is in case of a complete cluster failure. However, the more frequently logs are written, the more likely it is that disk I/O may impact your application's throughput or latency.
There are two frequency settings that can be set separately:
Whichever milestone is reached first initiates a write to the logs. See the chapter on "Command Logging and Recovery" in Using VoltDB for more information.
|Command Logging: Synchronous Logging|
In addition to specifying the frequency of logging, you can also specify whether logging occurs synchronously or asynchronously. Normally, logging is asynchronous to the database transactions; the transactions continue while the log is being written. If you select synchronous logging (by checking the checkbox), the results of all transactions are held until the next batch of transactions are written to the log.
Synchronous logging is recommended only if you have a fast, dedicated device for command logging (such as a disk with a battery-backed cache). Otherwise logging will have a negative impact on the performance of your transactions as they wait for the disk I/O to complete. At the same time, if you do use synchronous logging, it is important to set the command logging frequency to a very small increment (1-10 milliseconds), to keep the impact on latency to a minimum.
See Using VoltDB for more information on command logging.
|Command Logging: Log Size|
The size of the command logs defines how much disk space is preallocated for storing the logs. For most workloads, the default log size of one gigabyte is sufficient. However, if your workload writes large volumes of data or uses large strings for queries (so the command invocations include large parameter values), the log segments fill up very quickly. To avoid this, you can increase the total log size. Specify the desired log size as an integer number of megabytes. The minimum log size is three megabytes.
|Max Java heap|
The maximum heap size for the Java process running the database software on each cluster node.
The database servers keep track of each other by periodically checking for a "heartbeat" from the other nodes in the cluster. If a heartbeat is not received from a server 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" , which is specified in 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.
|Max temp table memory|
The maximum size for the temporary tables that VoltDB uses to store table data while processing transactions. The default temp table size is 100 megabytes. This setting is appropriate for most applications. If you need to increase the temp table size, you can specify an alternate size as an integer number of megabytes. Note, however, increasing the temp table limit may result in out-of-memory errors on memory-constrained systems.
|Snapshot Priority||Snapshot priority specifies the priority (as a value between 0 and 10) for snapshots as opposed to other database work. The lower the priority value, the more priority snapshot work receives. Zero specifies that no prioritizing is applied and snapshot work is done immediately. The closer to 10 the priority value, the longer a snapshot can take to complete. The closer to 1 the value, the quicker the snapshots complete but the more likely snapshots could impact latency and/or throughput of database transactions on a loaded database.|
Note that certain settings cannot be changed while the database is running (for example, port numbers or the maximum heap size). If the database is running and a setting cannot be modified, that particular configuration field is grayed out in the interface. To change these settings, you must stop the database first.