← ClaudeAtlas

couchbase-upgradelisted

Plan and execute Couchbase Server version upgrades, including rolling upgrades and the specific considerations for upgrading to 8.0. Use whenever the user asks about upgrading Couchbase, rolling upgrade, upgrade path, upgrade from 7.x to 8.0, upgrade checklist, cluster compatibility version, Magma storage engine default change in 8.0, 128 vBucket change in 8.0, EE features required for 8.0 defaults, pre-upgrade backup, post-upgrade verification, or 'how do I upgrade Couchbase without downtime.' Distinct from couchbase-mcp (which has an operational-runbooks reference covering rolling upgrade mechanics via MCP tools). This skill covers the planning, compatibility, and 8.0-specific breaking changes that require attention before and after the MCP-level upgrade steps.
celticht32/Couchbase-Skills-for-Claude.ai · ★ 1 · AI & Automation · score 75
Install: claude install-skill celticht32/Couchbase-Skills-for-Claude.ai
# Couchbase Upgrade Planning and executing Couchbase Server version upgrades — upgrade paths, breaking changes, pre/post-upgrade steps, and 8.0-specific considerations. Distinct from the rolling upgrade section in `couchbase-mcp` (which covers the MCP tool sequence for executing the upgrade). This skill covers the *planning* layer: what to check before you run those tools. ## When this skill applies - "How do I upgrade from 7.x to 8.0?" - "What changed in 8.0 that could break my cluster?" - "What's the safe upgrade path?" - "How do I verify the upgrade worked?" - "What's the cluster compatibility version?" - "Do I need EE for 8.0 defaults?" ## Supported upgrade paths Couchbase supports upgrading one major version at a time: | From | To | Supported | |---|---|---| | 7.0 / 7.1 / 7.2 / 7.6 | 8.0 | Yes — rolling upgrade | | 6.x | 8.0 | No — must go through 7.x first | | Community Edition | Enterprise Edition | Requires reinstall, not in-place upgrade | **Always upgrade to the latest patch of your current version before upgrading to the next major version.** Bugs fixed in patch releases can affect the upgrade process itself. ## Pre-upgrade checklist - [ ] Full cluster backup (cbbackupmgr or Capella managed backup) - [ ] Verify current cluster is healthy: all nodes `active` + `healthy`, rebalance not in progress, XDCR caught up (`changes_left` ≈ 0) - [ ] Review breaking changes for the target version (see below for 8.0) - [ ] Test the upgrade on a staging cluster first -