第6章 Galera の使用
高可用性のデプロイメントでは、Red Hat OpenStack Platform は MariaDB Galera Cluster を使用してデータベースのレプリケーションを管理します。「Pacemaker で設定された OpenStack サービス」に記載のとおり、Pacemaker は、 マスター/スレーブ設定のリソースを使用して Galera サービスを実行します。pcs status を使用して、galera-master が実行されているかどうか、またその場合にはどのコントローラー上で実行されているのかを確認することができます。
Master/Slave Set: galera-master [galera]
Masters: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]- ホスト名の解決
- MariaDB Galera Cluster のトラブルシューティングを行う際には、ホスト名の解決 から開始してください。デフォルトでは、director は Galera リソースを IP アドレスではなく hostname にバインドします。[1]そのため、ホスト名の解決を妨げている問題 (例: 設定の誤りや DNS のエラーなど) があると、Pacemaker が Galera リソースを適切に管理できなくなる可能性があります。
ホスト名の解決の問題がないことを確認した後には、クラスター自体の整合性をチェックしてください。そのためには、各コントローラーノードのデータベースで、Write Set Replication のステータスを確認します。
Write Set Replication の情報は、各ノードの MariaDB データベースに保管されます。関連する変数はそれぞれ wsrep_ のプレフィックスを使用します。そのため、この情報はデータベースクライアントで直接問い合わせることができます。
$ sudo mysql -B -e "SHOW GLOBAL STATUS LIKE 'wsrep_%';"
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| wsrep_protocol_version | 5 |
| wsrep_last_committed | 202 |
| ... | ... |
| wsrep_thread_count | 2 |
+------------------------+-------+MariaDB Galera Cluster の正常性と整合性を検証するには、まず最初にクラスターが正しいノード数を報告するかどうかを確認してから、各ノードで以下の点をチェックします。
- 正しいクラスターに属していること
- クラスターへの書き込みが可能であること
- クラスターからクエリーの受信と書き込みが可能であること
- クラスター内の他のノードに接続されていること
- ローカルのデータベースで Write Set をテーブルにレプリケーションしていること
以下の項では、各ステータスを調べる方法について説明します。
6.1. データベースクラスターの整合性の調査
MariaDB Galera Cluster の問題を調査する際には、クラスター自体の整合性から開始してください。クラスターの整合性を検証するには、各コントローラーノード上の特定の wsrep_ データベース変数を確認する必要があります。データベースの変数を確認するには、次のコマンドを実行します。
$ sudo mysql -B -e "SHOW GLOBAL STATUS LIKE 'VARIABLE';"VARIABLE は確認する wsrep_ データベース変数に置き換えてください。たとえば、ノードの cluster state UUID を確認するには、以下のコマンドを実行します。
$ sudo mysql -B -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_state_uuid';"
+--------------------------+--------------------------------------+
| Variable_name | Value |
+--------------------------+--------------------------------------+
| wsrep_cluster_state_uuid | e2c9a15e-5485-11e0-0800-6bbb637e7211 |
+--------------------------+--------------------------------------+以下の表には、クラスターの整合性と関連するさまざまな wsrep_ データベース変数をまとめています。
表6.1 クラスターの整合性を確認するためのデータベース変数
| 変数 | 概要 | 説明 |
|---|---|---|
|
wsrep_cluster_state_uuid |
クラスターの状態の UUID |
ノードが属するクラスターの ID。全ノードに全く同じ ID が割り当てられている必要があります。異なる ID が割り当てられたノードは、クラスターに接続できません。 |
|
wsrep_cluster_size |
クラスター内のノード数 |
これは、任意のノード 1 台で確認することができます。値が実際のノード数を下回る場合には、いずれかのノードでエラーが発生したか、接続を失ったことになります。 |
|
wsrep_cluster_conf_id |
クラスターの変更回数 |
クラスターが複数のコンポーネント (パーティション) に分割されているかどうかを確認します。これは、ネットワークのエラーが原因となっている場合が多いです。全ノードの値が全く同じである必要があります。 異なる wsrep_cluster_conf_id を報告するノードがある場合には、wsrep_cluster_status の値をチェックして、クラスター (Primary) への書き込みができるかどうかを確認してください。 |
|
wsrep_cluster_status |
Primary コンポーネントのステータス |
ノードがまだクラスターへの書き込みをできるかどうかを確認します。可能な場合には、wsrep_cluster_status は Primary のはずです。それ以外の値の場合には、ノードが稼働していないパーティションの一部であることを示します。 |
6.2. データベースクラスターノードの調査
Galera クラスターの問題を特定のノードに切り分けすることができる場合には、その他の wsrep_ データベース変数が具体的な問題を解く手がかりとなる可能性があります。これらの変数は、クラスターのチェック (「データベースクラスターの整合性の調査」に記載) と同様の方法で確認することができます。
$ sudo mysql -B -e "SHOW GLOBAL STATUS LIKE 'VARIABLE';"同様に、VARIABLE は以下の値のいずれかに置き換えます。
表6.2 ノードの整合性を確認するためのデータベース変数
| 変数 | 概要 | 説明 |
|---|---|---|
|
wsrep_ready |
ノードがクエリーを受け入れる機能 |
ノードがクラスターから write set を受け入れることができるかどうかを示します。受け入れることができる場合には、wsrep_ready は ON のはずです。 |
|
wsrep_connected |
ノードのネットワーク接続性 |
そのノードが他のノードに接続されているかどうかを示します。接続されている場合には、wsrep_connected は ON のはずです。 |
|
wsrep_local_state_comment |
ノードの状態 |
ノードの状態の概要を示します。ノードがクラスターにまだ書き込みができる場合 (すなわち、wsrep_cluster_status が Primary の場合。「データベースクラスターの整合性の調査」 を参照) には、wsrep_local_state_comment の通常の値は Joining、Waiting on SST、Joined、Synced、Donor です。 ノードが稼働していないコンポーネントの一部の場合には、wsrep_local_state_comment は Initialized に設定されます。 |
wsrep_connected が ON の場合には、そのノードが 一部の ノードのみに接続されている可能性があることも意味します。たとえば、クラスターのパーティションの場合には、そのノードは、クラスターに書き込みができないコンポーネントの一部となっている可能性があります。詳しくは、「データベースクラスターの整合性の調査」 を参照してください。
wsrep_connected が OFF の場合には、そのノードは、どのクラスターコンポーネントにも接続されていません。
6.3. データベースレプリケーションのパフォーマンスの調査
クラスターおよびそのクラスター内の個々のノードが正常な状態で安定している場合には、レプリケーションのスループットを確認して、パフォーマンスのベンチマークを行うこともできます。「データベースクラスターノードの調査」および「データベースクラスターの整合性の調査」に記載したように、この操作には各ノードの wsrep_ データベース変数が必要です。
$ sudo mysql -B -e "SHOW STATUS LIKE 'VARIABLE';"同様に、VARIABLE は以下の値のいずれかに置き換えます。
表6.3 クラスターのパフォーマンス (レプリケーションのスループット) を確認するためのデータベース変数
| 変数 | 概要 |
|---|---|
|
wsrep_local_recv_queue_avg |
最後にクエリーされた後のローカル受信キューの平均サイズ |
|
wsrep_local_send_queue_avg |
その変数が最後にクエリーされた後の送信キューの平均の長さ |
|
wsrep_local_recv_queue_min and wsrep_local_recv_queue_max |
いずれかの変数が最後にクエリーされた後のローカル受信キューの最小サイズと最大サイズ |
|
wsrep_flow_control_paused |
その変数が最後にクエリーされた後に フロー制御 が原因でノードが一時停止された時間の割合 |
|
wsrep_cert_deps_distance |
並行して適用可能なシーケンス番号 (seqno) の最小値と最大値の幅の平均 (潜在的な並列化度) |
それらの変数のいずれかをクエリーするときには毎回、FLUSH STATUS コマンドを実行すると値がリセットされます。クラスターのレプリケーションのベンチマークを行うには、それらの値を複数回クエリーして、その変化を確認する必要があります。この変化は、フロー制御 がクラスターのパフォーマンスにどの程度影響を及ぼしているかを判断するのに役立てることができます。
フロー制御 とは、クラスターがレプリケーションを制御するのに使用するメカニズムです。ローカル受信 Write Set キューが一定の閾値を超えると、ノードがそのキューに追い付くために、フロー制御がレプリケーションを一時停止します。詳しくは、Galera Cluster のサイトで、「Flow Control」のセクションを参照してください。
異なる値とベンチマークについての説明は以下の一覧を確認してください。
- wsrep_local_recv_queue_avg > 0.0
- ノードが 受信に対応できる速度で Write Set を適用することはできないため、レプリケーションのスロットルがトリガーされます。このベンチマークの詳しい情報は、wsrep_local_recv_queue_min とwsrep_local_recv_queue_max を確認してください。
- wsrep_local_send_queue_avg > 0.0
- wsrep_local_send_queue_avg の値が高くなると、レプリケーションのスロットルとネットワークスループットの問題が発生する可能性も高くなります。これは特に wsrep_local_recv_queue_avg の値が高くなると、その傾向が強くなります。
- wsrep_flow_control_paused > 0.0
フロー制御によりノードが一時停止されています。ノードが一時停止されている時間を確認するには、wsrep_flow_control_paused の値をクエリーの間隔の秒数で乗算してください。たとえば、最後のチェックから 1 分後に wsrep_flow_control_paused = 0.50 となった場合には、ノードのレプリケーションは 30 秒停止されたことになります。また、wsrep_flow_control_paused = 1.0 の場合には、最後のクエリーからずっと停止していたことになります。
理想的には、wsrep_flow_control_paused は可能な限り 0.0 に近い値であるべきです。
スロットルおよび一時停止の場合には、wsrep_cert_deps_distance をチェックして、(平均で) 適用可能な write set の数を確認することができます。その後に、wsrep_slave_threads をチェックして、同時に適用された write set の実際の数を確認します。
Configuring a higher wsrep_slave_threads の値を高くすると、スロットルと一時停止を軽減することができます。たとえば、wsrep_cert_deps_distance の読み取った値が 20 の場合は、wsrep_slave_threads を 2 からその倍の 4 に指定すると、そのノードが適用できるWrite Set の量も 2 倍になります。ただし、wsrep_slave_threads はそのノードの CPU コア数以下に設定する必要があります。
問題のあるノードで、wsrep_slave_threads がすでに最適に設定されている場合には、接続の問題の可能性を調査するためにそのノードをクラスターから除外することを検討してください。
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.