What’s New in Version 7.1

Prior to Couchbase Server Version 7.1, Analytics Service data was not replicated. This meant that when an Analytics node failed over, the Analytics Service stopped working cluster-wide. If the failed-over Analytics node was then recovered, data ingestion had to begin again from scratch.

Analytics shadow data may now be replicated up to 3 times. When replicas exist, and an Analytics node fails over, the Analytics Service continues to work: one of the replicas is promoted to serve the shadow data stored on the failed over node. If the failed-over Analytics node is then recovered, the shadow data on the recovered node is updated from the promoted replica.

Analytics replicas can be managed using the user interface, the setting-analytics command line tool, or the Analytics Settings REST API. For further details, refer to General Settings.

Analytics replicas can also be monitored using the Analytics Cluster Status REST API. Refer to Cluster Status.

Analytics now supports Analytics views, which are virtual Analytics collections derived from actual stored Analytics collections. Analytics views might be used to present a subset of the stored data, or to present a join or other transformation of stored data for some particular purpose. Queries may operate on Analytics views in exactly the same way as they do on real stored data.

Analytics also supports tabular Analytics views, a type of view that presents data in the form of a table with uniform rows and columns and with a well-defined schema. Tabular views enable Analytics to interact with software tools that are designed for relational databases, such as Tableau.

For further details on Analytics views and tabular Analytics views, refer to Analytics Views.

The new Tableau Connector provides integration between Couchbase Analytics tabular views and the Tableau interactive data visualization platform. Refer to Introduction.

The Analytics Service now supports external datasets on Azure Blob storage. These may be managed using the UI or the Analytics Links REST API. Refer to Managing Links and Analytics Links REST API.

Analytics now provides array indexes, which enable you to index values within an array, or fields within an object nested in an array. In Analytics, array indexes are not meant to serve as covering indexes. Instead, array indexes are simply meant to accelerate queries involving multi-valued fields. For further details, refer to Using Indexes.

The data definition language has been extended to support the creating and dropping of array indexes. Refer to Data Definition Language (DDL).

Prior to Couchbase Server Version 7.1, the cost-based optimizer was unable to rewrite queries to use the optimal join order. Joins were performed in the order in which they are specified in the query, and no reordering of joins was considered.

The cost-based optimizer may now consider different join orders, and can choose the optimal join order based on cost information. This is the default behavior when the cost-based optimizer is active and the optimizer statistics are up-to-date. Refer to Cost-Based Optimizer.

You can use an optimizer hint, if required, to over-ride the cost-based optimizer and specify that the query should use the join order as written. Refer to Query Block Hints.

You can now include optimizer hints within queries to supply directives to the optimizer. Optimizer hints request that the optimizer should consider specific indexes, join methods, join ordering, and so on, when creating the plan for a query. This may be useful in situations where the optimizer is not able to come up with the preferred plan, due to lack of optimizer statistics, high level of skew in data, data correlations, and so on.

You can supply hints to the operator within a specially-formatted hint comment, similar to the type of hint comment found in many relational databases. Many optimizer hints have legacy equivalents using the USE clause. For further details, refer to Optimizer Hints.

Prior to Couchbase Server Version 7.1, a Couchbase-Server cluster could maintain at most one root certificate: all nodes and all clients were obliged to rely on this certificate’s authority. From version 7.1, Couchbase Server permits multiple root certificates to be maintained in a trust store for the cluster. This allows an individual node either to use a CA that is also used by one or more other nodes; or to use a CA that is used by no other node. This procedure may be used during CA certificate rotation: a new CA is uploaded, node certificates are changed one by one, and finally, the old CA is removed.

Couchbase Server additionally uses its list of trusted certificates to verify:

For more information, see Using Multiple Root Certificates.

Note that prior to Couchbase Server Version 7.1, node-to-node encryption, which is managed by means of the Couchbase CLI, needed to be disabled before management of either root or intermediate certificates could be performed. This restriction is lifted in version 7.1: therefore, root and intermediate certificates can now be managed while node-to-node encryption is enabled.

Prior to Couchbase Server Version 7.1, running Functions under the Eventing Service required admin permissions of either "Full Admin" or "Full Eventing Admin".

This limiting restriction is lifted in version 7.1. Now any user can securely create or manage Eventing Functions provided they have proper RBAC permissions configured.

Use of encrypted private keys is now supported for certificate management.

In version 7.1, Couchbase Server supports PKCS #1 and PKCS #8 — in each case, only for use with private keys:

If a node-certificate to be loaded is associated with an encrypted private key, a procedure can be defined to allow Couchbase Server to access and use the key’s passphrase, when use of the key is required: the passphrase can be registered by means of a JSON object. For information, see JSON Passphrase Registration.

System events are generated to record significant occurrences on the cluster. Events are provided for the Cluster Manager, the Data Service, the Index Service, the Search Service, the Eventing Service, the Backup Service, and the Analytics Service. Events are also generated for XDCR, security, and Views.

Each event is provided as a JSON document containing a number of key-value pairs: some key-value pairs are included in all system events, others are specific to the service for which the event is generated. Each key-value pair provides definitive information on the event.

For detailed information, see System Events.

New roles are provided for the administration of Sync Gateway, especially in the context of Couchbase Capella. These roles are listed at Roles.

TLS 1.3 cipher-suites can now be used by all services; and by the Cluster Manager, XDCR, and Views. For information, see On the Wire Security.

XDCR checkpointing is now entirely persistent through topology-changes on the source cluster. This provides improved performance when failover and rebalance occur on the source cluster.

Amazon Linux is now supported on the ARM platform. See Release Notes for Couchbase Server 7.1 and Supported Platforms.

ENTERPRISE EDITION

The new Magma Storage Engine has been added to 7.1 as an Enterprise Edition feature, allowing for higher performance with very large datasets. Magma is a disk-based engine, so is highly suited to datasets that will not fit in available memory. You can find more details on Magma in Storage Engines.

The Plasma Storage Engine has been enhanced, with per page Bloom filters and in-memory compression. For information, see Plasma Memory Enhancements.

Automatic failover can now fail over more than three nodes concurrently: this has permitted the removal of pre-7.1 interfaces that were specific to triggering auto-failover for server groups. Consequently, in order now to ensure successful auto-failover of a server group, the maximum count for auto-failover must be established by the administrator as a value equal to or greater than the number of nodes in the server group.

Note that the pre-7.1 interfaces for triggering auto-failover for server groups have been removed from 7.1: therefore, programs that attempt to use the pre-7.1 interfaces with 7.1+ will fail.

In 7.1+, automatic failover of the Index Service is supported. Improvements have also been made to rebalancing algorithms, so that active buckets, services, and replicas will be spread across different server groups, even when server groups are unequal.

Updated interfaces for 7.1+ are documented in Node Availability, Enabling and Disabling Auto-Failover, and Retrieving Auto-Failover Settings. For an overview of automatic failover, see Automatic Failover. For information on server groups, see Server Group Awareness.

A number of improvements have been made to Full-Text Search:

The Index Service now provides:

The following features have been added in 7.1.2.