A newer version of this documentation is available.

View Latest

Release notes for version 4.1

Couchbase Server release 4.1 extends Couchbase lead as the most performant and scalable NoSQL database for mission critical enterprise applications.

Release Notes for 4.1.2

Released in August 2016, Couchbase Server 4.1.2 is the second maintenance release in the 4.1.x series. This maintenance release has several bug fixes related to DCP, indexing, querying, XDCR, and security.

Fixed issues in 4.1.2

Here are the notable fixes in the 4.1.2 release:

Issue Description

MB-20312

Key value engine task will run at HIGH or LOW, but not guaranteed at the requested priority.

MB-20236

Indexer process uses large amounts of CPU and RAM when no indexes are configured.

MB-20182

When upgrading from 2.5.x to 4.x.x, TAP followed by DCP can result in a failure.

MB-20153

When running multiple N1QL clients with request cancellation or low scan timeout values, a race condition in connection shutdown causes the indexer to crash.

MB-20105

Purge Seqno would be reset in case there was a compaction call that was not purging any items, causing tombstone items not to be purged.

MB-20102

Purge Seqno is incorrectly passed to the compactor for development design documents preventing Couchbase Server from reclaiming the disk space.

MB-20047

When using cbdocloader and loading files from disk, the documents are loaded except for the design documents, which are silently skipped.

MB-20008

Security upgrade for curl to version curl 7.49.1.

MB-19843

The View engine fails with DCP start sequence number that is greater than end sequence number error and fails to roll back. This behavior can cause view engine indexing issues.

MB-19837

By default, increase the number of non-IO threads to stay on top of all ready tasks.

MB-19832

XDCR would temporarily get stuck in a loop when a node, which was previously removed from a cluster, rejoins the cluster in the situation where there are multiple Couchbase Server versions in the cluster and no mutations had previously been replicated.

MB-19802

When XDCR getMeta receives an error that is not a network timeout type, it repairs network connection and continues in a loop to read from the client until a timeout occurs after 2 minutes. In this window, XDCR replication appears stuck.

MB-19757

MB-19608

TLS configuration on the port 11207 is lost on server restart.

TLS configuration on the port 11208 is lost on server restart.

MB-19714

After lots of document UPSERT operations, high CPU utilization remains for nodes with GSI indexes for an indefinite time even if there are no more UPSERT operations.

MB-19697

More than one XDCR replication instance might start after replication is resumed, resulting in incorrect functional behavior and performance impact.

MB-19659

select count(*) does not work correctly when used in a prepared statement.

MB-19635

An offline upgrade from Couchbase Server version 2.5 to any version of a Couchbase Server release 3.x could result in a potential data loss.

MB-19599

The Couchbase Web Console and REST API over HTTPS do not work for center web clients such as Chrome 50 or higher that are sending elliptic curve X25519 requests for TLS.

MB-19503

Under a low mutation rate, long pauses can occur when updating View indexes.

MB-19473

Fixed incorrect an error message for Go-XDCR when upgrading with swap-rebalance from Couchbase Server version 3.x.

MB-19371

When switching from full eviction to value eviction, if the total metadata is bigger than the memory quota of the bucket keys will not be loaded even when warmup is complete and the bucket is online.

MB-19364

Memcached bucket will cause the query select * from system:keyspaces to fail.

MB-18975

In a multi-node cluster, two cbq shell sessions connected to distinct nodes have a window where index metadata is not fully synchronized.

MB-18949

GOXDCR needs to handle NOT_MY_VBUCKET errors more gracefully, without restarting.

MB-18453

When a high-priority task is busy, tasks of lower priorities never have a chance to run and have been observed waiting for many hours. This behavior can, for example, result in a node failover caused by the lack of response to statistics calls.

MB-18452

If a DCP consumer is hit with more data than it can consume, it will run the Processor task for as long as this situation continues resulting in NON-IO threads being held and preventing other NON-IO tasks from running.

MB-16766

The Cluster manager continuously crashes on an undersized system

See the following link for a full list of issues.

Known issues in 4.1.2

The following are the known issues:

Issue Description

MB-16831

Summary: When creating a Global Secondary Index (GSI), the interactive query shell cbq can time out if the result is not returned within 2 minutes. Although the index is successfully created, the error message is unclear.

Workaround:Create the index with defer_build:true and then build the index separately.

MB-16618

Summary: When the View queries with the options reduce and group set to true are parameterized by a list of keys that are not listed in ascending order, the produced results might not be properly reduced.

Workaround: Ensure that the list of keys passed to the query is in ascending order.

Release Notes for 4.1.1

Couchbase Server 4.1.1, released in April 2016, is a first maintenance release for Couchbase Server 4.1. It further fortifies Couchbase Server 4.1.0 and includes some critical bug fixes.

Fixed issues in 4.1.1

Here are the notable fixes in the 4.1.1 release:

Issue Description

MB-19093

Data Service (memcached) can lock up when replica indexes for Views are enabled.

MB-18794

XDCR replication can stop working when nodes are rebalanced out of the target cluster.

MB-18651

Indexer service can pick up a wrong index file after being restarted during compaction, causing the index to have partial data.

MB-18476

Data Service (memcached) on windows can crash when failing to write to disk.

MB-18251

When using primary indexes on Windows, the Query service does not release connection to the data service.

MB-18133

XDCR upgrade process can fail when upgrading from pre-4.X Couchbase Server versions when a remote cluster is unreachable.

MB-18018

Improvement: New private setting to block TLS version 1.1 and lower for SSL.

MB-17815

Data service (memcached) can count operations twice when the bucket is using full eviction mode, and the operation has to go to disk.

MB-17758

XDCR does not recover in some cases when there is a network partition between target and source clusters.

MB-17517

When an invalid CAS is discovered, one of the following situations can occur:

  • The Data service (memcached) will crash when arithmetic operations operate on an invalid CAS.

  • CAS operation will incorrect work when a CAS mismatch should have been generated.

An invalid CAS can only be created when the cluster has been upgraded from Couchbase Server 2.X, and the locks operations have been used.

MB-17506

Improvement: New private setting is needed that allows disabling the cluster map being included in a Not My VBucket response from the server to the client. The above situation might in some cases reduce network bandwidth between clients and the cluster during a rebalance.

MB-17481

XDCR uses more network bandwidth than expected due to stats collection.

MB-17341

Data Service (memcached) can crash when the Cluster Manager incorrectly sets up the DCP streams to dead vBuckets.

MB-17297

XDCR does not handle incomplete HTTP response causing replication to fail. This only affects XDCR to Elasticsearch.

MB-17279

Data service (memcached) can crash when a race condition is triggered by rebalancing that was abruptly terminated.

MB-17231

Data service (memcached): Increment/decrement operation will hang when used on buckets with full eviction mode.

MB-17174

Cbcollect_info would take a lot space and a long time to run on clusters with a large amount of data.

MB-17148

Query Service Count(*) with USE KEYS returned the incorrect results.

MB-17088

Data service (memcached): Stats can be incorrect because of an integer underflow.

MB-17024

Improvement: Data Service (memcached) has better logging around bucket deletion .

MB-17009

Index service’s initial Global Secondary Index builds could hang with larger data sets.

MB-16949

Data service (memcached): A small memory leak was caused by DCP backfill manager.

MB-16915

Data service (memcached) crash caused by a race condition when a DCP producer is closed while a backfill task is running. This can happen when rebalancing is terminated or when XDCR connections are terminated.

MB-16910

Memcached.log can contain an unexpectedly large number of "warmup is complete" messages after the warmup.

MB-16836

Data service (memcached) cbstats reset command does not reset ep_bg_fetched stat.

MB-16656

Rebalancing can fail when replica indexes are enabled on Views as the Data service is returning the incorrect high sequence number to the View engine.

MB-16632

Improvement: Reduced lock contention inside the Data service in some cases by reducing CRUD operation latency.

Known issues in 4.1.1

The following are the known issues:

Issue Description

MB-18564

Summary:cbbackupwrapper on Windows requires that the file path of the cbbackup process has no spaces.

Workaround:Copy cbbackup.exe into a path with no spaces ( such as c:\couchbase)

MB-16831

Summary:When creating a Global Secondary Index (GSI), the interactive query shell cbq can timeout if the result is not returned within 2 minutes. Although the index is successfully created, the error message is unclear.

Workaround:Create the index with defer_build:true, and then build the index separately.

MB-16618

Summary:View queries with the options reduce and group set to true when parameterized by a list of keys that are not in ascending order can produce results that are not properly reduced.

Workaround: Ensure that the list of keys passed to the query is in ascending order.

Release Notes for 4.1

Known Issues

The following table lists the known issues in the 4.1 release:

Release Notes for Couchbase Server 4.1

Known issues

The following table lists the known issues in the 4.1 release:

Issue

Description

MB-17004

Summary: When using queries backed by GSI to perform singleton lookups and range scans, occasional processing of index compaction can incur long pauses affecting concurrent query throughput.

MB-16939

Summary: Prepared encoded plan for N1QL statements with system catalog queries in WHERE clause may not be recognized.

Workaround: To avoid this issue, do not execute certain queries with prepared statements (known as .adhoc(false) or similar in SDK APIs). Instead, use regular queries with system catalog queries.

MB-16935

Summary: Kernel futex wait call can cause ForestDB to hang during initial index build.

Workaround: If you are running RHEL 6x or CentOS 6.x, we highly recommend upgrading to the latest kernel (2.6.32-504.16.2 or higher). With Centos 7.1, you should upgrade to Linux kernel 3.18 at least.

MB-16902

Summary: Latency on queries using the request_plus option on scan consistency may be abnormally high during index compaction, leading to application timeouts of queries. The response times may occasionally be in the 10s of seconds or the query may return an error due to timeout. The default timeout interval is 75 seconds.

Workaround:

MB-16831

Summary: When creating a global secondary index (GSI), the interactive query shell cbq, can timeout if the result is not returned within 2 minutes. Although the index is successfully created, the error message is unclear.

Workaround:Create the index with defer_build:true, and then build the index separately.

MB-16618

Summary: View queries with reduce and group set to true, and parameterized by a list of keys that are not in ascending order, can produce results that are not properly reduced.

Workaround: Ensure that the list of keys passed to the query is in ascending order.

MB-16115

Summary: When the indexer settings are changed, the connections from the query shell cbq can sometimes become stale causing an EOF errors.

Workaround: Restart the query engine before executing the query again.

MB-15968

Summary: Replication over SSL encryption from a source 4.0 cluster to a destination 2.5.x cluster may result in slow performance (rate of data transfer).

Workaround: We recommend upgrading the destination cluster to 3.x version.

Fixed issues

Here are some of the notable fixes in the 4.1 release:

Issue

Description

MB-16689

Memcached process crashed if it ran out of file descriptors during log rotation.

MB-16528

If delta-node recovery was started after updating the bucket configuration, but before the bucket was loaded into memcached, a rebalance operation sometimes ejected the node from the cluster and the cluster vBucket map still contained the node

MB-16435

Couchbase Server failed to start on OS X 10.11 (El Capitan).

MB-16421

If a getMeta was issued at the destination cluster during XDCR followed by a GET request by the client, the background fetch operation for the item did not complete and caused a large number of disk reads and client side timeouts.

MB-16389

When deletion of a large bucket happened in the background, rebalance was disabled, and the status of the ongoing background task was shown in the UI.

MB-16385

Querying a view with a reduce function based on a subset of partitions resulted in a massive memory usage.

MB-16357

If a vBucket state changed from active to replica while performing compaction, the race condition between the compaction thread and memcached thread sometimes caused an assertion and triggered a crash.

MB-16244

Running the Elasticsearch connector sometimes resulted in high CPU usage.

MB-16159

DCP consumer would consistently take 6 seconds to acknowledge a 20Mb mutation.

MB-16125

Memcached would sometimes hang during shutdown.

MB-16067

On a Windows system, the XDCR remote cluster reference was not updated after a node was removed from the cluster.

MB-16013

XDCR based on DCP consumed a large amount of RAM with large mutations.

MB-15876

When using XDCR with SSL, replication to an older cluster failed after an online upgrade to 4.0 and an error message that the pipeline failed to start was received.

MB-13948

The mapping phase of the view MapReduce operation took a lot of memory if lots of key-value pairs were emitted per document.

For the complete list of issues fixed in 4.1 release, see the following JIRA query.