Release Announcement: InfluxDB Enterprise 1.9.5

By Tim Hall / Product
Oct 11, 2021

Navigate to:

A new maintenance release for InfluxDB Enterprise is now available.

Key highlights for this InfluxDB Enterprise release include:

Memory Utilization Improvement

  • Improvements to the compaction cycle using the TSI index has resulted in a significant reduction in memory usage. In some cases, a 50% reduction in memory usage was observed.
  • The underlying protobuf library has also advanced to the latest version which results in some additional resource efficiency.

Flux Advancement

  • This latest update moves Flux from version 0.120.1 to 0.131.0.
    • Breaking change: removed the sleep() function
    • Added WebEx Teams notification support.
    • Added new Hex package to ease working with hexadecimal string values.
    • Optimized the pivot() transformation.
    • Added InfluxDB sample data package.
    • Now table.fill() is called when aggregateWindow(createEmpty: true) is used.
  • Fixes have been added to address panics caused by queries using limit() and other cases where no data is present.
  • In cases where the replication factor for the database was less than the number of data nodes and datasets with > 1000 points to merge were being returned, the Flux engine encountered issues where some points were not read correctly. This has been addressed.
  • Please join the discussion about Flux via InfluxCommunity or Slack.

Backup/Restore Improvements

The following improvements have been made to the restore process.  Review the documentation for more details on how to take advantage of these improvements:

  • You can now restore data with a new retention policy into an existing database.
    • You can override the duration of a retention policy contained within the backup while restoring.  So, if you backed-up a database with a 30-day retention period, you can restore this and extend the retention period to any duration you wish, including infinite.
    • You can now specify a destination shard when restoring a specific shard.
    • The process of a single-shard restore has been improved to reduce the amount of validation of shards during shard restore, if you specify a new shard. Specifically, the shard just has to have the same index in the shard group (for hashing), and the same start and end time (for queries). Previously, InfluxDB Enterprise also asserted a matching source and destination database, retention policy, and shard group id. This existing behavior is preserved when -newshard is not provided as part of the restore process. Even if -shard is supplied, the metadata is updated if there is a change to the retention policy or database name.

Security

  • If you've configured InfluxDB Enterprise to use LDAP for authentication, LDAP queries that use nested connections to the LDAP server fail to properly use STARTTLS, if configured. The result was that an unencrypted LDAP connection was used for part of the operation.  This has been addressed so that STARTTLS is now used for all connections.
  • influxd-ctl entropy commands could use the incorrect TLS settings to communicate with data nodes if meta nodes and data nodes don't have matching TLS configurations. This has been addressed such that the appropriate TLS settings are now used when working with influxd-ctl entropy.

Eventual Consistency Fixes

  • In some cases the Anti-Entropy service was not reading the remote digest completely. This causes a broken pipe error on the remote node when it tries to write to the closed connection. This issue has been addressed.
    • There are rare situations where shards with overlapping time ranges can exist within the cluster. If overlapping shards do exist, then writing multiple points to those shards resulted in dropped writes with a dropped write error reported to the writer. If only a single point is written, it will succeed. This edge case has been addressed.
    • A race condition was found within the hinted handoff service which was triggered by frequent hinted handoff queue growth and clearing.  In these situations, writes were lost for the remote data nodes.  In these situations, data entropy was introduced or the data could be lost entirely.  This has been addressed.

Logging Improvements

  • Enabling the log format = "json" did not result in all of the log output being in JSON format. This has been addressed.
  • In some circumstances, InfluxDB Enterprise can lose logs for shard writes that time out. Additionally, in situations where InfluxDB Enterprise fails to fully read a TLV for queries and writes in the RPC cluster API, it doesn't log which type of RPC call was attempted. Both of these issues have been addressed.

Again, there is no corresponding InfluxDB OSS 1.9 release. While we continue to make improvements to the InfluxDB 1.x code line and these are being included within InfluxDB Enterprise, we are guiding our community users to InfluxDB 2.x at this time. Of course, you can always build InfluxDB 1.x from source code, if necessary. InfluxDB 2.x does include 1.x compatible interfaces to allow for reads and writes using the 1.x API. The latest open source release can be found on our downloads page.