はじめに

第3弾です。引き続き以下のページを訳していきます。

Technical Description — Galera Cluster Documentation

take-she12.hatenablog.com

Replication API

同期レプリケーションには"eager replication"を用います。クラスタのノードは1つのトランザクションを、レプリカ更新によってすべてのノードに同期します。これは、トランザクションがコミットするとき、すべてのノードは同じ値を持つことを意味します。(訳注：これがすなわちeager replicationのことですね) このプロセスはグループコミュニケーションを通じてwrite-setを扱います。

途中にある図はgalera clusterとその周辺コンポーネントのアーキテクチャです。

データベース管理システム(DBMS)
- データベースサーバはそれぞれ個別のノード上で実行されます。galera clusterはMySQLまたはMariaDBを扱うことができます。
wsrep API
- データベースサーバとレプリケーションプロバイダへのインターフェイスであり、これは以下を含みます。
  - wsrep hooks: write-setレプリケーションのためにデータベースサーバエンジンを統合します
  - dlopen(): wsrep providerがwsrep hooksを使えるようにする機構です
Galeraレプリケーションプラグイン
- write-setレプリケーションをサービスとして使わせるためのプラグイン。
グループコミュニケーションプラグイン
- 様々なグループコミュニケーションシステムがGalera Clusterを利用可能になる。例えばgcommとspreadがある。
訳者コメント：
- gcommは、複数ノードがいたとして、クラスタ間の通信をサポートするもので、それがグループコミュニケーションと言われている。それをgalera replication pluginがサポートする。そしてdlopen -> wsrep hooksの層でwrite-setの伝搬をサポートし、実際にDBMSにコミットされる、という風に理解した。個人的には上下逆のほうがわかりやすい。

wsrep API

wsrep APIはデータベースに対する一般的なレプリケーションプラグインインターフェイスである。アプリケーションのコールバックとレプリケーションプラグインの呼び出しの集合を定義する。

wsrep APIはデータベースサーバに状態を持たせるレプリケーションモデルを使用する。状態はデータベースの中身に紐づく。データベースを使用しているとき、クライアントがデータベースの内容を修正すると、それは状態を変更することを意味する。wsrep APIはATOMICな変更、あるいはトランザクションの集合(訳注：これはwrite-setを意味すると思う)として、データベースの状態変更を表現する。

データベースクラスタでは、すべてのノードが常に同じ状態である。これらは、同じ順番で状態変更を同期させる。

より技術的な視点で見ると、Galera Clusterは以下のプロセスで状態変更を行う

クラスタ内の1つのノードで、データベースに対する変更が行われる
データベースで、wsrep hooksがwrite-setへの変更として解釈する
dlopen() が wsrep provider functionにwsrep hooksを利用可能にする
Galeraレプリケーションプラグインがwrite-set証明とレプリケーションをクラスタに対して扱う

(訳注：特にこれまでの説明と同じ気がする。。。)

クラスタ内の各ノードで、優先度の高いトランザクションによってアプリケーションプロセスが発生する。(？）

Global Transaction ID

クラスタ間で状態を個別に保つために、wsrep APIはGlobal Transaction ID(GTID)を用います。これは状態変更を特定し、最後の状態変更と現在の状態との関係を特定します。

Global Transaction IDは以下のコンポーネントを含みます。

State UUID: 状態とそれが受ける変更のシーケンスの識別子
Ordinal Sequence Number: シーケンスの中で変更位置を示すために使われる、64-bit signed integerのシーケンス番号。

Global Transaction IDはアプリケーションの状態と状態変更の順番の成立を比較します。これを変更が適用されたかどうかと、変更が与えられた状態に全てに適用可能かどうかを決定するために使うことができます。

(訳コメント：Global Transaction IDでクラスタ内の各ノードがどこまでDBの変更を書き込んでいるかを管理しているみたいですね。write-setなのかわかりませんが、ある塊でState UUIDが変更されて、1つのstate UUIDの中では後半のOrdinal Sequence Numberで位置を特定できそうです。となるとState UUIDはどの単位で変わるのかが気になりますね。。。)

Galera Replication Plugin

Galera Replication Pluginはwsrep APIを実装します。wsrep Providerを操作します。

より技術的な観点からみると、Galera Replication Pluginは以下のコンポーネントを含みます。

Certification Layer: このレイヤーはwrite-setを準備し、証明チェックを行い、受け入れられるかを保証します
Replication Layer: このレイヤーはレプリケーションプロトコルを管理し、順番を並び替えます
Group Communication Framework: このレイヤーはGalera Clusterに接続する様々なgroup communication systemのためのプラグイン構造です。

Group Communication Plugins

Group Communication Frameworkは様々なgcommシステムに対してのプラグイン構造を提供します。

Galera Clusterは独自のgrouo communication system layerを実装しています。これは仮想的にQoSと同期する実装です。仮想的な同期はデータ転送とクラスタのメンバーシップサービスをひとまとめにし、メッセージ配信セマンティクスに明確な形式を提供します。(？）

仮想的な同期が一貫性を保証している一方で、スムースなマルチマスター操作のために必要な時間同期は保証しません。これを避けるために、Galera Clusterは自身で設定可能な時間フロー制御を実装しています。フロー制御は1秒単位でノードを同期させます。

これに加えて、Group Communication Frameworkは複数の送信元からの全てのメッセージ順番を提供します。これを用いてマルチマスタクラスタでのGlobal Transaction IDを生成しています。

Transaportレベルでは、Galera Clusterは対象無向グラフです。すべてのデータベースノードは互いにTCPコネクション上で接続します。デフォルトではTCPはメッセージレプリケーションとクラスタメンバシップサービスの両方に用いられますが、LANでのレプリケーションにUDP マルチキャストを使うこともできます。

(訳コメント：まずGroup Communicationの仕組みでメンバ管理、メンバ間の通信、メッセージの順番を管理している。replication pluginを通じてwsrep APIを叩き、GTIDを生成して一貫性を保証している、ということですね。わかったようなわからんような。)

ツナワタリマイライフ

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

Galera Clusterの同期の仕組みを公式ドキュメントから読み解く(3) Replication API