YugabyteDBのドキュメントを全部読む Day6

前回からつづいてYugabyteDBのドキュメントを読んでいきます。

ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。

Table Cration

YugabyteDBではユーザーにより実行されるテーブルの作成はYB-Masterのリーダーが実行する非同期APIによって管理される。

YB-MasterはそのAPIでテーブルのスキーマと障害耐性を高めるために形成するRaftグループに所属するYB-Masterでのテーブル作成に必要な他の情報のレプリケーションが完了した段階でAPIの成功を返す。

YB-Masterのリーダーがテーブル作成を実行するときは複数のステップが存在する。

YB-Masterリーダーはテーブルスキーマの検証を行ない、指定された数のタブレットを作成する。

これらのタブレットはこの段階ではYB-TServerには割り振られていない。

YB-MasterリーダーはYB-MasterのRaftグループにテーブルスキーマと新しく作成されたタブレット(この時点ではYB-TServerへの割り当て行なわれていない)の複製を行なう。

この処理はYB-Masterリーダに障害が発生してもテーブル作成が成功することを保証する。

テーブル作成処理はYB-Masterリーダーに障害が発生しても処理を継続することが出来るため、この段階で非同期テーブル作成APIは成功を返す。

YB-Masterリーダーはそれぞれのタブレットをレプリケーションファクターとして指定された数だけYB-TServerに割り当てを行なう。

このタブレットピアーの配置は指定された障害耐性を実現でき、またタブレットの割り当てがYB-TServerに均等に行なわれるように実行される。

タブレットのYB-TServerへの割り当てはタブレットのレプリカが複数クラウド、リージョン、アヴェイラビリティゾーンをまたいで分散するといった追加の制約を満す必要がある。

YB-Masterリーダーは全てのタブレットの割り当て処理を監視し、その実行状態と完了をユーザーが実行したAPIコールに対して応答する必要がある。

テーブルが4ノードからなるYugabyteDBUniverseに作成される処理について考える。このときテーブルは16のタブレットと3つのレプリケーションファクターを持つとする。

YB-Masterリーダーはスキーマを検証する。また16タブレット(合計48のタブレットピアー)を作成し、 Raftを利用して過半数のYB-TServerにテーブルの作成に必要なデータを複製する。
作成したタブレットをRaftグループを成すYB-TServerの中の指定された数のYB-TServer割り当て、リーダーの選出を行なう。このタブレットに属するキーに対する全てのリードとライトは、タブレットピアーのリーダーとRaftグループが責任を持つ。
タブレットが割り当てられると長期に渡る障害か将来のロードバランシングが発生しYB-Masterにオーナーシップを変更されるまで、割り当て先のYB-TServerが所有する。タブレットリーダーをホストするYB-TServerの内の1台に障害が発生した場合、タブレットのRaftグループはI/Oを処理するために即座にリーダーエレクションを実行する。そのためYB-MasterはI/Oにおけるクリティカルパスになることはない。
YB-TServerが長時間に渡り障害状態にある場合、YB-Masterはデータのレプリケーション先となる候補を探す。この複製処理は段階的かつGracefulに実行される。