Volt Active Data
13.3.2
VoltDB Operator 3.2.1 |
September 6, 2024 (updated September 10, 2024)
This document provides information about known issues and limitations to the current release of VoltDB. If you encounter any problems not listed below, please be sure to report them to support@voltactivedata.com. Thank you.
The process for upgrading from the recent versions of VoltDB is as follows:
Shutdown the database, creating a final snapshot (using voltadmin shutdown --save).
Upgrade the VoltDB software.
Restart the database (using voltdb start).
For Kubernetes, see the section on "Upgrading the VoltDB Software and Helm Charts" in the VoltDB Kubernetes Administrator's Guide. For DR clusters, see the section on "Upgrading VoltDB Software" in the VoltDB Administrator's Guide for special considerations related to DR upgrades. If you are upgrading from versions before V6.8, see the section on "Upgrading Older Versions of VoltDB Manually" in the same manual.
Finally, for all customers upgrading from earlier versions of VoltDB, please be sure to read the Volt Upgrade Guide, paying special attention to the notes for your current and subsequent releases, including V8, V10, V11, and V12.
Users of previous versions of VoltDB should take note of the following changes that might impact their existing applications. See the Volt Operator Release Notes for changes specific to the use of VoltDB on the Kubernetes platform.
Starting with the release of Volt Operator version 3.0.0, the commands for starting and managing Volt clusters on
Kubernetes have changed. These changes apply to all versions of VoltDB after you do a helm
repo update
, which makes Volt Operator version 3.0.0 available in Helm.
For the latest Volt Operator there is no default for the software version — you must specify the version on the Helm command line. How this is done depends on which version of VoltDB you wish to use:
Recent releases — For recent releases of all supported versions of Volt
Active Data (including 13.0.3, 12.3.4, 11.4.13, and 10.2.21 or later) you can specify the VoltDB version to use by
setting the Helm property global.voltdbVersion
. For example:
$ helm install mydb voltdb/voltdb --set global.voltdbVersion=13.3.0
Older releases — For earlier releases (prior to 13.0.3, 12.3.4, 11.4.13, or 10.2.21) you must specify the Operator and chart version associated with the software version you want to use and, optionally, the image tag. For example:
$ helm install mydb voltdb/voltdb \ --set operator.image.tag=2.2.1 \ --set cluster.clusterSpec.image.tag=12.3.1
See the Volt Operator Release Notes for details on running older versions of VoltDB on Kubernetes.
1. Release V13.3.2 (September 6, 2024) | ||||||||||
1.1. | Security updates | |||||||||
The following CVE was resolved:
| ||||||||||
1.2. | Improvements | |||||||||
The following limitations in previous versions have been resolved:
| ||||||||||
2. Release V13.3.1 (August 16, 2024) | ||||||||||
2.1. | Preparation for in-service upgrades to Volt Active Data V14.0 | |||||||||
This release includes the necessary changes to prepare the software to support in-service upgrades from V13.3 LTS to the next major version of Volt Active Data, V14.0. | ||||||||||
2.2. | Security updates | |||||||||
The following CVEs were resolved:
The following outstanding CVE in the Universal Base Image (UBI) will be addressed as soon as a fix becomes available from Red Hat:
| ||||||||||
2.3. | Improvements | |||||||||
The following limitations in previous versions have been resolved:
| ||||||||||
3. Release V13.3.0 (June 28, 2024) | ||||||||||
3.1. | Long-Term Support release for Volt Active Data Version 13 now available | |||||||||
We are happy to announce the Long-Term Support (LTS) release for version 13. This means this version of the software has reached maturity and will be maintained for the LTS life span. Updates will be released to fix critical security vulnerabilities, correct bugs, and further ensure the stability of the software, but no new features will be added until the next major release, V14.0.0. | ||||||||||
3.2. | Support for dual stack networks | |||||||||
This release extends the IPv6 and dual stack network support by allowing the selection of the IP protocol to
use for XDCR clusters in Kubernetes. The | ||||||||||
3.3. | Improved performance of in-service upgrades | |||||||||
As part of the in-service upgrade (ISU) process, the nodes drop out of the cluster and rejoin it one at a time to upgrade the software. During this step there was a momentary but noticeable spike in the latency of in-flight transactions as the remaining nodes synchronize their workloads. This latency has been dramatically reduced, improving the overall performance and reducing the impact on customer applications during the upgrade process. | ||||||||||
3.4. | New configuration options for controlling database replication (DR) timeouts | |||||||||
There is an undocumented VOLTDB_OPTS option, DR_RECV_TIMEOUT, that changes the timeout period for a cluster's
connection requests to another XDCR cluster. This setting is now deprecated and replaced by two official
configuration controls, <dr id="1" role="xdcr"> <connection source="parisdb.myorg.com" connectiontimeout="15000" receivetimeout="300000" /> </dr> Note that the use of DR_RECV_TIMEOUT is now deprecated and will be ignored in a future release. However, until then, the VOLTDB_OPTS setting will take precedence so as not to alter existing behavior. | ||||||||||
3.5. | New documentation on tuning XDCR clusters | |||||||||
The chapter on Active(N) Database Replication in the Using VoltDB manual has been rewritten, including a new section on tuning XDCR to meet the needs of the application's workload requirements. | ||||||||||
3.6. | Additional improvements | |||||||||
In addition to the new features and capabilities described above, the following limitations in previous versions have been resolved:
| ||||||||||
4. Release V13.2.3 (June 27, 2024) | ||||||||||
4.1. | Improvements | |||||||||
The following limitations in previous versions have been resolved:
| ||||||||||
5. Release V13.2.2 (May 31, 2024) | ||||||||||
5.1. | Security updates | |||||||||
The following CVE was resolved:
The following outstanding CVE's in the Universal Base Image (UBI) will be addressed as soon as fixes become available from Red Hat:
| ||||||||||
5.2. | Additional improvements | |||||||||
The following limitations in previous versions have been resolved:
| ||||||||||
6. Release V13.2.1 (April 19, 2024) | ||||||||||
6.1. | Additional improvement | |||||||||
The following limitation in a previous version has been resolved:
| ||||||||||
7. Release V13.2.0 (March 29, 2024) | ||||||||||
7.1. | Volt Operator V3.0 | |||||||||
This release of Volt Active Data uses a new version of the Volt Operator for Kubernetes, version 3.0.0. The newest operator improves the management of Volt database applications in two ways. It allows the user to select the chart, operator, and Docker image by specifying just the software version of VoltDB. It also uses a single operator and chart for managing all current versions of VoltDB, rather than separate operator releases for each software release. These changes have two major benefits:
The one slight change resulting from the transition to Operator V3.0 is that there is no longer a default version of VoltDB. In other words, you must explicitly identify the version of VoltDB you want to use when you start the database or upgrade the VoltDB version. For example: $ helm install mydb voltdb/voltdb --set global.voltdbVersion=13.2.0 This applies to both the | ||||||||||
7.2. | Autoscaling in Kubernetes | |||||||||
Volt Active Data now supports autoscaling in Kubernetes. That is, the ability for the Volt Operator to automatically expand or contract the cluster based on specific metrics. For example, if the workload increase to a certain size, measured in transactions per second, the operator will add more nodes to the cluster to handle the additional work. On the other hand, if the workload decreases below a certain TPS value, the operator will shrink the cluster to avoid over provisioning. See the chapter on starting and stopping the cluster in the Kubernetes Administrator's Guide for more information on autoscaling. | ||||||||||
7.3. | Separate VMC service now available | |||||||||
A separate service supporting the Volt Management Center (VMC) and HTTP JSON programming interface is now available for bare metal installations. The VMC service has been available on Kubernetes since VoltDB V13.0; it is now also available as a separate downloadable kit for bare metal systems. The separate service is recommended for several reasons:
So the Volt VMC Service guide for details on installing and running VMC and the JSON HTTP API as a separate service. | ||||||||||
7.4. | Embedded VMC and JSON HTTP API are being deprecated | |||||||||
With the availability of VMC and the JSON API as a separate service, the use of these features embedded in the server software is being deprecated. The separate VMC service is already used by default on Kubernetes. Currently, the embedded VMC and HTTP server are still available and enabled by default for clusters running on bare metal. However, in a future release, this default will be changed so that the embedded service does not start by default and, eventually, it will be removed entirely from the server software. | ||||||||||
7.5. | Kubernetes updated to use the Red Hat Universal Base Image (UBI). | |||||||||
With this release, the base image for running Volt under Kubernetes has been upgraded from Alpine to the Red Hat Universal Base Image (UBI). UBI provides Volt Active Data with an established and supported base image on which to build. This change also corrects issues encountered when running Volt under recent releases of OpenShift. | ||||||||||
7.6. | New SQL SIGN() function | |||||||||
There is a new SQL function, SIGN(), that takes a numeric value as its argument and returns 1, -1, 0, or null, depending on whether the argument is positive, negative, zero, or null respectively. | ||||||||||
7.7. | Ability to select the Kubernetes user account and group UIDs | |||||||||
Previously, the user account UID used for the Kubernetes security context was fixed as user 1001 and could not be changed. The default is still 1001, but you can now select your own user and/or group UID when initially configuring a Volt Active Data database in Kubernetes. Note, however, you cannot change those IDs once the database has been created. | ||||||||||
7.8. | You can now use PEM files to specify the truststore in Java client applications and Volt command line utilities | |||||||||
Where before you had to specify the TS/SSL credentials using a properties file when connecting from a client, you can now use a PEM (or Privacy Enhanced Mail) file. PEM files are text rather than binary and therefore easier to manage. You can use them when connecting from a Java or Python client application or using the Volt command line utilities. For example, when starting sqlmd you can specify a PEM file with the --ssl qualifier: $ sqlcmd --ssl=mysslcreds.pem | ||||||||||
7.9. | Support for Java 21 | |||||||||
Volt Active Data now supports Java 21 for running the VoltDB servers and clients. | ||||||||||
7.10. | Support for Kubernetes 1.28 | |||||||||
The new operator V3.0.0 adds support for Kubernetes 1.28. | ||||||||||
7.11. | New metrics measure intra-cluster latency | |||||||||
Several new metrics are available that help analyze the time spent queuing, sending and returning transactions that must be passed between the nodes of the cluster. The new metrics are the result of sampling transactions in flight and include:
| ||||||||||
7.12. | New @Statistics MEMORY columns measure Java NIO usage and undo log size | |||||||||
Several columns have been added to the MEMORY selector of the @Statistics system procedure that measure the use of Java new input/output (NIO) memory and the undo log. These columns include UNDO_LOG_SIZE, NIO_TOTAL_BUFFER_COUNT, NIO_TOTAL_SIZE, and NIO_USED. See the description of the @Statistics system procedure in the Using VoltDB guide for details. | ||||||||||
7.13. | The | |||||||||
The Helm property | ||||||||||
7.14. | Active/passive database replication as a separate product feature is deprecated. | |||||||||
The original active/passive database replication product feature has been deprecated. The user interface artifacts associated with this feature (such the roles of "master" and "replica" in DR configuration and the @Promote system procedure ) will be removed in a future major release. Note that active/passive replication is still possible using Active(N), where it can also be combined with other DR usage models such as active/active. It is only the older, limited feature set and user interface that are being deprecated. | ||||||||||
7.15. | Security updates | |||||||||
The following high and critical CVEs were resolved:
| ||||||||||
7.16. | Additional improvements | |||||||||
The following limitations in previous versions have been resolved:
| ||||||||||
8. Release V13.1.3 (February 8, 2024) | ||||||||||
8.1. | Additional improvements | |||||||||
The following limitations in previous versions have been resolved:
| ||||||||||
9. Release V13.1.2 (January 31, 2024) | ||||||||||
9.1. | Improvements to In-Service Upgrade | |||||||||
This release provides significant improvements to the in-service upgrade process, eliminating most interruptions and errors returned by in-flight transactions due to servers stopping and restarting. In the initial release of in-service upgrade, stopping the individual nodes could result in transactions returning an error if the queue stopped before the transaction completed. This issue was exacerbated in Kubernetes environments by the Operator prematurely stopping the pod before the server process completed its shutdown procedure. Both of these situations have been significantly improved through better coordination of the server, the client, and the operator. Please note, that these improvements depend on changes to all three components and are only available if you upgrade all three. That is, using the latest Volt Operator, Volt server software, and linking your client applications against the latest Java client library (2.3.2 or later of the operator and V13.1.2 or later of the server software and client library). | ||||||||||
9.2. | Security updates | |||||||||
All known high and critical CVEs were resolved as of the date of this release, including:
| ||||||||||
9.3. | Additional improvement | |||||||||
The following limitation in previous versions has been resolved:
| ||||||||||
10. Release V13.1.1 (January 11, 2024) | ||||||||||
10.1. | Additional improvements | |||||||||
The following limitations in previous versions have been resolved:
| ||||||||||
11. Release V13.1.0 (December 21, 2023) | ||||||||||
11.1. | ARM 64 | |||||||||
Volt Active Data now supports the Arm CPU architecture — and specifically Aarch64 — as a hardware platform for production use of VoltDB. Talk to your Volt Active Data sales representative for more information. | ||||||||||
11.2. | In-Service Upgrade | |||||||||
Volt Active Data now supports in-service upgrades: the ability to upgrade the VoltDB
server software for a single cluster without requiring any downtime (uninterrupted upgrades using multiple Active(N)
clusters have been available for some time now). In-service upgrade is a new, licensable feature where you remove,
upgrade, and rejoin individual nodes from the cluster one at a time. On Kubernetes, the Volt Operator automates this
process through a new property, | ||||||||||
11.3. | Elastically reducing the cluster size in Kubernetes | |||||||||
It is now possible to both elastically grow and shrink clusters in the Kubernetes environment. Reducing the cluster size is just a matter of setting the replica count to the appropriate value. (You can only reduce the cluster by K+1 nodes at a time.) Once initialized, the Volt Operator automates the process and provides periodic status information through Kubernetes events and object properties. See the sections on elastically resizing the cluster in the Volt Kubernetes Administrator's Guide for more information. | ||||||||||
11.4. | Diagnostics tools for Kubernetes | |||||||||
Volt now provides maintenance and management tools optimized for Kubernetes as a separately installable pod. The diagnostics pod provides access to sqlcmd as well as the collect command for gathering logs and other diagnostics data from the cluster. See the appendix on diagnostics tools in the Volt Kubernetes Administrator's Guide for more information. | ||||||||||
11.5. | FORMAT() Function | |||||||||
There is a new SQL function, FORMAT(), that formats a text string, using the standard replacement placeholders found in functions such as printf to insert values from table columns and other SQL expressions. | ||||||||||
11.6. | New license file format | |||||||||
VoltDB uses a new license file format with a more flexible structure to allow for new features in the future. With the introduction of the new file format, this release of Volt Active Data no longer accepts older, outdated license formats. This means that before upgrading existing databases, please make sure you are using a recent license issued in the past two years. To verify that you have a recent license, connect to your database server and issue the command voltadmin inspect. If the command reports a permit version of 3 or 4, you are all set. If the command reports a permit version of 2 or less, or returns an error that no such command exists, you will need to replace your license before upgrading. Talk to your Volt Active Data customer support representative to receive a replacement license. In addition to a new license format, several minor changes related to license management have been made:
| ||||||||||
11.7. | Java 8 use deprecated for VoltDB servers | |||||||||
Use of the Java 8 runtime to run the VoltDB server software is now deprecated. The recommended Java versions are Java 11 and 17. Note that Java 8 is still supported for running applications using the VoltDB client API. Although deprecated, use of Java 8 to run the VoltDB server continues to work at this time. However, support for such usage will be removed in a future release. | ||||||||||
11.8. | Passive Database Replication deprecated | |||||||||
The original passive database replication (DR) functionality involving one master and one replica cluster, is now deprecated. The ability to set up passive replication using Active(N) — also known as XDCR — easily and more flexibly (with multiple masters, any mix of active masters and passive replicas) makes a separate and less functional alternative impractical. By focusing on a single, integrated set of capabilities for both active and passive DR, the product can move forward with new capabilities more rapidly. The separate passive DR implementation continues to function in V13. However, it will be removed from the product in some future major release. | ||||||||||
11.9. | Volt support for Helm 3.11 and later | |||||||||
To match the currently supported versions of Helm, Volt Active Data now requires Helm 3.11 or later when running in Kubernetes. | ||||||||||
11.10. | Additional improvements | |||||||||
The following limitations in previous versions have been resolved:
| ||||||||||
12. Release V13.0.3 (November 27, 2023) | ||||||||||
12.1. | Security updates | |||||||||
All known high and critical CVEs were resolved as of the date of this release, including:
| ||||||||||
12.2. | Additional improvements | |||||||||
The following limitations in previous versions have been resolved:
| ||||||||||
13. Release V13.0.2 (November 6, 2023, updated May 14, 2024) | ||||||||||
13.1. | Beta release of ARM architecture support. | |||||||||
We are happy to announce that VoltDB 13.0.2 is available in both the traditional x86 kit and in a new ARM64 architecture build. The ARM build is a beta release for testing only, it is not intended for production use. The only known limitation to the beta release is that the separate Volt Management Center (VMC) pod for
Kubernetes does not work yet. The workaround is to set the $ helm install mydb voltdb/voltdb \ --values myconfig.yaml \ --set vmc.enabled=false Please report any further issues and feedback to betasupport@voltactivedata.com. Thank you. | ||||||||||
13.2. | New diagnostics pod available for Volt Active Data on Kubernetes. | |||||||||
For Kubernetes users, there is a new tool, the diagnostics pod, that automates the collection of logs and other diagnostic information that is needed when debugging issues you report to the Volt support team. The diagnostics pod is a standalone product that is installed separately, so can be added to existing VoltDB installations without affecting ongoing operations. The diagnostics pod is available from the same repository as the Volt Active Data server software and can be installed using Helm: $ helm install volttools voltdb/volt-diagnostics Instructions are available in the readme included in the kit: $ helm show readme voltdb/volt-diagnostics | ||||||||||
13.3. | Security updates | |||||||||
All known high and critical CVEs were resolved as of the date of this release, including:
| ||||||||||
13.4. | Additional improvements | |||||||||
The following limitations in previous versions have been resolved:
| ||||||||||
14. Release V13.0 (September 30, 2023) | ||||||||||
14.1. | New Prometheus metrics system | |||||||||
Volt V13 announces the general production release of a new metrics system, where every server in the cluster reports its own data through a Prometheus-compliant endpoint. You enable Prometheus metrics in the configuration file when initializing the database by adding the <metrics> element to the Volt configuration file: <deployment>
<cluster kfactor="1"/>
<metrics enabled="true"/>
</deployment> Once enabled, each Volt server reports server-specific information through the metrics port, which defaults to 11781. The new metrics system replaces the standalone Prometheus agent, which has now been deprecated. See the sections on integrating with Prometheus in the Volt Administrator's Guide and Volt Kubernetes Administrator's Guide. | ||||||||||
14.2. | New Grafana dashboards | |||||||||
To match the new metrics system, Volt provides sample Grafana dashboards to help visualize your database's performance and status. The dashboards are available from github: | ||||||||||
14.3. | Support for alternate character sets | |||||||||
Volt provides full support for international characters through its use of UTF-8 for storing and displaying
textual data. However, there are other character encodings that may be in use by customers, including both older,
established encodings such as Shift_JIS and newer encodings like the Chinese GB18030-2022 standard. For customers
using alternate character encodings as the default in their client environment, Volt now provides automatic
conversion of character encodings both interactively and for file input. The sqlcmd utility
automatically converts to and from the terminal session's localized character set for input and display. When
reading and writing files, you can use the | ||||||||||
14.4. | Improved command line interface for the sqlmd utility | |||||||||
In addition to full character set support, the sqlcmd utility has a more complete and
consistent set of command line qualifiers. The new | ||||||||||
14.5. | Beta support for ARM architecture | |||||||||
Beta software kits for running the VoltDB server software natively on ARM64 architecture are now available. If you are interested in participating in the ARM64 beta program, please contact your Volt Customer Success Manager. | ||||||||||
14.6. | Support for Kubernetes 1.27 | |||||||||
Volt Active Data now supports version 1.27 of the Kubernetes platform. See the Kubernetes Compatibility Chart for details on what versions of Kubernetes are supported by each version of VoltDB. | ||||||||||
14.7. | Security updates | |||||||||
All known high and critical CVEs were resolved as of the date of this release, including:
| ||||||||||
14.8. | Additional improvements | |||||||||
The following limitations in previous versions have been resolved:
|
The following are known limitations to the current release of VoltDB. Workarounds are suggested where applicable. However, it is important to note that these limitations are considered temporary and are likely to be corrected in future releases of the product.
The following notes provide details concerning how certain VoltDB features operate. The behavior is not considered incorrect. However, this information can be important when using specific components of the VoltDB product.
1. Networking | |||||
1.1. | Support for IPv6 addresses | ||||
VoltDB works in IPv4, IPv6, and mixed network environments. Although the examples in the documentation use IPv4 addresses, you can use IPv6 when configuring your database, making connections through applications, or using the VoltDB command line utilities, such as voltdb and voltadmin. When specifying IPv6 addresses on the command line or in the configuration file, be sure to enclose the address in square brackets. If you are specifying both an IPv6 address and port number, put the colon and port number after the square brackets. For example: voltadmin status --host=[2001:db8:85a3::8a2e:370:7334]:21211 | |||||
1.2. | Issues with Jumbo Frames | ||||
There have been reports that VoltDB does not operate correctly when the networking environment is configured to use jumbo frames. The symptoms are that TCP packets with MTU>9000 are dropped. However, this is not a Volt-specific issue. When configuring the network to use jumbo frames, it is crucial to thoroughly test the network to guarantee that TCP packets are not fragmented or have their segments reordered during reassembly. If not, there is a danger of lost packets in the network layer, unrelated to the specific application involved. | |||||
2. XDCR | |||||
2.1. | Upgrading existing XDCR clusters for Dynamic Schema Change | ||||
Volt Active Data V12.3 introduces a new feature, dynamic schema change for XDCR clusters. To use this feature, clusters must be configured to enable the feature and must be using the latest DR protocol. However, existing clusters that upgrade from earlier versions will not automatically use the new protocol. Instead, you must explicitly upgrade the DR protocol using the voltadmin dr protocol --update command. First, to use dynamic schema change you must enable the feature in the configuration file. This must be done
when you initialize the cluster which, for existing XDCR clusters, is easiest to when performing the version
upgrade. To upgrade XDCR clusters, you must drop the cluster from the XDCR environment, upgrade the software, then
reinitialize and restart the cluster. While reinitializing the cluster, add the <deployment>
<dr id="1" role="xcdr">
<schemachange enabled="true"/>
<connection source="paris.mycompany.com,rome.mycompany.com"/>
</dr>
</deployment> Similarly, for Kubernetes, the YAML would be: cluster:
config:
deployment:
dr:
id: 1
role: xdcr
schemachange:
enabled: true
connection:
source: paris.mycompany.com,rome.mycompany.com Once all of the clusters are upgraded to the appropriate software version, you can upgrade the DR protocol. When used by itself, the voltadmin dr protocol command displays information about what versions of the DR protocol the XDCR clusters support and which version they are using. When the XDCR relationship starts, the clusters use the highest supported protocol. However, when an existing XDCR group is upgraded, they do not automatically upgrade the originally agreed-upon protocol. In this case, you must go to each cluster and issue the voltadmin dr protocol --update command to use the highest protocol that all the clusters can support. Once you issue the voltadmin dr protocol --update command on all of the clusters, you are then ready to perform dynamic schema changes on your XDCR environment. | |||||
3. Volt Management Center | |||||
3.1. | Schema updates clear the stored procedure data table in the Management Center Monitor section | ||||
Any time the database schema or stored procedures are changed, the data table showing stored procedure statistics at the bottom of the Monitor section of the VoltDB Management Center get reset. As soon as new invocations of the stored procedures occur, the statistics table will show new values based on performance after the schema update. Until invocations occur, the procedure table is blank. | |||||
3.2. | TLS/SSL for the HTTPD port on Kubernetes | ||||
Prior to VoltDB V12.0, encryption for the httpd port which VMC uses was automatically enabled on Kubernetes
when you enabled TLS/SSL for the server using the Starting with V12.0, VMC on Kubernetes is run as a separate service by default and you can enable or disable
TLS/SSL encryption for VMC independently using the | |||||
4. SQL | |||||
4.1. | You cannot partition a table on a column defined as ASSUMEUNIQUE. | ||||
The ASSUMEUNIQUE attribute is designed for identifying columns in partitioned tables where the column values are known to be unique but the table is not partitioned on that column, so VoltDB cannot verify complete uniqueness across the database. Using interactive DDL, you can create a table with a column marked as ASSUMEUNIQUE, but if you try to partition the table on the ASSUMEUNIQUE column, you receive an error. The solution is to drop and add the column using the UNIQUE attribute instead of ASSUMEUNIQUE. | |||||
4.2. | Adding or dropping column constraints (UNIQUE or ASSUMEUNIQUE) is not supported by the ALTER TABLE ALTER COLUMN statement. | ||||
You cannot add or remove a column constraint such as UNIQUE or ASSUMEUNIQUE using the ALTER TABLE ALTER COLUMN statement. Instead to add or remove such constraints, you must first drop then add the modified column. For example: ALTER TABLE employee DROP COLUMN empID; ALTER TABLE employee ADD COLUMN empID INTEGER UNIQUE; | |||||
4.3. | Do not use UPDATE to change the value of a partitioning column | ||||
For partitioned tables, the value of the column used to partition the table determines what partition the row belongs to. If you use UPDATE to change this value and the new value belongs in a different partition, the UPDATE request will fail and the stored procedure will be rolled back. Updating the partition column value may or may not cause the record to be repartitioned (depending on the old and new values). However, since you cannot determine if the update will succeed or fail, you should not use UPDATE to change the value of partitioning columns. The workaround, if you must change the value of the partitioning column, is to use both a DELETE and an INSERT statement to explicitly remove and then re-insert the desired rows. | |||||
4.4. | Ambiguous column references no longer allowed. | ||||
Starting with VoltDB 6.0, ambiguous column references are no longer allowed. For example, if both the Customer and Placedorder tables have a column named Address, the reference to Address in the following SELECT statement is ambiguous: SELECT OrderNumber, Address FROM Customer, Placedorder . . . Previously, VoltDB would select the column from the leftmost table (Customer, in this case). Ambiguous column references are no longer allowed and you must use table prefixes to disambiguate identical column names. For example, specifying the column in the preceding statement as Customer.Address. A corollary to this change is that a column declared in a USING clause can now be referenced using a prefix. For example, the following statement uses the prefix Customer.Address to disambiguate the column selection from a possibly similarly named column belonging to the Supplier table: SELECT OrderNumber, Vendor, Customer.Address FROM Customer, Placedorder Using (Address), Supplier . . . | |||||
5. Runtime | |||||
5.1. | File Descriptor Limits | ||||
VoltDB opens a file descriptor for every client connection to the database. In normal operation, this use of file descriptors is transparent to the user. However, if there are an inordinate number of concurrent client connections, or clients open and close many connections in rapid succession, it is possible for VoltDB to exceed the process limit on file descriptors. When this happens, new connections may be rejected or other disk-based activities (such as snapshotting) may be disrupted. In environments where there are likely to be an extremely large number of connections, you should consider increasing the operating system's per-process limit on file descriptors. | |||||
5.2. | Use of Resources in JAR Files | ||||
There are two ways to access additional resources in a VoltDB database. You can place the resources in the
LOAD CLASSES is used primarily to load classes associated with stored procedures and user-defined functions. However, it will also load any additional resource files included in subfolders of the JAR file. You can remove classes that are no longer needed using the REMOVE CLASSES directive. However, there is no explicit command for removing other resources. Consequently, if you rename resources or move them to a different location and reload the JAR file, the database will end up having multiple copies. Over time, this could result in more and more unnecessary memory being used by the database. To remove obsolete resources, you must first reinitialize the database root directory, start a fresh database, reload the schema (including the new JAR files with only the needed resources) and then restore the data from a snapshot. | |||||
5.3. | Servers with Multiple Network Interfaces | ||||
If a server has multiple network interfaces (and therefore multiple IP addresses) VoltDB will, by default, open ports on all available interfaces. You can limit the ports to an single interface in two ways:
Also, when using an IP address to reference a server with multiple interfaces in command line utilities (such as voltadmin stop node), use the @SystemInformation system procedure to determine which IP address VoltDB has selected to identify the server. Otherwise, if you choose the wrong IP address, the command might fail. | |||||
5.4. | Using VoltDB where the /tmp directory is noexec | ||||
On startup, VoltDB extracts certain native libraries into the /tmp directory before loading them. This works in all standard operating environments. However, in custom installations where the /tmp storage is mounted with the "noexec" option, VoltDB cannot extract the libraries and, in the past, refused to start. For those cases where the /tmp directory is assigned on storage mounted with the ‘noexec’ option, you can assign an alternative storage for VoltDB to use for extracting and executing temporary files. This is now done automatically on Kubernetes and does not require any user intervention. On non-Kubernetes environments, you can identify an alternative location by assigning it to
export VOLTDB_OPTS="-Dvolt.tmpdir=/volttemp \ -Dorg.xerial.snappy.tempdir=/volttemp \ -Djna.tmpdir=/volttemp" When using an alternate temporary directory, files can accumulate over time since the directory is not automatically purged on startup. So you should make sure you periodically delete old files from the directory. | |||||
5.5. | Text Data and Character Sets | ||||
Volt Active Data processes and stores text data as UTF-8 encoded strings. When using the Volt Java API, the Java String datatype always stores text in Unicode. So there is no conversion necessary when passing string data to Volt stored procedures. If the application must handle data in alternate character encodings you can use existing Java functionality to convert the data to Unicode on input. For example, using the second argument to specify the character encoding when instantiating a buffered reader: BufferedReader myfile = Files.newBufferedReader(filename,charset); On the other hand, when users enter data interactively using an alternate character encoding, Volt automates the conversion of the character set of the current session to UTF-8 on input and output. In other words, if the user's session is localized to use a specific character set, when entering data at the sqlcmd prompt (for example, when executing an INSERT statement) the data is automatically converted to UTF-8 before processing. Similarly, on output (such as displaying the results of a SELECT statement) the UTF-8 data is converted to the user's localized character set. When processing text files, such as CSV files or sqlcmd scripts, the command line utilities
provide a Finally, which character sets are supported depends on which Java virtual machine (JVM) release you are using on your servers (for export) or client machines (for sqlcmd and csvloader). For established character sets, such as Shift_JIS or ISO-8859-1, all supported JVM releases provide support. For newer character sets, you may need a more recent release of the JVM. For example, the recent Simplified Chinese character set GB18030-2022 requires a JVM released in 2023 or later. For OpenJDK this includes the following releases:
| |||||
5.6. | Using Java 11 in Client Applications | ||||
When running a client application linked against the VoltDB Java API and using the Java 11 runtime, the application may issue warnings about an " illegal reflective access operation." The message does not impact the actual operation of the client or the database itself. You can suppress this warning using the --add-opens qualifier on the java command. For example: $ java --add-opens=java.base/java.lang=ALL-UNNAMED \ --add-opens=java.base/sun.nio.ch=ALL-UNNAMED \ --add-opens=java.base/java.net=ALL-UNNAMED \ --add-opens=java.base/java.nio=ALL-UNNAMED \ myclientapp | |||||
6. Kubernetes | |||||
6.1. | Do not change the UID on the Kubernetes account used to run VoltDB | ||||
In the security context section of the Helm chart for VoltDB, the user account UID is set to 1001. This value is required. Do not change or override any of the following properties when configuring your database:
| |||||
6.2. | OpenShift and Transparent Huge Pages (THP) | ||||
For production, VoltDB requires that Transparent Huge Pages (THP) are disabled because they interfere with memory-intensive applications. However, THP may be enabled on OpenShift containers and the containers themselves not have permission to disable them. To overcome this situation, you must run the Helm chart for disabling THP from a privileged container: $ helm -n kube-system install thp voltdb/transparent-hugepages \ --set thp.securityContext.privileged=true | |||||
6.3. | Kubernetes Compatibility | ||||
See the Volt Kubernetes Compatibility Chart for information on which versions of the Volt Operator and Helm charts support which version of VoltDB. See the VoltDB Operator Release Notes for additional information about individual releases of the VoltDB Operator. |