分散バックアップの課題解決：TiDBがトランザクション一貫性を実現する方法

※このブログは2026年2月26日に公開された英語ブログ「Solving the Distributed Backup Headache: How TiDB Delivers Transactional Consistency」の拙訳です。

主なポイント

• 従来のシステムがストレージファイルをそのままコピーするのとは異なり、TiDBはバックアップを単一の、グローバルに一貫性のあるタイムスタンプに固定します。
• クラスタ全体での境界を使用することで、TiDBはノードごとにトランザクション状態が競合した状態になる「断片化された」バックアップを回避します。
• コミットされたデータのみが記録され、正確なポイントインタイムリカバリ (PITR) が可能になります。
• バックアップ時に一貫性が確保されるため、復元作業において手動での調整、ロックのクリーンアップ、またはトランザクションの部分的な修復を行う必要はありません。
• TiDBのバックアップモデルは、ノード中心ではなくトランザクション中心であり、ネイティブな分散ACID基盤を活用してデータ保護を簡素化します。

分散データベースのバックアップとは、単に複数のマシンからファイルのコピーを調整することではなくトランザクション処理中のシステム全体で、単一の一貫性のある時点のデータを取得することです。

TiDBでは、データは多数のノードに分散されています。トランザクションは2フェーズコミットプロトコルを用いたMVCCを使用します。トランザクションは複数のパーティションに同時にアクセスする可能性があります。任意の時点では、トランザクションはコミット済みであったり、進行中であったり、部分的に書き込まれた状態であったりします。

バックアップにおける最大の課題は明らかです。それは、クラスタが稼働している状態で、クラスタ全体の論理的に一貫した状態をどのように取得するか、ということです。

分散データベースバックアップの不整合のリスク

TiDBが独自の方法でバックアップに取り組む理由を理解するためには、不整合な状態でデータをバックアップするリスクを理解することが重要です。各ノードでストレージファイルを個別にバックアップすると、システムが断片化された状態のバックアップを取得するリスクがあります。データベースクラスタの各パーティションが、異なるトランザクション状態を反映する可能性があります。

• あるパーティションではコミットされたトランザクションが含まれるが、別のパーティションでは含まれていません。
• いくつかの変更は書き込まれているが、完全にはコミットされていません。
• 不完全な更新が、対応するトランザクションの状態を考慮しないでに表示されます。

バックアップに部分的なトランザクションが含まれる場合、リストア操作では追加の修正措置が必要になります。システムを安全に再開する前に、不整合を検出して修復する必要があります。この照合作業は、特にストレスの多い障害発生時には、復旧時間と運用リスクを増加させます。

分散システムでは、多くの場合バックアップ速度よりもリストアの複雑さの方が重要です。

完全バックアップ：グローバルなトランザクション境界に固定

TiDBのバックアップおよび復元ツール (BR) は、バックアップのアプローチが異なります。ストレージのファイルをそのままコピーするのではなく、TiDBは各フルバックアップを単一のグローバルに一貫性のあるタイムスタンプに固定します。このタイムスタンプは、クラスタ全体における実際のトランザクション境界を表します。

バックアップ処理では、その時点で確定して見えているデータを正確に読み取ります。

• 進行中のトランザクションは除外されます。
• 完全にコミットされた変更のみが含まれます。
• すべてのパーティションが同じ論理的な時点を反映します。

バックアップの内容は単なる近似的な状態ではありません。それはクラスタ全体のトランザクションに一貫性のあるスナップショットです。

そのスナップショットがリストアされると、データはすでに内部的に整合性があります。ロッククリーンアップ、部分トランザクション修復、ノード間の照合は必要ありません。

ログのバックアップ：時間の経過に伴う一貫性の維持

全体のスナップショットは、クラスタの状態を定期的に保存します。一方、TiDBのログバックアップは、より厳しいRPO (目標復旧時間) を実現するために、継続的に変更を記録します。

ここでの課題は、変更が分散システム全体で完全かつ安全にコミットされた後にのみ記録されるようにすることです。

TiDBは、それ以前のすべてのトランザクションが完了していることが保証される最新の時点 (解決済みタイムスタンプ) を表す、継続的に更新されるグローバル境界を維持します。ログバックアップに記録される対象となるのは、その境界より前の変更のみです。

これにより以下のことが保証されます。

• 部分的なトランザクションは一切記録されません。
• ポイントインタイムリカバリは、実際のトランザクション状態を反映しています。
• リカバリの境界線が明確に定義され、測定可能になります。

このシステムは、キースペース全体にわたるログバックアップの進行状況 (チェックポイント) も追跡し、これにより明確なリカバリポイント目標が提供され、どこまで安全にリカバリできるかという曖昧さが排除されます。

一貫性は全体スナップショット取得時だけでなく、継続的に維持されます。

分散データベースバックアップ：アーキテクチャの理念と設計

バックアップの動作はデータベースのアーキテクチャとは無関係ではなく、システムの基盤となる整合性モデルを反映します。

分散システムの中には、結果整合性を前提として構築されているものがあります。そのような設計では、ノードは独立したスナップショットとして個別にバックアップされる場合があります。クラスタ全体の一貫性は多くの場合近似値であり、後でバックグラウンドでの修復と調整によって復元され、システムが安定した状態に戻ることが期待されます。

データを独立したMySQLインスタンスに分散させることでスケーリングを行うシステムもあります。バックアップはシャードごとに実行され、「グローバルスナップショット」の取得は、単一のネイティブなトランザクション境界ではなく、外部の運用調整に依存します。

TiDBは異なるアプローチを採用しています。クラスタ全体で時間の概念を共有する分散ACIDトランザクションを提供します。トランザクションは既にグローバルに順序付けられたタイムスタンプモデル (TSO) を共有しているため、バックアップも同じ基盤を利用することができます。これにより、データが複数のノードやリージョンにまたがっていても、すべてのバックアップがクラスタ全体の厳密に一貫性のある特定の時点の状態を表すことが保証されます。

その結果、ノード中心やシャード中心ではなく、トランザクション中心のバックアップモデルが実現されます。一貫性は、リストア操作やリストア後の調整に委ねられるのではなく、バックアップ時に解決されます。

このアーキテクチャ上の選択が、リカバリのあり方を決定づけます。

ワークフローの復元と決定論的リカバリ

一貫性は、バックアップ時だけでなく、リストア時にも維持されなければなりません。

TiDBのリストアプロセスは、データベーススキーマとトランザクション境界を認識します。データは、単なるキー範囲としてではなく、テーブル定義とメタデータに沿ってリストアされます。

これにより、以下のことが可能になります。

• データ取り込み前のテーブルをクリーンに再作成します。
• 新しいクラスタへ復元する際に識別子を正しくマッピングします。
• マルチテナント環境でのテーブル単位で復旧します。

さらに重要なのは、リストア処理が決定論的になり、後続の修正措置が不要になることです。データがロードされた後は、調整すべき部分的なトランザクションも、解釈すべき曖昧な状態もなくなります。

厳しい復旧時間目標 (RTO) を達成するには、データの転送速度だけでなく、システムを運用可能な状態に戻すために必要な作業を最小限に抑えることも重要です。

TiDBは、バックアップ時にトランザクションの一貫性を確保し、リストアワークフローを通じてその整合性を維持することで、最も重要な局面においても予測可能なリカバリを実現します。

決定論的なリカバリを体験してみませんか？TiDBのドキュメントをご覧いただき、利用を始めましょう。