第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 ]

Master/Slave Set: galera-master [galera]
     Masters: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]

Copy to Clipboard

Toggle word wrap

ホスト名の解決: 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_%';"

$ sudo mysql -B -e "SHOW GLOBAL STATUS LIKE 'wsrep_%';"
    +------------------------+-------+
    | Variable_name          | Value |
    +------------------------+-------+
    | wsrep_protocol_version | 5     |
    | wsrep_last_committed   | 202   |
    | ...                    | ...   |
    | wsrep_thread_count     | 2     |
    +------------------------+-------+

Copy to Clipboard

Toggle word wrap

MariaDB Galera Cluster の正常性と整合性を検証するには、まず最初にクラスターが正しいノード数を報告するかどうかを確認してから、各ノードで以下の点をチェックします。

正しいクラスターに属していること
クラスターへの書き込みが可能であること
クラスターからクエリーの受信と書き込みが可能であること
クラスター内の他のノードに接続されていること
ローカルのデータベースで Write Set をテーブルにレプリケーションしていること

以下の項では、各ステータスを調べる方法について説明します。

6.1. データベースクラスターの整合性の調査
リンクのコピー

MariaDB Galera Cluster の問題を調査する際には、クラスター自体の整合性から開始してください。クラスターの整合性を検証するには、各コントローラーノード上の特定の wsrep_ データベース変数を確認する必要があります。データベースの変数を確認するには、次のコマンドを実行します。

sudo mysql -B -e "SHOW GLOBAL STATUS LIKE 'VARIABLE';"

$ sudo mysql -B -e "SHOW GLOBAL STATUS LIKE 'VARIABLE';"

Copy to Clipboard

Toggle word wrap

VARIABLE は確認する wsrep_ データベース変数に置き換えてください。たとえば、ノードの cluster state UUID を確認するには、以下のコマンドを実行します。

sudo mysql -B -e "SHOW GLOBAL STATUS LIKE '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 |
    +--------------------------+--------------------------------------+

Copy to Clipboard

Toggle word wrap

以下の表には、クラスターの整合性と関連するさまざまな wsrep_ データベース変数をまとめています。

Expand

表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';"

$ sudo mysql -B -e "SHOW GLOBAL STATUS LIKE 'VARIABLE';"

Copy to Clipboard

Toggle word wrap

同様に、VARIABLE は以下の値のいずれかに置き換えます。

Expand

表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';"

$ sudo mysql -B -e "SHOW STATUS LIKE 'VARIABLE';"

Copy to Clipboard

Toggle word wrap

同様に、VARIABLE は以下の値のいずれかに置き換えます。

Expand

表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 がすでに最適に設定されている場合には、接続の問題の可能性を調査するためにそのノードをクラスターから除外することを検討してください。

^[1] このメソッドは、IPv6 を使用するオーバークラウドで Galera が正常に起動できるようにするために実装されました (詳しくは、BZ#1298671 を参照してください)。

第6章 Galera の使用

6.1. データベースクラスターの整合性の調査
リンクのコピー

6.2. データベースクラスターノードの調査
リンクのコピー

6.3. データベースレプリケーションのパフォーマンスの調査
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第6章 Galera の使用

6.1. データベースクラスターの整合性の調査リンクのコピーリンクがクリップボードにコピーされました!

6.2. データベースクラスターノードの調査リンクのコピーリンクがクリップボードにコピーされました!

6.3. データベースレプリケーションのパフォーマンスの調査リンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

6.1. データベースクラスターの整合性の調査
リンクのコピー

6.2. データベースクラスターノードの調査
リンクのコピー

6.3. データベースレプリケーションのパフォーマンスの調査
リンクのコピー