upgrading-cluster-version
Skill2 starsChanged 28 days agoMITView on GitHub
Guides CockroachDB version upgrades with tier-appropriate procedures. Self-Hosted covers manual rolling binary replacement with finalization control. Advanced/BYOC covers Console-initiated major upgrades, maintenance windows for patches, and release channel selection. Standard and Basic upgrades are fully automatic with no customer action required. Use when planning, executing, or monitoring a version upgrade.
- Reads credentials
2 other projects use a version of this, 2 of them edited.
Adopted by
Most recently taken up by
- cockroachdb/claude-pluginedited, first seen Oct 13, 2026
- DineshKumar8399/aegis-governed-memory-fleetedited, first seen Aug 18, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 2
- cockroachdb/claude-plugin★ 489% same
- DineshKumar8399/aegis-governed-memory-fleet★ 089% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository192 other files it gives its agents.
- clickhouse-architecture-advisor/AGENTS.mdAGENTS.md
- clickhouse-best-practices/AGENTS.mdAGENTS.md
- unsafe-checker/AGENTS.mdAGENTS.md
- alertmanager-querySkill
- analyzing-range-distributionSkill
- analyzing-schema-change-storage-riskSkill
- argocdSkill
- aspire-configurationSkill
- aspire-integration-testingSkill
- aspire-service-defaultsSkill
- auditing-cloud-cluster-securitySkill
- auditing-table-statisticsSkill
- benchmarking-transaction-patternsSkill
- cepthSkill
- chdb-datastoreSkill
- chdb-sqlSkill
- clickhouse-architecture-advisorSkill
- clickhouse-best-practicesSkill
- clickhousectl-cloud-deploySkill
- clickhousectl-local-devSkill
- cockroachdb-sqlSkill
- coding-guidelinesSkill
- configuring-audit-loggingSkill
- configuring-ip-allowlistsSkill
- configuring-log-exportSkill
- configuring-private-connectivitySkill
- configuring-sso-and-scimSkill
- create-technical-architecture-documentSkill
- csharp-mstestSkill
- csharp-tunitSkill
- csharp-xunitSkill
- designing-application-transactionsSkill
- designing-multi-region-applicationsSkill
- domain-cliSkill
- domain-cloud-nativeSkill
- domain-embeddedSkill
- domain-fintechSkill
- domain-iotSkill
- domain-mlSkill
- domain-webSkill
- dotnet-aot-wasmSkill
- dotnet-aspire-patternsSkill
- dotnet-benchmarkdotnetSkill
- dotnet-blazor-authSkill
- dotnet-blazor-componentsSkill
- dotnet-blazor-patternsSkill
- dotnet-blazor-testingSkill
- dotnet-channelsSkill
- dotnet-ci-benchmarkingSkill
- dotnet-cli-architectureSkill
- dotnet-cli-distributionSkill
- dotnet-cli-packagingSkill
- dotnet-cli-release-pipelineSkill
- dotnet-containersSkill
- dotnet-cryptographySkill
- dotnet-csharp-dependency-injectionSkill
- dotnet-csharp-modern-patternsSkill
- dotnet-csharp-nullable-reference-typesSkill
- dotnet-csharp-source-generatorsSkill
- dotnet-maui-doctorSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 10 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
For pre-upgrade health check: Use reviewing-cluster-health.
- Distinctive: line 23
For node drain during Self-Hosted upgrade: Use performing-cluster-maintenance.
- Distinctive: line 24
For maintenance window configuration: Use performing-cluster-maintenance.
- Distinctive: line 57
If Standard or Basic: No additional context needed — upgrades are fully automatic.
- Very specific: line 165
Verify cluster.preserve_downgrade_option still returns the old version, then replace each node's binary with the previous version and …
- Very specific: line 234
Verify PrivateLink/PSC/VPC Peering connections remain healthy during the upgrade
- Distinctive: line 245
Only Regular releases (no Innovation channel)
- Distinctive: line 246
No maintenance window configuration
- Distinctive: line 248
No downtime during upgrades
- Very specific: line 270
Verify version if needed: SELECT version().
- Distinctive: line 285
Never skip major versions (SH) — upgrades must be sequential
- Distinctive: line 286
Never finalize before testing (SH) — finalization is irreversible
- Distinctive: line 287
Never change cluster settings during an upgrade (SH, ADV, BYOC)
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Upgrading Cluster Version
Guides CockroachDB version upgrades end-to-end. Before providing procedures, this skill gathers deployment context to deliver only the steps relevant to the operator's tier.
When to Use This Skill
- Planning or executing a version upgrade (Self-Hosted)
- Initiating a major version upgrade via Cloud Console (Advanced, BYOC)
- Configuring how patches are applied (Advanced, BYOC)
- Verifying upgrade completion (all tiers)
- Deciding whether to finalize or roll back (Self-Hosted)
For pre-upgrade health check: Use reviewing-cluster-health. For node drain during Self-Hosted upgrade: Use performing-cluster-maintenance. For maintenance window configuration: Use performing-cluster-maintenance.
Step 1: Gather Context
Required Context
| Question | Options | Why It Matters |
| Deployment tier? | Self-Hosted, Advanced, BYOC, Standard, Basic | Completely different upgrade procedures per tier |
| Current version? | e.g., v24.2.5 | Validates upgrade path and compatibility |
Additional Context (by tier)
If Self-Hosted:
| Question | Options | Why It Matters |
| Upgrade type? | Major (e.g., 24.2→24.3), Patch (e.g., 24.2.5→24.2.8) | Major requires finalization; patches do not |
| Target version? | e.g., v24.3.1 | Confirms version is available and sequential |
| Deployment platform? | Bare metal, VMs, Kubernetes (Operator/Helm/manual) | Changes binary replacement and restart procedure |
| Process manager? | systemd, manual, container orchestrator | Changes stop/start commands |
| Node count? | Number | Affects upgrade sequencing |
If Advanced or BYOC:
| Question | Options | Why It Matters |
| Upgrade type? | Major version, Patch | Major requires Console initiation; patches use maintenance windows |
| Cloud provider? (BYOC only) | AWS, GCP, Azure | For infrastructure-level monitoring during upgrade |
| Release channel? | Regular, Innovation | Innovation gives latest features, shorter support window |
If Standard or Basic: No additional context needed — upgrades are fully automatic.
Context-Driven Routing
| Tier | Go To |
| Self-Hosted | Self-Hosted Upgrade |
| Advanced | Advanced Upgrade |
| BYOC | BYOC Upgrade |
| Standard | Standard Upgrade |
| Basic | Basic Upgrade |
Self-Hosted Upgrade
Applies when: Tier = Self-Hosted
Major vs Patch
| Aspect | Major (e.g., 24.2→24.3) | Patch (e.g., 24.2.5→24.2.8) |
| Finalization required | Yes | No |
| Rollback possible | Before finalization | Always (binary swap) |
| Auto-finalization | Enabled by default (disable recommended) | N/A |
Pre-Upgrade Validation
-- All nodes live
SELECT n.node_id, n.build_tag, n.is_live
FROM crdb_internal.gossip_nodes n ORDER BY n.node_id;
-- No bulk operations running
WITH j AS (SHOW JOBS)
SELECT job_id, job_type, status, now() - created AS running_for FROM j
WHERE status IN ('running', 'paused')
AND job_type IN ('SCHEMA CHANGE', 'BACKUP', 'RESTORE', 'IMPORT', 'NEW SCHEMA CHANGE');
-- No pending finalization from a previous upgrade
SHOW CLUSTER SETTING cluster.preserve_downgrade_option;
-- Ranges fully replicated
SELECT CASE WHEN array_length(replicas, 1) >= 3 THEN 'fully_replicated'
ELSE 'under_replicated' END AS status, COUNT(*)
FROM crdb_internal.ranges_no_leases GROUP BY 1;Disable Auto-Finalization (Major Version — Recommended)
SET CLUSTER SETTING cluster.preserve_downgrade_option = '<current_version>';
-- Example: SET CLUSTER SETTING cluster.preserve_downgrade_option = '24.2';Rolling Node Upgrade (repeat for each node)
If process manager = systemd:
cockroach node drain --self --certs-dir=<certs-dir> --host=<node-address>
sudo systemctl stop cockroachdb
cp /path/to/new/cockroach /usr/local/bin/cockroach
cockroach version # verify new binary
sudo systemctl start cockroachdbIf Kubernetes (Operator):
kubectl patch crdbcluster <name> --type merge -p '{"spec":{"cockroachDBVersion":"<new-version>"}}'
# Operator handles rolling restart automaticallyIf Kubernetes (Helm):
helm upgrade cockroachdb cockroachdb/cockroachdb --set image.tag=<new-version>If Kubernetes (manual StatefulSet):
kubectl set image statefulset/cockroachdb cockroachdb=cockroachdb/cockroach:<new-version>Verify each node before proceeding to the next:
SELECT node_id, build_tag, is_live
FROM crdb_internal.gossip_nodes
WHERE node_id = <upgraded-node-id>;Monitor Progress
SELECT n.node_id, n.build_tag AS version,
CASE WHEN n.build_tag = (SELECT MAX(build_tag) FROM crdb_internal.gossip_nodes)
THEN 'UPGRADED' ELSE 'PENDING' END AS status
FROM crdb_internal.gossip_nodes n ORDER BY n.node_id;Finalize (Major Version Only — Irreversible)
SELECT COUNT(DISTINCT build_tag) FROM crdb_internal.gossip_nodes; -- Must be 1
RESET CLUSTER SETTING cluster.preserve_downgrade_option;
SHOW CLUSTER SETTING version; -- Monitor until updatedRoll Back (Before Finalization Only)
Verify cluster.preserve_downgrade_option still returns the old version, then replace each node's binary with the previous version and restart. After all nodes are back:
RESET CLUSTER SETTING cluster.preserve_downgrade_option;Advanced Upgrade
Applies when: Tier = Advanced
Advanced clusters are managed by Cockroach Labs. You initiate major upgrades; patches are applied automatically.
Major Version Upgrade
- Cloud Console → Cluster → Settings → Upgrade
- Select target version
- CRL performs rolling upgrade across nodes automatically
- Monitor progress in Cloud Console
- Finalize via Cloud Console when testing is complete
SQL verification during upgrade:
SELECT build_tag AS version, COUNT(*) FROM crdb_internal.gossip_nodes GROUP BY 1;Patch Upgrades
Patches are applied automatically during the configured maintenance window. See performing-cluster-maintenance for maintenance window configuration and patch deferral.
Release Channel
- Regular: Stability-focused, longer support windows
- Innovation: Latest features, shorter support, can be skipped
Configure via Cloud Console → Cluster → Settings → Upgrades.
Upgrade Before End of Support
You are responsible for initiating major upgrades before the current version reaches End of Support (EOS). Failure to upgrade before EOS may affect SLA guarantees.
Cloud API
# Check current version
curl -s -H "Authorization: Bearer $COCKROACH_API_KEY" \
"https://cockroachlabs.cloud/api/v1/clusters/<cluster-id>" | jq '.cockroach_version'BYOC Upgrade
Applies when: Tier = BYOC
BYOC upgrade procedures are the same as Advanced. Follow all Advanced Upgrade steps.
Cloud Provider Monitoring During Upgrade
Since BYOC clusters run in your cloud account, you can observe the rolling upgrade in your infrastructure:
If AWS: EC2 console shows instance restarts; CloudWatch metrics show brief dips during node cycling.
If GCP: Compute Engine console shows VM restarts; Cloud Monitoring shows instance-level events.
If Azure: Azure portal shows VM restarts; Azure Monitor captures instance events.
Additional BYOC Considerations
- Verify PrivateLink/PSC/VPC Peering connections remain healthy during the upgrade
- Reserved instances and committed use discounts are unaffected (instance types don't change)
Standard Upgrade
Applies when: Tier = Standard
Standard is a multi-tenant managed service. There are no nodes or infrastructure for you to manage. All upgrades — both major versions and patches — are applied automatically by Cockroach Labs.
- Only Regular releases (no Innovation channel)
- No maintenance window configuration
- No deferral capability
- No downtime during upgrades
After an Upgrade
- Monitor Cloud Console for upgrade notifications
- Review release notes for behavior changes
- Verify application compatibility:
SELECT version();
Basic Upgrade
Applies when: Tier = Basic
Basic is a serverless offering. All upgrades are fully managed and transparent. The serverless architecture is designed for zero-downtime upgrades with no customer action required.
After an Upgrade
- Review release notes for behavior changes
- Verify version if needed:
SELECT version();
Safety Considerations
| Operation | Tier | Reversible? |
| Set preserve_downgrade_option | SH | Yes |
| Replace node binary | SH | Yes (swap back before finalization) |
| Finalize upgrade | SH | No — irreversible |
| Initiate Cloud Console upgrade | ADV/BYOC | Contact support to discuss |
| Automatic upgrade | STD/BAS | N/A (managed by CRL) |
Critical:
- Never skip major versions (SH) — upgrades must be sequential
- Never finalize before testing (SH) — finalization is irreversible
- Never change cluster settings during an upgrade (SH, ADV, BYOC)
Troubleshooting
| Issue | Tier | Fix |
| Cannot set preserve_downgrade_option | SH | Value must match output of SHOW CLUSTER SETTING version |
| Finalization stuck | SH | Decommission dead nodes; ensure all live nodes are upgraded |
| Auto-finalization triggered early | SH | Cannot undo; test application on new version |
| Upgrade not available in Console | ADV/BYOC | Check release schedule; contact support |
| Behavior change after automatic upgrade | STD/BAS | Review release notes; contact support |
References
Related skills:
- reviewing-cluster-health — Pre/post-upgrade health
- performing-cluster-maintenance — Node drain (SH) and maintenance windows (ADV/BYOC)
- managing-cluster-settings — preserve_downgrade_option
Official CockroachDB Documentation:
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

