|
| 1 | + |
| 2 | + |
| 3 | +[#release-728] |
| 4 | +== Release 7.2.8 (7.2.8) |
| 5 | + |
| 6 | +Couchbase Server 7.2.8 was released in 7.2.8. |
| 7 | +This maintenance release contains fixes to issues. |
| 8 | + |
| 9 | +== Fixed Issues |
| 10 | + |
| 11 | + |
| 12 | + |
| 13 | + |
| 14 | + |
| 15 | + |
| 16 | + |
| 17 | + |
| 18 | + |
| 19 | + |
| 20 | + |
| 21 | + |
| 22 | +=== XDCR |
| 23 | + |
| 24 | +[#table-known-issues-728-xdcr, cols="10,40,40"] |
| 25 | +|=== |
| 26 | +|Issue | Description | Resolution |
| 27 | + |
| 28 | +| https://jira.issues.couchbase.com/browse/MB-66650/[MB-66650] |
| 29 | + |
| 30 | +a| When modifying filter expressions or mapping configurations (explicit/migration), race conditions may prevent proper replication from the source. This can result in source bucket documents failing to replicate to the target bucket. |
| 31 | + |
| 32 | +To address this issue, the system now displays an alert when detecting replication resuming from stale checkpoints. This alert notifies users to delete and recreate the affected replication. |
| 33 | + |
| 34 | +IMPORTANT: Do not dismiss this alert by pausing and resuming the replication, as this will hide the warning without resolving the underlying issue. |
| 35 | + |
| 36 | +| Issue resolved |
| 37 | + |
| 38 | +|=== |
| 39 | + |
| 40 | + |
| 41 | + |
| 42 | + |
| 43 | + |
| 44 | + |
| 45 | + |
| 46 | + |
| 47 | +=== Index Service |
| 48 | + |
| 49 | +[#table-known-issues-728-index-service, cols="10,40,40"] |
| 50 | +|=== |
| 51 | +|Issue | Description | Resolution |
| 52 | + |
| 53 | +| https://jira.issues.couchbase.com/browse/MB-67118/[MB-67118] |
| 54 | + |
| 55 | +a| `DropInstanceToken` increased in size due to changes in the definition. With more partitions, its size can increase beyond the `metakv` size limit. |
| 56 | + |
| 57 | +This ticket fixes the issue by using `BigValueGet` with `DropInstanceToken` which splits the tokens in parts, stores them in `metakv`, and retrieves the token by combining the parts. |
| 58 | + |
| 59 | +Before this patch, replica drops were failing when the token increased in size as retrieval was failing. |
| 60 | + |
| 61 | +| Issue resolved |
| 62 | + |
| 63 | +| https://jira.issues.couchbase.com/browse/MB-67116/[MB-67116] |
| 64 | + |
| 65 | +a| A race condition in the projector service could cause a deadlock when closing streams with high mutation rates. The issue, present since version 7.2.2, didn't affect functionality but resulted in increased memory consumption as mutations in the pipeline couldn't be released properly. |
| 66 | + |
| 67 | +With this fix, memory usage has been restored to normal levels. |
| 68 | + |
| 69 | +| Issue resolved |
| 70 | + |
| 71 | +| https://jira.issues.couchbase.com/browse/MB-66034/[MB-66034] |
| 72 | + |
| 73 | +a| Previously, during smart batching, the calculation of `max concurrent builds per node` incorrectly considered all indexer nodes as potential destinations; even those not participating in index movement during the rebalance. As a result, the destination node count was inflated, causing the batch size to be divided across more nodes than necessary. This led to smaller batch sizes and fewer tokens per batch on the actual recipient nodes. |
| 74 | + |
| 75 | +With this fix, only indexer nodes that are actively receiving index transfers are considered in the destination node count. This results in more accurate batch sizing and improved efficiency during index rebalance operations. |
| 76 | + |
| 77 | +| Issue resolved |
| 78 | + |
| 79 | +| https://jira.issues.couchbase.com/browse/MB-65375/[MB-65375] |
| 80 | + |
| 81 | +a| In the latest update (version 7.2.8-8817), a key commit has been implemented to set the min and max iteration parameters for the planner during the CommandRepairBuild process. This update specifically targets the Replica Repair scenario to enhance system performance. The changes have been verified, but emphasize the need for a functional test to validate the ALTER INDEX functionality when increasing replicas, following the procedures outlined in a related ticket. |
| 82 | + |
| 83 | +// Generated by [chatgpt:gpt-4o] |
| 84 | +| Issue resolved |
| 85 | + |
| 86 | +|=== |
| 87 | + |
| 88 | + |
| 89 | + |
| 90 | + |
| 91 | +=== Tools |
| 92 | + |
| 93 | +[#table-known-issues-728-tools, cols="10,40,40"] |
| 94 | +|=== |
| 95 | +|Issue | Description | Resolution |
| 96 | + |
| 97 | +| https://jira.issues.couchbase.com/browse/MB-57755/[MB-57755] |
| 98 | + |
| 99 | +a| Beginning with Server 7.2.8/7.6.7, when installing on a Linux system using cgroups v1, Server will set the `memory.swappiness` cgroups parameter to `0` for the `couchbase-server` service slice. This ensures best performance without affecting any other services that may be running on the system. |
| 100 | + |
| 101 | +For Linux systems using cgroups v2 (which is the default for the more recent releases of most Linux distributions), there is no `memory.swappiness` parameter for individual service slices. Therefore it is still highly recommended to set kernel swappiness to `0` globally on each node, as explained in the documentation: [https://docs.couchbase.com/server/current/install/install-swap-space.html\|https://docs.couchbase.com/server/current/install/install-swap-space.html] |
| 102 | + |
| 103 | +| Issue resolved |
| 104 | + |
| 105 | +|=== |
| 106 | + |
| 107 | + |
0 commit comments