MySQLまたはMariaDBGaleraクラスターをブートストラップする方法-更新

標準のMySQLサーバーやMySQLクラスターとは異なり、MySQL /MariaDBGaleraクラスターを起動する方法は少し異なります。 Galeraでは、残りのノードが参加してクラスターを形成する前に、参照ポイントとしてクラスター内のノードを開始する必要があります。このプロセスは、クラスターブートストラップと呼ばれます。ブートストラップは、データベースノードをプライマリコンポーネントとして導入するための最初のステップであり、他の人がデータベースノードをデータを同期するための参照ポイントと見なす前に行われます。

どのように機能しますか？

Galeraがノードでbootstrapコマンドを開始すると、その特定のノードはプライマリ状態になります（wsrep_cluster_statusの値を確認してください）。残りのノードは通常の開始コマンドを必要とするだけで、クラスター内の既存のプライマリコンポーネント（PC）を自動的に検索し、参加してクラスターを形成します。次に、データの同期は、ジョイナーとドナー間のインクリメンタル状態転送（IST）またはスナップショット状態転送（SST）のいずれかを介して行われます。

したがって、基本的には、新しいクラスターを開始する場合、またはクラスター内の他のノードがPRIMARY状態にない場合にのみ、クラスターをブートストラップする必要があります。実行するアクションを選択するときは注意が必要です。そうしないと、クラスターが分割されたり、データが失われたりする可能性があります。

次のシナリオ例は、ノード状態（wsrep_local_state_comment）とクラスター状態（wsrep_cluster_status）に基づいて3ノードクラスターをブートストラップするタイミングを示しています。

Galera State	ブートストラップフロー
	INITIALIZEDノードを再起動します。
	INITIALIZEDノードを再起動します。完了したら、新しいノードを起動します。
	「pc.bootstrap=1」を使用して最も高度なノードをブートストラップします。残りのノードを一度に1ノードずつ再起動します。
	新しいノードを開始します。
	新しいノードを一度に1ノードずつ開始します。
	任意のノードをブートストラップします。残りのノードを一度に1ノードずつ開始します。

ガレラクラスターを開始するには？

3つのGaleraベンダーは、（ソフトウェアの最新バージョンに基づいて）異なるブートストラップコマンドを使用します。最初のノードで、次を実行します：

MySQL Galera Cluster（Codership）：

$ service mysql bootstrap # sysvinit
$ galera_new_cluster # systemd
$ mysqld_safe --wsrep-new-cluster # command line

Percona XtraDBクラスター（Percona）：

$ service mysql bootstrap-pxc # sysvinit
$ systemctl start [email protected] # systemd

MariaDBガレラクラスター（MariaDB）：

$ service mysql bootstrap # sysvinit
$ service mysql start --wsrep-new-cluster # sysvinit
$ galera_new_cluster # systemd
$ mysqld_safe --wsrep-new-cluster # command line

上記のコマンドは単なるラッパーであり、実際に実行されるのは、wsrep_cluster_address変数としてgcomm：//を使用してそのノードでMySQLインスタンスを起動することです。 my.cnf内の変数を手動で定義し、標準のstart/restartコマンドを実行することもできます。ただし、開始後にすべてのノードのアドレスが含まれるように、wsrep_cluster_addressを再度変更することを忘れないでください。

最初のノードが稼働しているときに、後続のノードで次のコマンドを実行します。

$ service mysql start
$ systemctl start mysql

新しいノードは、wsrep_cluster_addressパラメーターで定義されたクラスターメンバーに接続します。これで、クラスターマップが自動的に取得され、残りのノードに接続してクラスターが形成されます。

警告：ノードを既存のクラスターに再接続する場合は、ブートストラップを実行しないでください。また、複数のノードでブートストラップを実行しないでください。

安全なブートストラップフラグ

バージョン3.19以降のGaleraには、grastate.dat内に「safe_to_bootstrap」という新しいフラグが付属しています。このフラグは、ノードがシャットダウンされている順序を追跡することにより、決定を容易にし、安全でない選択を防ぎます。最後にシャットダウンされたノードは、「Safe-to-Bootstrap」としてマークされます。他のすべてのノードは、ブートストラップするのに安全ではないとマークされます。

grastate.dat（デフォルトはMySQL datadirの下にあります）のコンテンツを見ると、最後の行のフラグに気付くはずです：

# GALERA saved state
version: 2.1
uuid:    8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno:   2575
safe_to_bootstrap: 0

新しいクラスターをブートストラップするとき、Galeraは、ブートストラップが安全でないとマークされた最初のノードの開始を拒否します。ログに次のメッセージが表示されます。

「このノードからクラスターをブートストラップするのは安全ではない可能性があります。クラスターを離れたのはこれが最後ではなく、すべての更新が含まれていない可能性があります。

このノードでクラスターのブートストラップを強制するには、grastate.datファイルを手動で編集し、safe_to_bootstrapを1に設定します。」

クリーンでないシャットダウンまたはハードクラッシュの場合、すべてのノードが「safe_to_bootstrap：0」になるため、InnoDBストレージエンジンを調べて、クラスター内の最後のトランザクションをコミットしたノードを特定する必要があります。これは、各ノードで「--wsrep-recover」変数を使用してmysqldを起動することで実現できます。これにより、次のような出力が生成されます。

$ mysqld --wsrep-recover
...
2016-11-18 01:42:15 36311 [Note] InnoDB: Database was not shutdown normally!
2016-11-18 01:42:15 36311 [Note] InnoDB: Starting crash recovery.
...
2016-11-18 01:42:16 36311 [Note] WSREP: Recovered position: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f:114428
...

「Recoveredposition」行のUUID文字列の後の番号が検索対象です。次の例に示すように、番号が最も大きいノードを選択し、そのgrastate.datを編集して「safe_to_bootstrap：1」を設定します。

# GALERA saved state
version: 2.1
uuid:    8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno:   -1
safe_to_bootstrap: 1

次に、選択したノードで標準のブートストラップコマンドを実行できます。

ノードが分岐した場合はどうなりますか？

特定の状況では、ノードが互いに分岐している可能性があります。ノード間のネットワーク分割、クラスタークラッシュ、またはプライマリコンポーネントの決定時にGaleraが例外をヒットした場合、すべてのノードの状態が非プライマリになる可能性があります。次に、ノードを選択して、それをプライマリコンポーネントに昇格させる必要があります。

ブートストラップする必要のあるノードを判別するには、すべてのDBノードのwsrep_last_committed値を比較します。

node1> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name        | Value       |
+----------------------+-------------+
| wsrep_last_committed | 10032       |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+

node2> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name        | Value       |
+----------------------+-------------+
| wsrep_last_committed | 10348       |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+

node3> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name        | Value       |
+----------------------+-------------+
| wsrep_last_committed |   997       |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+

上記の出力から、node2には最新のデータがあります。この場合、すべてのGaleraノードがすでに開始されているため、必ずしもクラスターを再度ブートストラップする必要はありません。 node2をプライマリコンポーネントに昇格させる必要があります：

node2> SET GLOBAL wsrep_provider_options="pc.bootstrap=1";

その後、残りのノードはプライマリコンポーネント（node2）に再接続し、このノードに基づいてデータを再同期します。

ClusterControlを使用している場合（無料で試してください）、ClusterControl>の概要から直接wsrep_last_committedとwsrep_cluster_statusを確認できます。ページ：

または、ClusterControl>パフォーマンス>DBステータスからページ：