DOC-14228--Create-release-note-for-Totoro--8.1

modules/install/pages/install-platforms.adoc

@@ -31,7 +31,7 @@ a|* AL2023 (x86-64, ARM64)
 | Debian
 a| * 13.x
 * 12.x
-* 11.x
+* 11.x (Deprecated)
 
 | Oracle Linux{empty}footnote:[Only the Red Hat Compatible Kernel (RHCK) is supported.
 The Unbreakable Enterprise Kernel (UEK) is not supported.]

modules/release-notes/pages/relnotes.adoc

@@ -9,6 +9,9 @@ These release notes are focused on bug fixes and breaking changes.
 
 For information about new features and major improvements made in Couchbase Server 8.0, see xref:introduction:whats-new.adoc[What's New].
 
+include::partial$docs-server-8.1-fixes-and-improvements.adoc[]
+include::partial$docs-server-8.1-platform-changes.adoc[]
+'''
 include::partial$docs-server-8.0.1-fixes-and-improvements.adoc[]
 include::partial$docs-server-8.0.1-known-issues.adoc[]
 ''''

modules/release-notes/partials/docs-server-8.1-fixes-and-improvements.adoc

@@ -0,0 +1,335 @@
+
+
+
+[#release-81]
+== Release 8.1 (June 2026)
+
+Couchbase Server 8.1 was released in June 2026.
+This maintenance release contains fixes to issues.
+
+[#dlist-fixed-issues-81]
+== Fixed Issues
+
+
+
+
+[#dlist-fixed-issues-81-cluster-manager]
+=== Cluster Manager
+
+*https://jira.issues.couchbase.com/browse/MB-70629/[MB-70629]*::
+
+RBAC groups containing security_admin_local,
+security_admin_external,
+or ro_admin roles are not handled correctly on upgrade to 8.0. The upgrade handling should replace:
+
++
+
+--
+
+* security_admin_local with security_admin + local_user_admin
+* security_admin_external with security_admin + external_user_admin
+* ro_admin with ro_admin + ro_security_admin
+
+--
+
++
+
+The issue also occurs when restoring users from a backup taken on a release prior to 8.0.
+
++
+
+The workaround for both the upgrade and restore case is to manually correct the affected users after the upgrade/restore completes.
+
+*https://jira.issues.couchbase.com/browse/MB-70951/[MB-70951]*::
+
+The following stats were reported twice by the `/metrics` REST API.
+This has been corrected to only report each once.
+
++
+
+`<count>cm_rest_request_enters_total{}<count>`
+
++
+
+`<count>cm_rest_request_leaves_total{}<count>`
+
+
+
+[#dlist-fixed-issues-81-data-service]
+=== Data Service
+
+*https://jira.issues.couchbase.com/browse/MB-68779/[MB-68779]*::
+
+The latest update addresses an issue where the unit conversion for `kv_ep_commit_time_total_seconds` was incorrect and resulted in a loss of precision. This defect stemmed from previous configurations that inaccurately reported commit time statistics. In response,
+the commit related to the change has been integrated,
+implementing a modification to utilize microseconds for enhanced precision in commit time statistics. This alteration ensures accurate representation and recording of time metrics,
+aligning with the intended precision standards. Users can expect improved and precise tracking of commit durations following this update. The adjustment reflects a commitment to maintaining data integrity and accuracy in system operations.
+
+// generated by openai:gpt-4o
+
+
+
+*https://jira.issues.couchbase.com/browse/MB-69568/[MB-69568]*::
+
+The bucket state named "clients" however it tracks all sort of clients currently holding a reference to the bucket (this could be other subcomponents _within_ the same process trying to iterate over buckets etc).  Therefore a new stat is introduced called `curr_bucket_connections`, to track client connections.
+
+*https://jira.issues.couchbase.com/browse/MB-70471/[MB-70471]*::
+
+In a recent update,
+two redundant parameters,
+magma_max_default_storage_threads and magma_flusher_thread_percentage,
+have been removed from the bucket configuration settings. This change comes as these parameters have not been actively utilized since version 7.6.10,
+having been superseded by their global equivalents within memcached. Typically,
+these settings are reserved for internal system configuration; customers should adjust them only with explicit instructions from support. The update is incorporated into the new build of the software,
+reflecting ongoing efforts to streamline operations and improve system efficiency by phasing out obsolete settings.
+
+// generated by openai:gpt-4o
+
+
+
+
+
+[#dlist-fixed-issues-81-views]
+=== Views
+
+*https://jira.issues.couchbase.com/browse/MB-67213/[MB-67213]*::
+
+*Metric Rename – Cache Miss Ratio → Get Miss Ratio*
+The _Cache Miss Ratio_ metric name suggested it measured memory or disk caching performance.
+In reality,
+as of version 7.6.2, it was redefined to measure the proportion of read (`get`) operations that fail because the requested key is not present in the bucket at all.
+ To eliminate this confusion,
+the metric has been renamed to *Get Miss Ratio*.
+
+*https://jira.issues.couchbase.com/browse/MB-67280/[MB-67280]*::
+
+*Change to Bucket Priority Settings*
+
++
+
+As part of improving background task scheduling,
+we have replaced the legacy implementation with a standardized,
+more advanced scheduler.
+As a result,
+setting a bucket's priority to high or low no longer affects system behavior.
+Consequently,
+the option to set bucket priority has been removed from the UI.
+
++
+
+Previously,
+task scheduling relied on a basic two-priority queue (high and low), which had limitations—such as busy polling.
+The new scheduling mechanism (introduced in MB-36956) eliminates these issues.
+
++
+
+NOTE: Bucket priority settings are still available via the REST API and CLI to maintain compatibility with existing customer scripts and tooling.
+
+
+
+[#dlist-fixed-issues-81-xdcr]
+=== XDCR
+
+*https://jira.issues.couchbase.com/browse/MB-68340/[MB-68340]*::
+
++Note on deprecation of internal settings+ `UprFeedDataChanLength` +and+ `UprFeedBufferSize`:
+
++
+
+To allow for finer-grained control over the footprint of an individual pipeline,
+this change deprecates internal settings `UprFeedDataChanLength` and `UprFeedBufferSize` (which would apply one value to all replications), in favour of a new replication setting `dcpFlowControlThrottle`.
+
++
+
+`dcpFlowControlThrottle` is a percentage (legal values in the range `[5, 100]`), which will be applied to the previous default values of both `UprFeedDataChanLength` (`20000`) and `UprFeedBufferSize` (`1024*1024 bytes`). Thus users can now specify a common percentage for both the values instead of specifying them individually.
+
++
+
+As a result of this,
+following care needs to be taken until all nodes in the cluster have been upgraded:
+
+. New replications MUST be created via the upgraded nodes (either API request or UI)
+
+. All https://docs.couchbase.com/server/current/rest-api/rest-xdcr-adv-settings.html#xdcr-advanced-settings-rest[replication settings] changes (especially to the new settings `dcpFlowControlThrottle` and `componentEventsChanLength`) MUST be made via the upgraded nodes (either API request or UI)
+
+. The change is resilient to replication "pause" & "resume" being triggered from legacy nodes.
+However,
+it is still advised to do so via the upgraded nodes.
+
+.. All internal-setting changes MUST be made via the legacy nodes.
+
+. If the internal-settings `UprFeedDataChanLength` and `UprFeedBufferSize` on the legacy nodes were set to a value other than their default (20000 and 1048576, respectively), then they need to be set on the upgraded nodes by updating the `dcpFlowControlThrottle` replication-setting.
+
++
+
+General documentation changes will be mentioned in https://jira.issues.couchbase.com/browse/DOC-13921[DOC-13921]
+
+*https://jira.issues.couchbase.com/browse/MB-70844/[MB-70844]*::
+
+In this release,
+an issue with document replication when the target is locked has been addressed. Previously,
+the change in behavior of sub-document multi-lookup operations on locked documents led to complications. These operations began allowing reads instead of delivering a "Resource Locked" response,
+affecting the replication process. As a result,
+the replication was prematurely marking source documents as failed. The solution involves identifying locked documents by checking if the response has the document's CAS set to its maximum value. This ensures that processes recognize the locked status,
+allowing for proper continuation of replication attempts. This resolves previous misinterpretations that were resulting in incorrect statuses being assigned during replication. The change is applicable to all versions utilizing sub-document multi-lookup when replicating to version 8.0.0 and higher.
+
+// generated by openai:gpt-4o
+
+
+
+*https://jira.issues.couchbase.com/browse/MB-71244/[MB-71244]*::
+
+When pausing or deleting a replication that is replicating to or from a cluster that recently underwent a failover and needs to rollback to 0, there could be a race condition that causes the goroutines to be stuck indefinitely.
+This has now been fixed.
+
+
+
+[#dlist-fixed-issues-81-query-service]
+=== Query Service
+
+*https://jira.issues.couchbase.com/browse/MB-68969/[MB-68969]*::
+
+* With multi-collection indexes that contained fields with `include in _all` setting enabled - there was a possibility for false positives to show up for field agnostic (composite field) queries.
+This has been addressed by denying the sargability for such indexes.
+* Addressed an issue where fields not belonging to a particular keyspace were being included in multi-collection indexes.
+* Addressed a bug that could influence composite field (`_all`) availability based on the order in which fields were processed.
+
+*https://jira.issues.couchbase.com/browse/MB-69081/[MB-69081]*::
+
+To retrieve a document's expiration,
+the user had to specify the sub-path explicitly,
+i.e., `META().expiration`. A call to the `META()` function without the sub-path would return the default expiration value 0 always which was incorrect.
+
+
++
+
+Now,
+when a user's query invokes the `META()` function without explicitly specifying the subpath,
+the document's expiration value is returned.
+
+*https://jira.issues.couchbase.com/browse/MB-69083/[MB-69083]*::
+
+Problem:
+
++
+
+A query may return an incorrect result under the following conditions:
+
++
+
+* query contains one or more joins
+* one of the joins involves a sub-query (FROM clause subquery)
+* the FROM clause sub-query has a GROUP BY and/or aggregates
+* the FROM clause sub-query can take advantage of index group/aggregate pushdown
+(this requires an appropriate secondary index)
+* CBO is ON,
+and UPDATE STATISTICS has been run on all keyspaces/indexes involved
+
+*https://jira.issues.couchbase.com/browse/MB-69955/[MB-69955]*::
+
+`CYCLE` was added as a KEYWORD for RECURSIVE WITH's CYCLE subclause.
++
+This causes a syntax error when a path or subpath's case-insensitive identifier is named `cycle`  when users upgraded to a version that supported the recursive with feature https://docs.couchbase.com/server/current/n1ql/n1ql-language-reference/with-recursive.html[WITH recursive clause]
++
+This is now handled by allowing `cycle` keyword as a permitted identifier.
+
+*https://jira.issues.couchbase.com/browse/MB-70112/[MB-70112]*::
+
+When a prepared request is made with the  `auto_execute` request parameter set as `true`, the request would incorrectly error out with error: `Unrecognizable prepared statement - cause: JSON unmarshalling error: auto_execute did not produce a prepared statement`
++
+In this release the server silently ignores the `auto_execute` request parameter when the request is a prepared request.
+
+*https://jira.issues.couchbase.com/browse/MB-70543/[MB-70543]*::
+
+Execution of a scope-level UDF (user-defined function) may fail and get `Invalid Function` error under the following conditions:
+
+* Running Couchbase Server version 7.6.0 through 7.6.10.
+* A query node is starting.
+* The query node is NOT being upgraded from an earlier version (for example,
+7.2)
+* A scope-level UDF was already present (created before the query node started)
+* A call to execute the scope-level UDF is issued against the query node shortly after the query node started.
+
+*https://jira.issues.couchbase.com/browse/MB-70745/[MB-70745]*::
+
+A restore may fail under the following conditions:
+
+* Couchbase version 7.6.0 through 7.6.10
+* CBO (Cost-Based Optimizer) was enabled
+* An index exists where one of the index keys contains `'::'`, for example,
+`SPLIT(<field>, "::")`
+* UPDATE STATISTICS (or ANALYZE) has been run on the index
+* a backup was taken after UPDATE STATISTICS was run
+* a restore was attempted with the backup
+
+
+
+
+
+
+
+
+
+[#dlist-fixed-issues-81-search-service]
+=== Search Service
+
+*https://jira.issues.couchbase.com/browse/MB-68681/[MB-68681]*::
+
+In response to an identified issue with potential crashes due to excessive partition counts in resource-constrained environments,
+a maximum limit on the number of partitions per index has been established,
+ensuring it aligns with the maximum number of vbuckets. This enhancement is aimed at preventing out-of-memory errors that were observed when an excessive number of partitions was configured,
+particularly on a single node with abundant metadata and associated agents. By setting this partition cap,
+resources are better managed,
+promoting stability and reliability. The decision to establish a limit,
+suggested at 256 partitions per index,
+was devised after thorough examination and is tracked under the improvement initiative,
+internally referred to as "totoro." These changes are now incorporated into the system as part of an ongoing commitment to optimize and safeguard the search service’s operational integrity.
+
+// generated by openai:gpt-4o
+
+
+
+*https://jira.issues.couchbase.com/browse/MB-70388/[MB-70388]*::
+
+Fixed an issue where we did not set `docvalues` for `geopoint` fields internally,
+causing it to be computed on demand for every query
+
+
+
+[#dlist-fixed-issues-81-tools]
+=== Tools
+
+*https://jira.issues.couchbase.com/browse/MB-68392/[MB-68392]*::
+
+In the latest update,
+backup functionality with S3 introduces a necessary change regarding versioning permissions for working with WORM repositories or backups. Users have the option to enable versioning permissions by default,
+which eliminates the UX differentiation between WORM and non-WORM backups. Alternatively,
+those who choose not to use these permissions can continue with non-WORM operations by applying a specific flag. This update addresses a previous regression,
+ensuring a smoother user experience by printing a warning instead of enforcing extra permissions. The preferred approach enhances clarity and minimizes potential bugs,
+aiding in seamless backup operations.
+
+// generated by openai:gpt-4o
+
+
+
+*https://jira.issues.couchbase.com/browse/MB-69453/[MB-69453]*::
+
+Enhancements have been introduced to facilitate the selection and restoration of cbbackupmgr backups based on a specific target time. These updates optimize the operational efficiency by moving restore and transfer state writers to a dedicated package and consolidating plan resources. The restoration plans now conveniently write to a temporary directory. To improve user experience,
+the contbk restores are now resumable,
+providing greater flexibility during restoration. As part of these changes,
+the process of creating and resuming restore operations has migrated to a specialized 'restore' package. Although this marks a shift in cbcontbk's resume function,
+it bears minimal impact due to the continuous backup being in developer preview status. Furthermore,
+continuous restore functionalities have been refined to allow resumption mid-operation,
+ensuring consistent progress in various operational scenarios. The restoration process now guarantees the creation of traditional backups,
+streamlining backup procedures and ensuring robust data management.
+
+// generated by openai:gpt-4o
+
+
+
+*https://jira.issues.couchbase.com/browse/MB-70255/[MB-70255]*::
+
+Addressed a bug where buckets with cross-cluster versioning enabled (link:https://docs.couchbase.com/server/current/learn/clusters-and-availability/xdcr-enable-crossclusterversioning.html[XDCR enable cross-cluster versioning]) would cause a merge to fail.
+
+
+

modules/release-notes/partials/docs-server-8.1-platform-changes.adoc

@@ -0,0 +1,6 @@
+== Deprecated Platforms
+
+Support for the following platforms is deprecated in this release:
+
+* Debian 11.x
+