はじめに
Cofiguration編第2弾。
Galeraで最も重要な概念、state transferのうち、State Snapshot Transfer(SST)について。
State Snapshot Transfers — Galera Cluster Documentation
ノードがクラスタからstate transferを要求するとき、デフォルトではISTメソッドを用います。しかし、ISTが可能なノードが見つからなかったり、wsrep_sst_donorパラメタで手動で相手をしていした場合、State Snapshot Transfer(SST)メソッドを用います。
Galera ClusterはSSTに対していくつかのバックエンド・メソッドをサポートしています。これには2種類あり、データベースサーバのインタフェースとクライアントを通じて行うLogical State Snapshotと、物理的に、ノードから直接データをコピーするPhysical State Snapshotがあります。
(訳注：表は省略しますが、mysqldump、rsyc、xtrabackupの3つのメソッドがあります。それぞれ同期のスピード、そしてdonorとして選択したノードが更新を受け付けるかどうか、生きてるノードで利用可能かは、Blocks Donorとなにが違うんだろう？Typeは前に言った論理か物理(logicalかphysical)、最後のDB root accessもわかんないな。mysqldサーバにroot権限でアクセスするかどうかかな？)
このメソッドはwsrep_sst_methodパラメタで指定します。
State Snapshot Transferにとってベストなメソッドは1つではありません。それぞれにあった正解があります。幸いにも受信ノードだけにmethodを設定すればよいです。donorがそれをサポートしていれば、joinerがリクエストしたmethodで転送します。
LOGICAL STATE SNAPSHOT
この方法ではメソッドはmysqldump、1つです。
Logical State Transfer Methodは以下のような利点を持ちます。
- Liveなサーバ全て利用可能です。実際、初期化されたサーバすべてがLogical State Snapshotを受信できます。
- 受信ノードとdonorノードが同じ設定を持っている必要性がありません。storage engine optionをupgradeすることができます（？？？）
例えば、antelopeからbarracudaファイルフォーマットにマイグレーションしてこのtransferメソッドを使うとき、パーティションから別のパーティションへ圧縮またはiblogを移動させればよいのです。
(訳注：これはストレージエンジンの設定変更が伴う同期でも、SQL文を通じて実行するから、実行可能だということでしょうね。)
Logical State Transferは以下の欠点があります。
- 遅い
- donorと加入ノード両方にrootで接続可能でないといけない
- 受信するサーバはデータベースが壊れていない状態でないといけない(?)
mysqldump
mysqldumpの利点は動作しているサーバにstate snapshotが使えることだろう。これはサーバをすtなどアロンで起動させてクライアントコマンドラインからクラスタへの加入を指示できるということである。また、フォーマットの異なるデータベース間で使用することもできる。
mysqldumpは受信ノードがフル機能を持つデータベースであることを必要とする。そのためdonorノードと他のノード両方でroot権限が必要となる。
このtransferメソッドはかなりのデータベースで他のメソッドより遅くなってしまう。しかし、とても小さいデータベースであれば早いこともあるだろう。例えば、ログファイルより小さいデータベースであれば。
注意：警告：このメソッドは各ノードで実行されるmysqldumpのバージョンに非常に敏感である。それぞれインストールされたバージョンがクラスタ間で統一されてないかもしれない。State Snapshot Transferはあるノードと新しいノードで非互換があると失敗してしまう。
時々、mysqldumpが唯一の選択肢なこともある。例えば、MySQL 5.1から5.5へ、InnoDB pluginがupgradeするときである。
mysqldumpスクリプトは送信ノードでのみ動く。スクリプトの出力はMySQL clientを通じて加入ノードに流し込まれる。
mysqldumpがデータベースclientを通じて行われるから、設定はwarep_sst_methodパラメタの設定範囲を超えて、いくつかのステップが必要となる。設定方法は次を参照。
PHYSICAL STATE SNAPSHOT
Physical State Snapshotにはrsyncとxtrabackupの2つのバックエンドメソッドがある。
Physical State Transferメソッドは以下のような利点がある。
- データをディスク上の物理的なデータコピーを行うので、データベースサーバに依存しない。
- donorノードが以前参加していたときのデータを上書きするので、データベースが稼働状態にある必要がない（？）
- 速い
Physical State Transferは以下のような欠点があります。
- 加入ノードはdonorノードと同じストレージエンジンの設定を持つ必要があります。(ディレクトリ構成など)
- ストレージエンジンが初期化されたサーバではtransferを受信できない(?)
これはノードがstate snapshotを要求するとき、データベースサーバは変更を適用するために再起動しなければならないことを意味します。(?) データベースサーバはストレージエンジンなしで認証を行うことができないので、state snapshot transferが完了するまでclientからのアクセスを受け入れられません。(?)
rsync
State Snapshot Transferで最も速いバックエンドメソッドがrsyncです。Ohysical Snapshot Transferの全ての利点と欠点を持ちます。転送している間、donorノードはブロックされますが、データベースの設定やルートアクセスを必要とせず、その設定も簡単です。
テラバイトスケールのデータベースを使っているとき、rsyncはxtrabackupの1.5から2倍速いでしょう。
rsyncは差分を転送するアルゴリズムを持つので、rsync-wan変更という特徴も持ちます。しかし、これはよりI/Oに強く依存するだけでなく、ネットワークスループットもボトルネックになりえます。
注意：もっともよくあることとして、このメソッドはdonorとjoiningノードでのrsyncバージョン間の非互換に出くわすことがあります
rsyncスクリプトはdonorとjoiningノードの両方で動きます。joinerのほうでは、rsyncをサーバモードで開始し、donorからの接続を待ちます。donorでは、rsyncをクライアントモードで開始し、データディレクトリをjoiningノードに送信します。
(訳注：donorのほうからjoinerに送信するんですね、意外。)
xtrabackup
State Snapshot Transferでもっともポピュラーなバックエンドメソッドがxtrabackupです。Physical State Snapshotの利点と欠点を持ちますが、仮想的にdonorノードではnon-blockingとなります。
xtrabackupはMyISAMテーブルをコピーする短時間だけdonorノードをblockします。これらのテーブルが小さければ、ブロック時間はとても短くて済みます。しかし、これはスピードがコストとなります。xtrabackupはrsyncよりかなり遅くなります。
xtrabackupは短時間でデータ全体をコピーしますが、donorの性能を著しく劣化させます。
注意：このメソッドでは設定に気をつけましょう。xtrabackupは設定ファイルのオプションにいくつか設定が必要ですが、donorサーバにはrootアクセスが必要となります。
おわりに
xtrabackupを使ったことがないんですが、mysqldump同様、普段はdumpに使うんですかね？ノードをブロックにしない点がrsyncより勝っていますが、遅いようですね。
リストアがかなり速いようですね。
それでは！
