Raftアルゴリズムが実現するデータ一貫性と高可用性の仕組み

はじめに

TiDBが「データが消えない」「サーバーが数台故障しても止まらない」と謳えるのはなぜでしょうか？
それは、分散システムの中核をなすRaft（ラフト）コンセンサスアルゴリズムにあります。

Raftは、複数のサーバー間でデータを安全に複製し、リーダーを自動で選出するための「多数決のルール」です。この記事では、TiDBがどのようにRaftを利用して、高いデータ一貫性と可用性を実現しているのか、その仕組みを解説します。

Raftとは？ 3つの役割で動く多数決システム

Raftを理解するために、3人の司書が同じ本を3冊、常に完璧に同期させるという例えで考えてみましょう。

役割 (Role)	説明 (Description)
リーダー (Leader)	3人のうちの1人。本の原本への書き込みを唯一許可されている。
フォロワー (Follower)	残りの2人。リーダーの指示に従い、自分の本のコピーを更新する。
候補者 (Candidate)	リーダー不在時に、フォロワーの中から「新しいリーダーになります！」と立候補する。

この3つの役割が連携することで、誰か一人が休んでも（サーバーが故障しても）、本のコピー（データ）が常に安全に保たれます。

TiDBにおけるRaftの仕組み：Region単位での合意形成
TiDBでは、このRaftの仕組みがRegionという単位で適用されています。

Regionとは？

TiDBはテーブルのデータを約96MBごとの塊（Region）に分割します。

データ書き込みの流れ (ProposeからApplyまで)

クライアントからINSERT文が実行されると、TiDB内部では以下のRaftフローが実行されます。

ステップ	名前	説明
1.	Propose (提案)	書き込みリクエストは、まずRaftグループのLeaderに送られます。Leaderは、この書き込み内容を「ログ」として記録する提案をします。
2.	Replicate (複製)	Leaderはそのログを各Followerに送り、「この内容を自分のログに追記してください」と依頼します。
3.	Committed (コミット)	過半数のFollowerから「追記しました」という返事を受け取ると、Leaderはそのログを「コミット済み」と判断します。この時点で、データが失われないことが保証されます。
4.	Apply (適用)	コミットされたログの内容が、各ノードのストレージ（RocksDB）に適用され、実際のデータとして書き込まれます。

この「過半数での合意」というステップがあるため、一部のサーバーが応答しなくても、データは安全に書き込まれるのです。

障害発生時：リーダーの自動選出

もしRaftグループのLeaderがいるTiKVサーバーが故障したらどうなるでしょうか？
この一連のプロセスは完全に自動で行われるため、サービスが長時間停止することはありません。これがTiDBの高可用性の秘密です。

ステップ	アクション	説明
1.	リーダーの不在を検知	Followerたちは、一定時間リーダーからの連絡がないことを検知します。
2.	リーダー選挙の開始	Followerは候補者 (Candidate) に役割を変え、「新しいリーダーに立候補します！」と他のメンバーに投票を依頼します。
3.	新しいリーダーの選出	過半数の票を獲得した候補者が、新しいLeaderに選出されます。
4.	サービスの継続	新しいLeaderは、すぐにクライアントからの読み書きリクエストの受け付けを再開します。

この一連のプロセスは完全に自動で行われるため、サービスが長時間停止することはありません。これがTiDBの高可用性の秘密です。

まとめ

TiDBにおけるRaftアルゴリズムは、単なるデータ複製技術ではありません。

データの一貫性: 「過半数の合意」により、書き込まれたデータが常に正しいことを保証します。
高可用性: リーダーの自動選出機能により、サーバー障害が発生してもサービスを継続できます。
水平スケーラビリティ: サーバー（TiKVノード）を追加するだけで、Raftグループが自動的に分散配置され、クラスタ全体の性能が向上します。

この堅牢なRaftの仕組みが、TiDBを金融機関などでも利用される高信頼なデータベースたらしめているのです。