ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

Galera Cluster Documentを読む Configuration編(1) NODE PROVISIONING

はじめに

Galera Documentationを読み解くシリーズ、Technical Description編が無事に終わり、次はConfiguration編です。

Galera Cluster Documentation — Galera Cluster Documentation

今回はNODE PROVISIONING。クラスタにノードを追加することですね。

Node Provisioning — Galera Cluster Documentation

NODE PROVISIONING

新しい状態になったとき、あsるいはノードが故障して、クラスタのPrimary Componentが変更されるとき、新規ノードあるいは故障ノードは現状のクラスタと同期しなければなりません。これより、新規ノードのプロビジョニングと故障ノードのリカバリは本質的に同じプロセスで、クラスタのPrimary Componentに参加します。

Galeraは初期化するノードIDをgrastate.txtファイルから読み取り、wsrep_data_dirパラメタによってディレクトリを見つけます。ノードが正常にシャットダウンされたとき毎回、Galeraはこのファイルに保存します。

Total Order Isolationモードでは、ノードがクラッシュした際にデータベースの状態は不明とし、初期化されたノードの状態は未定義になります。

00000000-0000-0000-0000-000000000000:-1

注意:通常のトランザクションが行われているとき、GTIDのシーケンスナンバーだけが未定義になります。(具体的には-1になります) UUIDは確実に残ります。この場合、Incremental State Transferによってノードがリカバリできます。

(訳注:Total Order Isolationとはなんでしょうか。リンク先の飛んでみると、書き込みがあったマスタノードにTransactionを実行する前に、同期しているすべてのノードで書き込み可能か判断してからコミットする仕組みのようですね)

HOW NODES JOIN THE CLUSTER

ノードがクラスタに参加するとき、自身のUUIDをPrimary Componentと比較します。UUIDが一致しない場合、クラスタからのstate transferをリクエストします。

state transferのdonorを決定するときに2つのオプションが利用できます。

  • Automatic: ノードがクラスタに加入しようとしたとき、group communicationレイヤーで、Primary COmponentの中で利用可能なdonorを選択します。
  • Manual: ノードがクラスタに加入しようとした時、wsrep_sst_donorパラメタを使ってdonorを決定します。Primary Componentの中で決定できなければ、state transferは失敗し、加入ノードは加入を放棄します。wsrep_sst_donorパラメタは、wsrep_node_nameパラメタと同じdonorの名前を使用します。

注意:state transferは重たい捜査です。これは加入するノードだけでなく、donorにとってもです。実際donorノードはクライアントのリクエストを受けられないでしょう。 結果的に、(もし可能なら)、donorを手動で選択したほうがいいでしょう。ネットワークの近さや、負荷分散の設定を考慮して選択すべきでしょう。

(訳注:なるべく早く終わるためにネットワーク的に遠いノードではなく近いノードを、また、なるべく同じロードバランサで振り分けられてる、更新量が近いノードを選ぶとstate transferははやく終わるでしょう)

state transferの最中は、加入ノードは他のノードから受け取るwrite-setをキャッシュします。state transferが終わると、現在のPrimary Componentに追いつくために、slaveから受け取るwrite-setを適用していきます。state snapshotがUUIDを知らせるので、snapshotが含むwrite-setと、捨てるwrite-setを決定するのは容易です。

追いつくフェーズでは、flow controlがslaveキューを短くすることを保証します。(これは、追いつくノードでのwrite-setを行う頻度がすなわち複製する頻度になり、上限となるからです)

STATE TRANSFERS

クラスタに加入するノードが行うstate transferには2種類あります。

  • State Snapshot Transfer(SST): donorが加入ノードに対してノード全体のスナップショットを転送する方法
  • Incremental State Transfer(IST): donorは加入しようとするノードに足りないTransactionのみを転送する方法

自動的にdonorが選ばれる場合、Galera clusterのバージョン3.6以降ではクラスタはstate transfer methodがもっとも利用可能であるという観点で決定されます。

  • ISTが安全に実行できるノードが存在しない場合、クラスタはstate snapshot transferを用いる
  • ISTが安全に実行できるノードが存在しない場合、donorにとってリモートノードよりローカルノードを好む
  • ISTが安全に実行できるローカルノードが存在しない場合、クラスタはリモートノードを選択する
  • ISTが安全に実行できるノードがlocalとremoteいくつか存在する場合、クラスタはseqnoがもっとも高いノードを選択する

(訳注:SSTでdonorノードが選択される論理について説明されています。local/remoteはネットワーク的な速さで選択しているのかどうか気になりますね。シーケンスナンバーが最も高い=1番更新されているノードが選ばれるのはそれはそうかなって感じです)

おわりに

クラスタのUUIDはなにを契機に変わるんでしょうか、Primary Componentが変わったとき?加入/離脱によって変わったとき?いずれにせよUUIDとseqnoでクラスタは状態を把握していて、その情報(grastate.txt)をもとにクラスタ加入をどのように(IST/SST)行うか決定されます。

クラッシュした場合UUIDはリセットされるのははじめて知りました。実機で見てみよう。