はじめに
Configuration編第4弾。quorumの再計算について。
Resetting the Quorum — Galera Cluster Documentation
RESETTING THE QUORUM
時々、Primary Componentの一部でなくなったノードが見られることもあるでしょう。例えば、ネットワーク障害や、クラスタの半分異常が故障した場合、あるいはsplit-brainが起きた時。これらのケースでは、ノードは接続されていない他のノードがPrimary Componentであると考えます。
これが起きた時、全てのノードは全てのqueryにUnknown command errorを返却します。wsrep_cluster_status変数を見ることでこの状況が発生しているかどうか確認できます。以下のクエリを各ノードで実行しましょう。
SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status'; +----------------------+---------+ | Variable_name | Value | +----------------------+---------+ | wsrep_cluster_status | Primary | +----------------------+---------+
Primaryという値が返却された場合、そのノードがPrimary Componentであることを示します。queryが他の値を返却したとき、ノードが操作不能であることを示します。Primaryと返すノードが存在しない場合、それはquorumのリセットが必要であることを意味します。
注意：Primary Componentを示すノードが存在しないケースが非常にまれであることに注意してください。あるノードがPrimaryを返す場合は、quorumのリセットは必要なく、ネットワークの問題です。接続の問題をトラブルシュートしましょう。ノードのネットワークが再接続されると、Primary Componentと自動的に再同期されます。
FINDING THE MOST ADVANCED NODE
quorumをリセットする前に、クラスタ内でもっとも進んでるノードを特定する必要があります。これは、最後のトランザクションがコミットされたデータベースを探すということです。quorumをリセットする方法にかかわらず、このノードは新しいPrimary Componentとしてスタートします。
クラスタ内でもっとも進んでいるノードを特定することには、もっともシーケンスナンバーが進んでいるノードを探す必要があります。wsrep_last_commitedステータス変数を使いましょう。
各ノードで、以下のクエリを実行します。
SHOW STATUS LIKE 'wsrep_last_committed'; +----------------------+--------+ | Variable_name | Value | +----------------------+--------+ | wsrep_last_committed | 409745 | +----------------------+--------+
ここで返却された値は、各ノードでの最後のtransactionのシーケンスナンバーです。クラスタ内でこの番号がもっとも高いノードがもっとも進んでいるノードです。新しいPrimary Componentとしてbootstrapするときはこのポイントを使います。
RESETTING THE QUORUM
quprumをリセットするときに行うことは、使用可能なノードのうちもっとも進んでいるノードでPrimary Componentを起動することです。このノードは新しいPrimary Componentとして機能するもので、クラスタの残りのノードはその状態に合わせます。
このプロセスでは、automaticとmanualの2つの方法があります。
注意：quorumのリセットで好ましい方法はautomaticメソッドです。manualメソッドと違って、automatic bootstrapsはwrite-set cache(すなわちGCache)を各ノードで保持します。これが意味することはあらたなPrimary Componentが起動したとき、joiningノードのいくつか、またはすべてはISTメソッドを使うことになります。
Automatic Bootstrap
quprumをリセットすると、最も進んでいるノード上でPrimary Componentをbootstrapします。これによってautomatic methodではデータベースクライアントを通じて、wsrep_provider_optionsの下のpc.bootstrapを動的に有効にすることで行われます。
自動的にbootstrapを行うために、最も進んでいるデータベースクライアントで、以下のコマンドを実行します。
SET GLOBAL wsrep_provider_options='pc.bootstrap=YES';
ノードは新しいPrimary Componentとして起動します。操作できないcomponentのノードは可能な限りISTでのネットワーク再接続を試み、もしできなければSSTを行います。
Manual Bootstrap
quorumをリセットすると、最も進んでいるノードでPrimary Componentをbootstrapします。manualメソッドでは、クラスタをシャットダウンし、もっとも進んでいるノードで再起動します。
- 全てのクラスタノードをシャットダウンします。initを使ってる場合は、以下のコマンドを実行します。
# service mysql stop
- もっとも進んでいるノードで、--wsrep-new-clusterオプションをつけて起動します。
# service mysql start --wsrep-new-cluster
- クラスタ内の他のノードを全て起動します。
# service mysql start
最初のノードで--wsrep-new-clusterオプションをつけて起動した時、以前のクラスタでもっとも進んでいるノードのデータを使って初期化します。他のノードはこのノードに接続し、データベースを更新するためにstate snapshot transferをリクエストします。
おわりに
この章ではシンプルに、全ノードが落ちてしまったとき、例えばデータセンターのダウンや、split-brainによって分断してnon-primary(閉塞)に陥った時、どのノードがもっとも進んでいるかを特定し、そこからの復旧の仕方が書かれていました。
これまでは適当にノードを選んで、manual methodでやっていましたね。。。最悪起動しなくてもSSTで加入させるという。
しかしpc.bootstrapをYESにした瞬間に立ち上がるんですかね？ちょっと試してみたいです。
Galera Parameters — Galera Cluster Documentation
これをいれるとNon-PrimaryからPrimaryになるようです。
