技术问询：YugaByte DB是否支持系统滚动升级？

Yes, absolutely! YugaByte DB is built with production-grade availability at its core, and rolling upgrades are a fully supported, first-class feature. This means you can upgrade your entire cluster without taking it offline or disrupting end-user traffic—critical for maintaining uptime in business-critical environments.

How Rolling Upgrades Work in YugaByte DB #

The process is straightforward and low-risk, designed to keep your cluster operational every step of the way. Here's a typical workflow for production clusters:

• First, confirm your cluster is healthy: all masters and tablet servers are online, replication is fully synced, and there are no pending failures. Use commands like yb-admin list_all_masters and yb-admin list_all_tabletservers to validate this.
• Pick one node at a time to upgrade. Start by stopping the YugaByte service on that node (e.g., sudo systemctl stop yugabyted if using systemd).
• Replace the existing YugaByte binary files with the target version's binaries.
• Start the service back up, then wait for the node to rejoin the cluster. Use the same yb-admin commands to confirm the node is healthy and has caught up on replication.
• Once that node is stable, repeat the process for the next node. Continue until all masters and tablet servers are running the new version.

For local test environments, you can simplify this with the yb-ctl tool:

yb-ctl upgrade --version <target-version>

This command automatically handles the rolling upgrade process for your local test cluster.

Critical Things to Keep in Mind #

• Follow compatible version paths: Don’t skip major versions when upgrading. For example, if you’re on v2.18 and want to reach v2.20, upgrade to v2.19 first, then to v2.20. This ensures schema and protocol compatibility between nodes during the transition.
• Avoid heavy operations mid-upgrade: Hold off on large data loads, schema changes, or index creation while upgrading—these can strain the cluster and slow down node recovery.
• Validate after each step: Always confirm a node is fully healthy before moving to the next. This prevents cascading issues if something goes wrong with a single node.
• Run post-upgrade checks: Once all nodes are upgraded, use yb-admin check_cluster to verify the entire cluster is in a consistent, healthy state.

Why Rolling Upgrades Are Possible #

YugaByte DB’s distributed architecture (powered by the Raft consensus protocol) ensures that when one node is offline for upgrade, the remaining nodes in the replication group continue serving traffic and maintaining data consistency. The upgraded node automatically syncs with the rest of the cluster once it’s back online, so there’s no data loss or service interruption.

内容的提问来源于stack exchange，提问作者Ricardo Adam