VoltDB
8.x
VoltDB 9.0 is a major release incorporating features from recent point releases plus new capabilities. The major new features in V9.0 include:
Automated Deletion of Old Data — VoltDB 8.4 introduced a new feature, USING TTL ("time to live"), that lets you define when records expire and can be deleted. This feature simplifies application design by automatically removing old data from the database based on settings you define in the table schema. With VoltDB 9.0, this feature is extended to include the migration of deleted data to other systems for archival purposes, as described next.
New Export Capabilities— The code that supports export of data to external systems has been rewritten to provide flexibility, improve reliability, reduce system resource utilization, and support new and future product features. The new export system reinforces the durability of data queued to the export connectors across unexpected system and network failures and allows export to be extended to add new capabilities.
The first two new capabilities are:
ALTER STREAM — The ability to modify an existing stream. You can use the new ALTER STREAM statement to modify the schema of the stream or the target for export without interrupting any already queued export data. See the description of ALTER STREAM in the Using VoltDB manual for details.
Automated Data Migration — You can now automate the export of data from VoltDB database tables to other systems as part of the data aging process. For tables declared with the USING TTL clause you can now add a MIGRATE TO TARGET clause. With MIGRATE TO TARGET, data that exceeds its "time to live" is queued to the specified export connector. Once the data is exported and acknowledged by the external system, it is then deleted from the VoltDB database. This automated process not only automates the archiving of old data it ensures that the data stays in the VoltDB database until it is confirmed as received by the export target. See the description of the CREATE TABLE statement in the Using VoltDB manual for more information about the USING TTL and MIGRATE TO TARGET options.
Two important aspects of the new export infrastructure are the effect on the overall export process:
Export now starts when the stream is defined, not when the target is defined. Previously, stream data was not queued for export until a valid export connector was configured and connected. This meant data written to a stream might be dropped rather than queued for export if the connector was not configured correctly. Starting with VoltDB 9.0, data written to streams declared with the EXPORT TO TARGET clause are queued for export whether the target is configured or not. Similarly, the queued data is removed as soon as the stream itself is removed with the DROP STREAM statement.
This change makes the queuing of export data much more reliable, easier to understand, and easier to control. Data is queued for export as soon as the stream is defined and purged as soon as the stream is dropped. The new ALTER STREAM statement further lets you modify the stream definition without having to clear any existing export queues.
Export is now an enterprise feature. The VoltDB Community Edition provides access to two streams per database, so users have access to basic export functionality. But for unlimited access to export and migration features, the Enterprise Edition is required. (See Special Considerations for more information about upgrading community databases that use export.)
"Live" Schema Updates with Database Replication — Previously, database replication (DR) required the schema of the cooperating databases to match for all DR tables. So updating the schema required a pause while all of the affected databases were updated. Starting with 9.0, this limitation has been loosened. DR continues even if the schema are different. So it is possible to update the schema without interrupting ongoing transactions.
Of course, it is not possible for VoltDB to resolve individual transactions if the schema differ. So if a DR consumer (either a replica in passive DR or an XDCR cluster in active replication) receives a binary log where the schema of the affected table(s) does not match, DR will stall and wait for the schema to be updated to match the incoming data. Therefore, care must be taken when updating the schema to ensure that no transactions that are affected by the schema change are processed during the interval when the clusters' schema do not match. See the sections on updating DR schema for passive and active DR for more information.
Simplified JSON interface — A new version of the VoltDB JSON API, 2.0, is now available. The original JSON interface provides complete information about the schema for the data being returned, including separate entries for the data, the column names, and datatypes. The 2.0 API returns a much more compact result set with each row represented by an associative array with each element consisting of the column name and value.
The 1.0 API is useful if you do not know what data is returned and want to deconstruct the results in detail. The 2.0 API is more useful for rapidly fetching and using known results. Both versions of the API accept the same parameters, as described in the section on using the JSON API in the Using VoltDB manual. So the following calls return the same data except at different levels of detail.
http://myserver:8080/api/1.0/?Procedure=@Statistics&Parameters=["TABLE",0] http://myserver:8080/api/2.0/?Procedure=@Statistics&Parameters=["TABLE",0]
Support for Java 11 — VoltDB now supports both Java 8 and Java 11.
Many of the new features and capabilities in VoltDB V9.0 do not impact existing applications. However, there are a few changes that may require action for users upgrading from earlier versions. Existing customers should take note of of the following changes:
Change to how stream data is queued for export
Previously, if you defined a stream with the EXPORT TO TARGET clause but no matching target was configured, any data inserted into the stream was dropped. No data was queued until the specified target was both configured and successfully connected. With VoltDB 9.0 export queuing has been simplified: data is queued as soon as the stream is declared and the queue is deleted as soon as the stream is dropped.
This means that if you declare a stream and it is being written to, but you do not configure the associated
target, the data inserted into the stream will be queued in the export_overflow directory,
consuming disk space that would not have been used in earlier versions of the product.
Change to the reporting of streams in @Statistics
In VoltDB 8.4, a new @Statistics selector, EXPORT, was introduced to provide improved visibility and more detail concerning the export lifecycle. At that time, export streams continued to be reported under the TABLE selector, so as not to disrupt existing scripts or procedures users might have that rely on that information. With VoltDB 9.0, export streams have been removed from the TABLE selector results. Now the TABLE selector only reports on tables and streams that are not associated with an export target. Information on streams declared with the EXPORT TO TARGET clause is provided under the EXPORT selector.
Managing export queues during outages
In most cases, VoltDB manages the export queues even in unusual cases where nodes go down in a K-safe cluster. If at any time the node managing an export partition finds a gap in the export queue (due to the current server having been down when that data was written to the stream), the system queries the other servers to find one with the missing data and export continues. In the rare case where VoltDB cannot find the missing records in any of the current server export queues, the export connector for that queue will stop, waiting for a server that has the data.
Even if servers stop and rejoin frequently, the data will eventually be found on a rejoining node. However, in the unusual case that, say, failed nodes are replaced by new, initialized servers, it is possible that the gap in the queue cannot be resolved. Previously, VoltDB would eventually (once the cluster was at a full complement of servers) skip the missing data and restart the connector at the next available export record. Starting with VoltDB 9.0, export will not skip over gaps automatically. The queue will stop and warnings will be logged to the console and reported via SNMP. You must issue the voltadmin export release command to resume processing of the export connector at the next available record.
Limits on streams in Community Edition
Export is now an Enterprise Edition feature and the Community Edition is limited to two streams per database. This means if you try to restore a database from a previous version with more than two streams using the VoltDB 9.0 Community Edition, the restore will fail. If this happens when upgrading, you can initialize a new database root, load the schema without the additional streams, then manually restore the data.
Support for CentOS and RHEL 6 removed
The officially supported platforms for VoltDB have been updated. CentOS and RHEL version 6 are no longer officially supported. The current list of supported platforms include CentOS and RHEL version 7.0 or later, Ubuntu versions 14.04, 16.04, and18.04, and Macintosh OS X 10.9 or later.
Support for export and import to Kafka 0.8.2 removed
The Kafka import and export connectors now require Kafka version 0.10.2 or later.
Logging name change from JOIN to ELASTIC
The log4J logger reporting on elastic changes to VoltDB clusters has been renamed from JOIN to ELASTIC.
Documentation