ゼロダウンタイムアップグレード：TiDBが常時稼働データベースを支える仕組み

※このブログは2025年11月13日に公開された英語ブログ｢Zero-Downtime Upgrades: How TiDB Powers Always-On Databases｣の拙訳です。

データベースが広く利用される領域において、ゼロダウンタイムでのアップグレードと運用継続性の確保は、いまだ大きな課題です。従来型データベースはアーキテクチャ上の制約により、アップグレード時に多くのダウンタイムを発生させることが一般的で、リアルタイムなデータアクセスに依存するビジネスにとっては運用上の混乱を招く要因となります。

そこで登場するのがTiDBです。堅牢でクラウドネイティブ、かつ疎結合なアーキテクチャを採用した先進的な分散SQLデータベースであるTiDBは、オンラインローリングアップグレードをサポートし、サービスを止めることなくゼロダウンタイムでのアップグレードを可能にします。

本ブログでは、TiDB独自の扱いやすいアップグレードメカニズムについて、ハンズオン形式で解説していきます。

本番環境でゼロダウンタイムが重要である理由

本番環境が停止すると、その損失は一気に膨らみます。最新の業界調査によると、中規模から大規模企業では1時間あたりのITダウンタイムの平均コストが30万ドルを超えており、ワークロードや業種によっては1時間あたり100万〜500万ドルに達するという報告も少なくありません。

Uptime Instituteの障害分析は、この傾向を裏付けています。すなわち、重大インシデントはコストが高く、規制当局や取締役会による監視も強まっており、レジリエンスと変更安全性に求められる基準は一段と高くなっています。保守的な試算であっても、一般的なダウンタイムのコストは1時間あたり10万～54万ドルとされており、これは多くのチームが自社のインシデントのポストモーテムで把握している数値とも一致します。つまり、計画メンテナンスを1回でも削減し、リスクの高いスキーマ変更をオンラインで実施できるようにすることは、そのまま収益・ブランド価値・SLOを守ることにつながります。

業界	一般的な範囲 (USD / 時間)	備考
金融サービス	$300,000 – $5,000,000以上	大企業ではしばしば1時間あたり30万ドル以上の報告があり、重大インシデントでは100万～500万ドル以上に達する場合もあります。
Eコマース / 小売	$140,000 – $1,000,000	一般的な「1分あたり」の平均値を時間換算すると、約14万～54万ドル以上となり、重大インシデントではさらに高額になることがあります。
SaaS / クラウド	$300,000 – $1,000,000以上	中～大規模企業では1時間あたり30万ドル以上が一般的で、深刻なインシデントでは100万ドルを超えることもあります。
製造業	$260,000 – $1,360,000以上	ベンチマークはおおむね1時間あたり26万ドル前後に集中していますが、最近の報告では一部地域で平均が130万ドルを超える場合もあります。

TiDBにおけるゼロダウンタイムアップグレードの意味：もしお使いの環境が共有データベースクラスタ上で数十のサービスを稼働させている場合、オンラインDDL / ローリングアップグレードと、わずかなメンテナンスウィンドウを取る場合との違いは、1件のインシデントで数十万ドル規模になることがあります。オンラインでのスキーマ変更、ローリング再起動、バージョン変更の自動化に投資することは、「あると便利」というレベルの話ではありません。実質的なコスト削減手段であり、ロードマップを予定通り進めるために不可欠な取り組みです。

従来型データベースアップグレードの課題

従来のデータベースプラットフォームは、依然として「停止して待つ」メンテナンスウィンドウを前提としており、24×7で稼働するSaaSやフィンテック環境とは相容れません。チームは真のオンラインスキーマ変更に苦労しています。具体的には、ブロッキングDDL、長時間のロック、IOを急増させタイムアウトを引き起こすテーブルのコピーなどです。

従来のデータベースプラットフォームは、依然として「停止して待つ」メンテナンスウィンドウを前提としており、24×7で稼働するSaaSやフィンテック環境とは相容れません。チームは真のオンラインスキーマ変更に苦労しています。具体的には、ブロッキングDDL、長時間のロック、IOを急増させタイムアウトを引き起こすテーブルのコピーなどです。

TiDBのゼロダウンタイム実現のための分散SQLアーキテクチャ

従来のデータベースでは、「停止して待つ」手法を用い、時間のかかるアップグレード中にすべての操作を凍結することが多いです。これに対して、TiDBはオンラインローリングアップグレード戦略を採用しています。このアプローチでは、特定の順序でコンポーネントをアップグレードすることでゼロダウンタイムを実現します：

1. Placement Driver (PD) サーバ
2. The TiKVサーバ
3. The TiDBサーバ

各サーバは1台ずつ順番にアップグレードされ、他のサーバが継続的に受信負荷を処理するため、途切れのない安定したアップグレード体験が可能となります。

次に、各主要コンポーネントがアップグレードプロセスにどのように寄与しているかを詳しく見ていきます：

図1.自動アップグレードアーキテクチャ

コンポーネント	定義	自動アップグレードメカニズム
Placement Driver (PD) Servers	PDサーバーはクラスターマネージャーとして機能し、メタデータ管理、スケジューリング、負荷分散を担当します。	アップグレード中、各PDサーバーは1台ずつ順番にアップグレードされます。 PDが現在のリーダーである場合、まずリーダーシップが移譲され、TSOのアクティブなリクエストに対してごく短い停止が発生しますが、進行中のトランザクションやクライアント接続には影響しません。
TiKV Servers	TiKVは分散型トランザクションキー・バリュー・ストレージ層であり、データの保存と取得を担当します。	TiKVサーバーは1台ずつ順番にアップグレードされます。アップグレード前に、各Regionのリーダーは別のTiKVサーバーへ移譲されるため、進行中の処理は中断されません。
TiDB Servers (Facilitated by TiProxy)	TiDBはステートレスなSQLサーバーであり、SQLクエリの処理、セッション管理、トランザクション処理を担当します。	TiProxyは、ネットワークロードバランサーとSQLレイヤーの間に位置し、TiDBサーバーのスムーズなアップグレードを支援します。アップグレード中はクライアントセッションを他のTiDBサーバーへ移行するため、クライアントアプリケーションに中断は発生しません。

このアップグレードメカニズムにより、アップグレードの各段階において、クライアントはダウンタイムを一切経験せず、まるで何も変わっていないかのようにデータベースへアクセスし続けることができます。TiDBの世界では、アップグレードは中断ではなく、シームレスな移行として扱われます。アップグレードメカニズムの詳細については、Maintaining Database Connectivity in Serverless Infrastructure with TiProxyをご参照ください。

クラウドネイティブかつ水平スケールを前提とした設計

TiDBの高い耐障害性 (レジリエンス) は、そのアーキテクチャに由来します。TiDBはクラウドネイティブで、各コンポーネントが独立して動作する「shared-nothing」設計を採用しており、ステートレスなSQLコンピュート (TiDB) と、Raftレプリケーションを用いたステートフルなストレージ (TiKV)、さらに分析用のオプションであるTiFlashが明確に分離されています。この分離により、サービスを停止することなく、変更の展開、キャパシティの追加、ノードの個別置き換えが可能です。需要が急増した場合やノードに障害が発生した場合でも、クラスタはリーダーやリージョンを自動的に再バランスするため、バックグラウンドでアップグレードが進行している間もスループットと可用性は安定します。

これがゼロダウンタイムでの変更を可能にする理由です：

• 柔軟なスケールアウト / スケールイン：TiDB (コンピュート) やTiKV (ストレージ) のノードをオンラインで追加・削除可能。トラフィックはPDによるスケジューリングで自動的に分散されます。
• 耐障害性のあるストレージ：Raftにより複数のレプリカを保持します。リーダー選出やリージョンの移動はメンテナンス中もライブで行われます。
• ローリングアップグレード：バイナリのアップグレード、パッチ適用、設定変更をノードごとに実施しても、クラスタは読み書きを継続します。
• ワークロードの分離：Placement RulesやTiFlashを活用し、重いスキャン処理をOLTPパスから切り離すことで、アップグレード中もp95/p99レイテンシを維持します。
• 運用上の安全対策：オンラインDDL、ポイントインタイムリカバリ、豊富な可観測性により、変更リスクを低減し、万一問題が発生した場合もMTTR (平均復旧時間) を短縮します。

PDサーバーおよびTiKV/TiDBコンポーネントによる高可用性

Placement Driver (PD) はTiDBのコントロールプレーンです。
PDは次の機能により、クラスタを健全かつ高可用に保ちます：(1) クラスタ全体のメタデータ (ストア、リージョン、リーダー) を管理すること、(2) 分散トランザクション向けに単調増加タイムスタンプオラクル (TSO) を提供すること、(3) キャパシティや負荷、ユーザーのPlacement Rulesに基づき、TiKVノード間でリージョン配置やリーダー選出をスケジューリングすること。
PDはTiKVからのハートビートを常時受信し、数秒以内に障害を検知します。そして、安全なリバランスやリーダー移譲を実行することで、ノードの再起動、アップグレード、ハードウェア障害が発生しても読み書きトラフィックをオンラインで維持します。

ゼロダウンタイムで行うアップグレードのステップバイステップ解説

TiDBのゼロダウンタイムアップグレード機能を具体的に示すために、セルフホスト型TiDBクラスタを使った実際のデモを見ていきましょう。フルマネージドのTiDB Cloudではこれらの機能がすぐに利用可能ですが、セルフホスト環境ではアップグレードプロセスをより詳細に確認することができます。

今回のデモはAWS上で実施しました。詳細なスクリプト、プログラム、CloudFormationテンプレート、ワークフローを含むステップ・バイ・ステップのガイドを提供しているので、ご自身で再現することも可能です。他のクラウド環境でのデモ実装に応じて、自由に改良・再現していただけます。このセクションでは、アップグレードプロセス中の観察結果にのみ焦点を当てます。

アップグレード前の準備とスケーリングのベストプラクティス

アップグレード中のゼロダウンタイムを実演することがデモの主な目的ですが、TiDBのアーキテクチャ設計により、事前にスケーリングを行うことも可能です。これは、ワークロードが並列処理に大きく依存している場合に特に有用です。オンラインアップグレードに際しては、以下のプラクティスを推奨します：

• アップグレード前：TiDBサーバーインスタンスを事前にスケールアウトして、スムーズなローリングアップグレードを確保します。このスケーリングは、ワークロードの要件に応じてTiKVサーバーインスタンスにも拡張可能です。
• アップグレード後：TiDBではスケールインも可能で、運用コストを削減できます。スケーリングは手動でも、TiDBの自動スケーリング機能を使っても管理できます。

アップグレード前の確認

デモのために、3つのターミナルウィンドウを用意しました：

図2.ターミナルのセットアップ

• 上部のターミナル：TiProxyサービスが稼働しています。
• 中央のターミナル：サンプルアプリケーションが表示されており、4つのアクティブなデータベース接続があります。これらの接続は、ネットワークロードバランサーとTiProxyサービスを経由して、均一な頻度でデータをデータベースに挿入しています。
• 下部のターミナル：サンプルアプリケーションによって挿入されたイベントを検索し、各TiDBサーバーが処理した挿入リクエスト数を表示しています。

ご覧のとおり、2台のTiDBサーバーがそれぞれ約170件のイベントを処理しています。両サーバーは同数の接続を受け取り、同程度のリクエストを処理しています。なお、今回2台のTiDBを使用しているのは、高可用性とスムーズなアップグレードのためです。

中央のターミナルと下部のターミナルはアプリケーションのワークロードを表しており、中央が書き込み、下部が読み取りを示しています。

アップグレード前に、AWSコンソール上でTiProxyのステータスを確認しました。

図3.AWSコンソールにおけるTiProxyのステータス

また、現在のTiDBバージョンがv6.5.1であり、アップグレード先のターゲットバージョンがv6.5.2であることも確認しました。

Figure4.初期クラスタの状態

本番環境でクエリを監視する方法について、ここで簡単に触れておきます。1〜5分ごとに、次のポイントをチェックしてください：

• 総レイテンシ別およびエラー別の上位ダイジェストを確認し、リグレッションを素早く検知する。
• ホットクエリのプラン変更 (同じSQLダイジェストでも、プランダイジェストが異なる場合は要注意。)
• リトライ／ロック待ちのシグナル、write_conflict、deadlock、backoffなどのカウントが増加していないか確認。
• 重要エンドポイントのP95／P99の変動 (監視対象のダイジェストを限定する)

オペレーター向けのヒントをいくつか紹介します：

• 監視対象のダイジェストは5〜10件程度のリストに絞り、ユーザーから見えるエンドポイントに紐づけておくこと。そうすることで、オンコール担当者が影響範囲を数秒で判断できるようになります。
• 変更実施の15〜30分前にベースラインを固定し、ロールアウト中は_deltaカラムのみを比較します。
• p95/p99と併せてプランの切り替わりを追跡し、両方が悪化する方向に動く場合は、ノード復帰後に統計を固定または統計情報の再取得を検討します。
• 重要なダイジェストについて、p95がベースラインの1.5倍を2連続インターバルで超えたとき、またはerrors_deltaが0より大きく増加傾向にある場合はアラートを発報します。

ローリングアップデートの実行

バージョン6.5.2へのアップグレードを開始するのは非常に簡単で、次のコマンドを実行するだけです：

$ tiup cluster upgrade tidb-demo v6.5.2 --yes

各コンポーネントのアップグレード手順は以下の通りです：

サンプルアプリケーションに一切の中断を発生させることなく、1台ずつ順番にアップグレードされました。

図5.PDアップグレードのプロセス

TiKVサーバー：各TiKVノードは順番にアップグレードされました。アップグレードを進める前に、各リージョンのリーダー役割は別のサーバーに移されました。ここでも、システムの中断は一切発生しませんでした。

図6.TiKVアップグレードのプロセス

TiDBサーバー：ここではTiProxyが重要な役割を果たしました。各TiDBサーバーをアップグレードする前に、TiProxyはそのサーバー上のアクティブセッションを別のTiDBサーバーに移動させ、サービスの中断を防ぎました。例えば、IPアドレス10.90.1.216のTiDBサーバーをアップグレードする前に、TiProxyはそのサーバー上のセッションをサーバー10.90.3.163に移行しました。

図7.TiDBアップグレードのプロセス

アップグレードの全工程を通して、サンプルプログラムの4つのセッションは常にアクティブなままで、クライアント側はアップグレードの実施に気づきませんでした。

ローリングアップグレードが中断なく進行する仕組みは以下の通りです：

• PDサーバー (コントロールプレーン)：PDは1台ずつアップグレードします。再起動の前に、PDは内部のリーダーシップを移譲します。残りのPDはTSOやスケジューリングのサービスを継続するため、トランザクションや配置の決定は通常通り進行します。
• TiKVノード (ストレージ)：対象ストアからリーダーを退避させてからノードを再起動します。Raftにより影響を受けたリージョンの新しいリーダーが選出され、読み書きは健全なピアにルーティングされます。PDはバックグラウンドでレプリカ数を復元し、リーダーをバランスします。
• TiDBサーバー (コンピュート)：TiDBはステートレスであるため、ロードバランサーの背後でノードを1台ずつ再起動または置き換えます。既存セッションはドレインされ、新しいセッションは健全なTiDBノードに接続されるため、接続規模やクエリスループットは安定したまま維持されます。

確認すべき事項：各コンポーネントのサブステップ中も、クエリスループット (QPS/TPS) はほぼ平坦で、わずかな揺らぎのみが見られます。エラー率やテールレイテンシもベースラインの範囲内に収まります。

オンラインスキーマ変更の例

TiDBはDDLをオンラインで実行するため、トラフィックが流れている最中でもスキーマを変更させることができます。以下は、負荷テスト中や実際のワークロードが動いている間でも、そのままセッションに貼り付けて使える、最小限かつ本番運用レベルのパターンです。

-- 1) Add a new nullable column safely (no app pause)
ALTER TABLE orders
  ADD COLUMN promo_code VARCHAR(32) NULL DEFAULT NULL COMMENT 'marketing code';

-- 2) Create an index online to speed up a hot path
CREATE INDEX idx_orders_created ON orders (created_at);

-- 3) (Optional) Backfill a derived column without blocking OLTP
--    Do it in small batches from the app or a job runner.
--    Example: 5k rows at a time to avoid hotspots.
UPDATE orders
SET promo_code = NULL
WHERE promo_code IS NULL
LIMIT 5000;

-- 4) Observe DDL progress non-disruptively
ADMIN SHOW DDL JOBS 5;

-- 5) Verify the planner uses the new index (no restart required)
EXPLAIN ANALYZE
SELECT id, created_at
FROM orders
WHERE created_at >= NOW() - INTERVAL 7 DAY;

注意点：バックフィルの処理が長時間に及ぶ場合は、バッチサイズを区切って実行できるようにし、何度実行しても副作用がない (冪等な) 形にしておきましょう。また、インデックスのバックフィルが走っている間はテールレイテンシを監視してください。TiDBでは、DDLパイプラインがオンラインフェーズ (delete-only、write-only、write-reorg、public) を処理するため、処理中も読み取り・書き込みは常に利用可能な状態が保たれます。

クラスタ管理におけるゼロダウンタイムのベストプラクティス

TiDBでゼロダウンタイムを実現するために使える、簡単なチェックリストを紹介します。

ローリングアップデートのスケジューリング：

• メンテナンスウィンドウは、小さく再現性のあるバッチ単位で設定します (PDを1台→TiKVストアを数台→TiDBを1台ずつの順番)。
• 対象のTiKVストアを再起動する前に、事前にリーダーをドレインし、リーダー数がほぼ0に近づいていることを確認します。
• 再起動の間には3〜5分程度のクールダウンを設け、PDがリージョン / リーダーをリバランスできるようにします。
• 各ステップごとに、ロールバック用のチェックポイント (パッケージバージョン + 設定差分 + BR/PITRのリストアポイント) を固定しておきます。
• 変更範囲を凍結します：ローリング更新のフェーズでは、重いDDL、コンパクション、BRジョブを並行して実行しないようにします。

アップグレード中のクラスタヘルスのモニタリング：

• 各TiDBインスタンスごとにp95/p99、エラーレート、QPS/TPSを追跡し、p95がベースラインの1.5倍を2インターバル連続で超えた場合にアラートを出します。
• Top SQL (レイテンシとエラー) を監視し、最もホットなダイジェストについてはプランの切り替え (plan flip) を確認します。
• ストレージでは、TiKVのCPU、スケジューラのpending tasks、Raft ready/append、ストアごとのリーダー集中度を監視します。
• PDでは、TSOのレート / レイテンシ、リージョンバランス、ストアのヘルスを確認し、長いテールのスケジューリングが起きていないことを検証します。
• 各ノードが復帰した後は、クイックチェックを再実行します：

-- Top latency (delta window)
SELECT digest_text, exec_count_delta, sum_latency_delta/1000 AS ms
FROM information_schema.statements_summary
ORDER BY sum_latency_delta DESC LIMIT 10;

-- Leader skew by store
SELECT store_id, SUM(CASE WHEN is_leader=1 THEN 1 ELSE 0 END) AS leaders
FROM information_schema.tikv_region_peers GROUP BY store_id ORDER BY leaders DESC;

スムーズな移行のためのMySQL互換性の活用：

• まずスキーマをリフト＆シフトし、アプリコードは変更しないままにします (MySQLプロトコル + SQL方言に対応)。
• 移行後は、TiDBのオンラインDDLを使ってテーブルを進化させます (アプリの停止は不要)。
• 重要なクエリをEXPLAIN/ANALYZEで検証し、必要なインデックスをオンラインで追加します。

CREATE INDEX idx_orders_created ON orders(created_at);
EXPLAIN ANALYZE SELECT * FROM orders WHERE created_at >= NOW() - INTERVAL 7 DAY;

• データ移行には、初期ロードにTiDB Dumpling / Lightning、変更同期にTiCDCを使用し、フィーチャーフラグを使ったブルーグリーン方式のカットオーバーを計画します。
• 互換性チェックリスト (SQLモード、照合順序、予約語、ドライバー / ORMなど) を維持し、移行計画に合わせてクライアントライブラリも同時にアップグレードします。

結論 – TiDBで将来を見据えたデータベースを

ゼロダウンタイムは単なる見せ物ではありません。TiDBのクラウドネイティブで分散SQLアーキテクチャにより、常に稼働するデータ層を実現します。PD / TiKV / TiDBを横断したローリングアップグレード、Raftレプリケーションと自動リーダー再配置による高可用性、負荷下でも可能なオンラインスキーマ変更、読み書き双方に対応する水平スケーラビリティ。その結果、予測可能なSLO達成、より安全な変更速度、アプリケーション再構築不要な緊急対応の削減を実現します。

ご自身の環境でTiDBを体験してみませんか？TiDBデモセンターでオンラインアップグレードの実演をご覧いただくか、ドキュメントでローリングアップデート、オンラインDDL、移行ツールのステップごとのガイドをご確認ください。