You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
| When a username is extracted from a client certificate, no check was made for its existence on the server.
29
-
| The username extracted from the client certificate is checked for its existence in couchbase-server.
28
+
| When a username is extracted from a client certificate, the candidate username is checked for its existance in couchbase-server. If such user doesn't exist, algorithm now doesn't stop, but tries to extract another candidate username.
| The /prometheus_sd_config endpoint provides a new option `clusterLabels` which species the cluster name and cluster UUID be returned. Prometheus will use them as labels in time series data.
33
+
| This provides a method to guarantee uniqueness for stats with the same name gathered from multiple clusters.
30
34
31
35
|===
32
36
@@ -57,7 +61,7 @@ However, as part of the file-based rebalance process introduced in 7.6.0, a reco
57
61
| XDCR connection pre-check now supports alternate addresses, DNS SRV, and works identically to XDCR remote cluster references.
|An API issue has been resolved where attempting to set the completed-stream-size to zero when it was already zero via the administrative REST API would:
101
+
102
+
* Prevent stream completion.
103
+
104
+
* Block access to the system:vitals keyspace or vitals end-point.
105
+
106
+
* Require a full Query process restart on affected nodes as the only previous workaround.
a| A server panic was resolved when processing an aggregate function with a less-common reference structure, such as MAX([d.date, d][1]). The more standard form MAX([d.date, d])[1] was not impacted. The fix ensures stable query processing for this edge case.
112
+
113
+
| Issue resolved.
95
114
96
115
|===
97
116
@@ -101,21 +120,9 @@ a| In previous versions of Couchbase Server, a clear delimiter between a numeric
| In earlier versions of Couchbase, when an eventing function is under deployment or being resumed,
105
-
then, if the function has any destination bucket bindings whose LCB instances are to be bootstrapped,
106
-
and there were ongoing KV service issues, (e.g., a network partition, firewall on the KV port, etc.),
107
-
`Eventing` used to leave these LCB instances in an unhealthy state and skip past them to continue with deployment. +
108
-
Unfortunately, these LCB handles will never be repaired, even if the KV issues are eventually resolved. +
109
-
This resulted in any subsequent operations scheduled on this LCB instance to fail and not return control.
110
-
From the customer's perspective, the eventing function was stuck.
123
+
| In earlier versions of Couchbase, during eventing function deployment or resumption, KV service disruptions (like network partitions) could leave LCB instances in an unrecoverable, unhealthy state. This caused the eventing function to become permanently stuck, with subsequent operations failing to return control, rendering the function non-functional.
111
124
112
-
| `Eventing` keeps track of the LCB instances' statuses
113
-
and retries bootstrapping the unhealthy LCB instance(s) until the operation timeout. +
114
-
The operation timeout is derived from the script timeout. +
115
-
This process is described as "lazy" because `Eventing` retries the LCB bootstrap process
116
-
when the customer's JavaScript code uses the corresponding bucket binding(s). +
117
-
With this change in approach,
118
-
Eventing can ensure that the customer's JavaScript code does not get stuck and times out the mutation's processing instead.
125
+
| This issue has been resolved. Couchbase Eventing now actively monitors LCB instance statuses and implements a "lazy" retry mechanism for bootstrapping unhealthy instances. The retry process continues until the operation times out, which is dynamically determined by the script timeout. This ensures that JavaScript code remains responsive, with mutations timing out gracefully if bootstrap attempts fail, instead of causing a complete function lockup.
119
126
120
127
121
128
|===
@@ -141,13 +148,13 @@ where we didn't consider new nodes coming in when placing lost indexes.
| After enabling GSI shard-based rebalance from the Web UI and saving the settings, it is not possible to disable the same setting by unticking the box. The box is greyed out and cannot be interacted with.
151
+
| After enabling GSI shard-based rebalance from the Web UI and saving the settings, it was not possible to disable the same setting by unticking the box. The box is greyed out and cannot be interacted with.
| An issue in the rebalancer caused several partitions to miss streaming mutations when partitioned indexes were moved during file-based rebalances. This issue resulted in corrupt indexes as not all data was processed. +
149
156
The issue occurred only with partitioned indexes with file-based rebalances enabled.
150
-
| Issue resolved
157
+
| Issue resolved.
151
158
152
159
|===
153
160
@@ -158,11 +165,15 @@ The issue occurred only with partitioned indexes with file-based rebalances enab
| The absence of `segmentVersion` within `params.store` of index definitions in `6.x` leads to a situation of `v11` and `v16` segments being mixed,
162
-
which in turn, leads to panics arising while building `v16` segments.
168
+
| In index definitions from version 6.x, the `segmentVersion` parameter is absent, with it previously defaulting to v11. With 7.6 we’ve updated the default to v16. So when the `segmentVersion` is absent, the v16 code will be going into effect.
169
+
170
+
An issue in the v16 code while interpreting data with no vector fields caused an alignment panic. This panic is fixed with 7.6.4 allowing 6.x index definitions to work ok in 7.6.4.
171
+
172
+
* This problem occurs only for index definitions that survive an upgrade from 6.x to 7.x and then 7.6.x without being “re-built” meaning they’d still be using the v11 file format.
173
+
174
+
* Indexes that were introduced in server version 7.x and later or re-built after the cluster was fully upgraded to 7.x (which will have a segmentVersion:15 setting within their index definition) will not encounter this issue, because they invoke the v15 code.
163
175
164
-
This problem only occurs when `6.x` index definitions survive an upgrade from `6.x` to `7.6.x` but not from `7.x` from `7.[0-2].x` to
165
-
`7.6.x` because `segmentVersion` exists by default for indexes introduced in any version `7.0+`.
176
+
| In summary, version 7.6.4 now supports upgrades of 6.x index definitions. However, Couchbase recommends upgrading indexes to 15+ segment version format for improvements in indexing footprint and performance.
166
177
167
178
| Issue resolved.
168
179
@@ -175,7 +186,7 @@ This problem only occurs when `6.x` index definitions survive an upgrade from `6
0 commit comments