Difference between revisions of "Pandora: Documentation ja: HA"
(→Pandora FMS コンソールの HA) |
(→インストール) |
||
| Line 445: | Line 445: | ||
さらに、Pandora FMS がインストールされているノードを '''pandorafms''' とします。 | さらに、Pandora FMS がインストールされているノードを '''pandorafms''' とします。 | ||
| + | |||
| + | '''all''' を参照した場合、それはデータベースノードのみです。追加の Pandora FMS ノードは常に '''pandorafms''' として参照され、 '''all''' の一部ではありません。 | ||
==== 前提条件 ==== | ==== 前提条件 ==== | ||
Revision as of 22:58, 13 November 2020
Contents
1 冗長化
1.1 概要
Pandora FMS はとても安定したアプリケーションになっています。(みなさんのテストのおかげで、それぞれのバージョンでは拡張が行われ、数百の不具合が報告され、修正されてきました。) しかし、クリティカルや高負荷な環境では、複数のサーバに処理を分散させることが可能です。Pandora FMS では、いずれかのコンポーネントで障害が発生しても、システム自体はダウンしません。Pandora FMS は、細かいモジュールで設計されています。それぞれのモジュールは、独立して動作することができます。しかし、それぞれはまた、連携して動作することができ、負荷を分配することができます。
Pandora FMS の基本設計を以下に示します。
もちろん、エージェントは冗長化構成ではありません。エージェントがダウンすると、モジュールの実行ができず、また、複数のエージェントを平行して実行することはできないため、またはシステム自体がダウンしているため、そのエージェントの全てのデータ収集はできなくなります。 重要なシステムに対する最良の解決策は、Pandora FMS エージェントのある無しに関わらず、冗長化しモニタリングすることです。
いくつかの場面において、次のような HA 構成が可能です。
- データサーバのバランシングと HA
- ネットワーク、WMI、プラグイン、Web および予測サーバのバランシングと HA
- データベースのロードバランシング
- 自動検出サーバのバランシングと HA
- Pandora FMS コンソールのバランシングと HA
1.2 HA のサイジングとアーキテクチャ設計
Pandora FMS における最も重要なコンポーネントは次の通りです。
- データベース
- サーバ
- コンソール
各コンポーネントは、あらゆる障害から監視システムを保護するために冗長構成を組むことができます。
負荷をバランシングするために必要なノード数を決定するためには、監視対象の数と監視間隔を知る必要があります。
監視のニーズによって、異なるアーキテクチャを決定します。
注意: アーキテクチャを決めるためのテストは、以下の複数の環境を使用して行っています。
Intel (R) Core (TM) i5-8600K CPU @ 3.60GHz
Amazon であれば、インスタンス t2.large [1]
1.2.1 サイジング
ニーズに依存します:
1. スタンドアローン(高可用性なし)で、最大 2500エージェント / 50000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースなし
サーバ数: 1 (共有) メイン: ---------- CPU: 6 cores RAM: 8 GB Disk: 100GB
2. スタンドアローン(高可用性なし)で、最大 2500エージェント / 50000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースあり
サーバ数: 2 (1 共有, 1 ヒストリ DB) メイン: ---------- CPU: 6 cores RAM: 8 GB Disk: 100GB ヒストリDB: ---------- CPU: 2 cores RAM: 4 GB Disk: 200GB
3. スタンドアローン(高可用性無し)で、最大 5000エージェント / 100000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースあり(1年保存)
サーバ台数: 3 (1 サーバ + コンソール, 1 メイン DB, 1 ヒストリ DB) サーバ + コンソール: ------------------- CPU: 6 cores RAM: 8 GB Disk: 40GB メイン DB: ------------------------ CPU: 4 cores RAM: 8 GB Disk: 100GB ヒストリ DB: ---------- CPU: 2 cores RAM: 4 GB Disk: 200GB
1.2.2 HA のアーキテクチャ設計
1. データベースがシンプルな HA 構成、最大 7500エージェント / 125000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースあり(1年保存)
サーバ数: 4 (1 サーバ + コンソール, 2 DB, 1 ヒストリ DB) サーバ + コンソール: ------------------- CPU: 6 cores RAM: 8 GB Disk: 40GB データベースノード 1: --------------------- CPU: 6 cores RAM: 8 GB Disk: 100GB データベースノード 2: --------------------- CPU: 6 cores RAM: 8 GB Disk: 100GB ヒストリ DB: ---------- CPU: 2 cores RAM: 4 GB Disk: 300GB
2. データベースが完全な HA 構成(3台構成)、最大 7500エージェント / 125000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースあり(1年保存)
サーバ数: 5 (1 サーバ + コンソール, 3 DB, 1 ヒストリ DB) サーバ + コンソール: ------------------ CPU: 6 cores RAM: 8 GB Disk: 40GB データベースノード 1: --------------------- CPU: 6 cores RAM: 8 GB Disk: 100GB データベースノード 2: --------------------- CPU: 6 cores RAM: 8 GB Disk: 100GB データベースノード 3: --------------------- CPU: 6 cores RAM: 8 GB Disk: 100GB ヒストリ DB: ---------- CPU: 2 cores RAM: 4 GB Disk: 200GB
3. データベースがシンプルな HA 構成、Pandora FMS が負荷分散 HA で、最大 7500エージェント / 125000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースあり(1年保存)
サーバ数: 5 (2 サーバ + コンソール, 2 DB, 1 ヒストリ DB) サーバ + コンソール ノード1: ------------------- CPU: 6 cores RAM: 8 GB Disk: 40GB サーバ + コンソール ノード2: ------------------- CPU: 6 cores RAM: 8 GB Disk: 40GB データベースノード 1: --------------------- CPU: 6 cores RAM: 8 GB Disk: 100GB データベースノード 2: --------------------- CPU: 6 cores RAM: 8 GB Disk: 100GB ヒストリ DB: ---------- CPU: 2 cores RAM: 4 GB Disk: 200GB
4. サーバが基本的な負荷分散 HA、マスター・スレーブのデータベース、最大 4000エージェント / 90000 モジュール、監視間隔 5分、一様なデータ、ヒストリデータベースあり(1年保存)
サーバ数: 3 (2 共有, 1 ヒストリ DB) メイン: (コンソール + サーバ + データベース ノード 1) ---------- CPU: 8 cores RAM: 12 GB Disk: 100GB セカンダリ: (コンソール + サーバ + データベース ノード 2) ---------- CPU: 8 cores RAM: 12 GB Disk: 100GB ヒストリ DB: ---------- CPU: 2 cores RAM: 4 GB Disk: 200GB
このスキーマでは、Pandroa FMS データベースのノードは、2台それぞれのサーバで(マスター・スレーブ構成で)設定します。
注意: 大規模環境では、前述の構成スキームを1つのセットとして定義します。
1.2.3 例
30,000 エージェント、500,000 モジュールを監視する必要がある場合、要求を満たすために必要な数のノードを設定する必要があります。以下に例を示します。
HA #1 の設計を選択した場合(1 サーバ + コンソール, 2 HA構成のデータベースノード, ヒストリ DB)、30,000 / 7500 = 4 つのセットを設定します。
全体の環境を管理するには、全体を一元管理できるメタコンソールのインストールが必要です。
メタコンソールに必要なリソースは以下の通りです。
サーバ数: 1 (共有) メイン: ---------- CPU: 8 cores RAM: 12 GB Disk: 100GB
ヒストリ DB を個別に用意した場合のサーバトータル数: 17
ヒストリ DB を集約した場合のサーバトータル数: 13
注意 : 全ヒストリ DB (4台) を一つのサーバに集約するには、負荷を考慮してサイズを変更する必要があります。
集約したヒストリ DB: -------------------- CPU: 8 cores RAM: 12 GB Disk: 1200GB
1.3 データサーバの HA
最も簡単な方法は、エージェントに実装されている HA を使用することです(プライマリが応答しない場合は代替サーバーに接続できます)。 ただし、データサーバはポート 41121 をサポートし、標準の TCP ポートであるため、通常の TCP サービスのバランシングまたはクラスタリングを可能にする商用ソリューションを使用することができます。
Pandora FMS データサーバでは、(異なるホスト名およびサーバ名で)設定された 2つの Pandora FMS データサーバを利用する必要があります。それぞれに tentacle サーバーを設定する必要があります。 各マシンは異なる IP アドレスを持ちます。 外部バランサを使用する場合、バランサにエージェントからのデータ送信用の接続 IP アドレス(VIP)を割り当てます。
外部バランサを使用していて、いずれかのサーバが故障した場合、アクティブなサーバにのみ接続するようになります。Pandora FMS エージェントは変更に気付くことなく、これまでと同様のアドレスへ接続します。しかし、この場合は、ロードバランサーは障害が発生したサーバにはデータを送信せず、アクティブな方にのみ送信します。Pandora FMS データサーバの設定を変更する必要はありません。それぞれのサーバに別々の名前を設定してさえいえれば、サーバの状態ビューでいずれかがダウンしていることがわかり便利です。Pandora FMS データモジュールは、いずれかのサーバで処理することができます。事前のサーバ指定は不要です。簡単に HA 構成がとれるように設計されています。
エージェントの HA メカニズムを使用する場合は、データの送信にわずかな遅延があります。これは、エージェントの実行ごとにプライマリサーバとの接続を試みるためです。応答しない場合 セカンダリに対してこれを行います(設定されている場合)。これについては、次の "ソフトウエアエージェントでのバランシング" で説明します。
2つのデータサーバーを使用し、ポリシー、コレクション、およびリモート構成を管理する場合は、 サーバデータディレクトリの複数 Pandora サーバでの共有 に従って次のディレクトリを共有する必要があります。データサーバのすべてのインスタンスでこれらのディレクトリを読み書きします。 また、コンソールもこれらの共有ディレクトリにアクセスできる必要があります。
- /var/spool/pandora/data_in/conf
- /var/spool/pandora/data_in/collections
- /var/spool/pandora/data_in/md5
- /var/spool/pandora/data_in/netflow
- /var/www/html/pandora_console/attachment
1.4 ソフトウエアエージェントでのバランシング
ソフトウエアエージェントで、データサーバのバランシングを行うことができます。データサーバの一方をマスター、もう一方をバックアップとして設定することができます。
エージェントの設定ファイル pandora_agent.conf において、次の部分のコメントを外します。
# Secondary server configuration # ============================== # If secondary_mode is set to on_error, data files are copied to the secondary # server only if the primary server fails. If set to always, data files are # always copied to the secondary server secondary_mode on_error secondary_server_ip localhost secondary_server_path /var/spool/pandora/data_in secondary_server_port 41121 secondary_transfer_mode tentacle secondary_server_pwd mypassword secondary_server_ssl no secondary_server_opts
次に示すオプションがあります。(詳細は、エージェント設定の章を参照してください。)
- secondary_mode: セカンダリサーバのモードを設定します。次のいずれかが設定できます。
- on_error: メインサーバにデータを送信できなかった場合のみセカンダリサーバにデータ送信します。
- always: メインサーバに接続できるできないに関わらず、常にセカンダリサーバにもデータを送信します。
- secondary_server_ip: セカンダリサーバの IP アドレスを指定します。
- secondary_server_path: セカンダリサーバの XML ファイルを置く場所を指定します。通常は、/var/spool/pandora/data_in です。
- secondary_server_port: セカンダリサーバに XML ファイルを置くためのポート番号を指定します。tentacle では 41121、ssh は 22、ftp は 21 です。
- secondary_transfer_mode: セカンダリサーバに XML を送信するモード (tentacle, ssh, ftp など) を設定します。
- secondary_server_pwd: FTP で送信するためのパスワードを設定します。
- secondary_server_ssl: Tentacle その他でデータを送信するときに、ssl を使うかどうかを yes または no で指定します。
- secondary_server_opts: 転送に必要なその他オプションを設定します。
|
|
エージェントのリモート設定が有効になっている場合、メインサーバでのみ操作できます。 |
|
1.5 ネットワーク、WMI、プラグイン、ウェブ、予測サーバのバランシングと HA
これは簡単です。複数のサーバに、ネットワーク、WMI、プラグイン、ウェブ、予測サーバを (モニタしたいシステムを見れるよう同じように) それぞれインストールします。複数のサーバは (ネットワーク遅延が同じになるように) 同一セグメントに置く必要があります。
それぞれのサーバはプライマリとして選択できます。それぞれのサーバは、他方がダウンした場合、そのサーバに割り当てられていた全てのモジュールデータの収集を自動的に引き継ぎます。Pandora FMS サーバには、最終接続時間 (サーバの threshold x 2) を確認して、他のサーバがダウンしていることを検知する仕組が実装されています。Pandora FMS サーバが 1台でも稼働していれば、他のサーバのダウンを検出することができます。すべての Pandora FMS サーバがダウンした場合は、検出する手段はありません。
2つのノードのシステムで HA およびロードバランシングを実装する簡単な方法は、それぞれのサーバに 50% ずつモジュールを割り当て、両方のサーバをマスターとして選択します。2つ以上のマスターサーバがあり、3台目がダウンした場合は、1台目のマスターサーバがダウンしたサーバに割り当てられていたモジュールの実行を自分自身に割り当てます。ダウンしたサーバが復旧した場合は、再度モジュールの実行が自動的にプライマリサーバに割り当てられます。
異なるサーバ間でのロードバランシングは、エージェント管理(Agent Administration) の設定メニューで実施します。
"サーバ(server)" フィールドにて、監視を実行するサーバを選択することができます。
1.5.1 サーバの設定
Pandora FMS サーバは、異なる 2つのモードで実行できます。
- マスターモード
- 非マスターモード
もしサーバがダウンすると、処理が止まらないように、そのサーバが持っていたモジュールはマスターサーバで実行されます。
/etc/pandora/pandora_server.conf で master の設定が 0 より大きい値になっているすべてのサーバから、一つのマスターサーバが選択されます。
master [1..7]
もし現在のマスターサーバがダウンすると、新たなマスターサーバが選択されます。複数の候補がある場合は、master の値が最も高いものが選択されます。
|
|
サーバの無効化には注意してください。ネットワークモジュールを持つサーバがダウンした場合、他のマスターサーバでネットワークサーバが無効化されていると、モジュールは実行されません。 |
|
例えば、master を 1 に設定した 3台の Pandora FMS サーバがある場合、マスターサーバはランダムに選択され、他の 2台は非マスターモードで動作します。マスターサーバがダウンすると、新たなマスターがランダムに選択されます。
pandora_server.conf に以下のパラメータを設定できます。
- ha_file: HA のテンポラリバイナリファイルの場所
- ha_pid_file: HA の現在のプロセス ID ファイル
- pandora_service_cmd: Pandora サービスの状態制御
1.6 Pandora FMS コンソールの HA
他のサーバにコンソールをインストールするだけです。それらのいずれからも、異なるユーザによって異なる場所から同時に使用することができます。 コンソールの前段でロードバランサを使用すると、セッションシステムが「クッキー」によって管理され、これがブラウザーに保管されるため、どちらがアクセスされているかを実際に知らなくてもアクセスできます。
リモート設定を使用する場合、双方のデータサーバとコンソールは、データ入力ディレクトリ(/var/spool/pandora/data_in)配下の configuration、collections その他を共有する必要があります。
|
|
こちらのガイドで、必要なフォルダを NFS または GlusterFS で共有する方法を確認できます。 |
|
サーバのパフォーマンスに影響するため、data_in 以下のサブディレクトリのみ共有し、data_in 自体は共有しないことが重要です。
1.6.1 更新
HA 環境で Pandora FMS コンソールを更新する際に、アップデートマネージャ [2] を介して OUM を使用して更新する場合は、次の点に考慮することが必要です。
Enterprise 版のユーザは、Pandora FMS サポートサイトから OUM パッケージをダウンロードできます。
共有データベースを使用するバランシング環境では、最初のコンソールを更新すると、対応する変更がデータベースに適用されます。 これは、セカンダリのコンソールを更新しようとすると、データベースがすでに更新されているため、Pandora FMS がエラーメッセージを表示することになります。 ただし、コンソールの更新は引き続き実行されます。
1.7 データベース HA
|
|
これは、Pandora FMS 環境において完全な HA を提供するソリューションです。これは、Pandora FMS で唯一公式にサポートされた HA モデルです。このソリューションは OUM 724 からあらかじめインストールされた状態で提供されています。このシステムは、以前お勧めしていた DRBD およびその他 HA システムを置き換えるものです。 |
|
|
|
これは、最初の Pandora DB HA の実装であり、導入処理は Linux コンソールで root を使うことによる、ほぼ手動です。将来のバージョンでは、GUI から簡単に設定できるようにする予定です。 |
|
Pandora FMS は、設定とデータの保存のために MySQL データベースに依存しています。データベースの障害は、一時的に監視処理が停止することになります。Pandora FMS の高可用性データベースクラスタにより、冗長化、堅牢なアーキテクチャを実現します。
クラスタリソースは、高度でスケーラブルな HA クラスタリソースマネージャである Pacemaker によって管理されます。Corosync は、複製された状態のマシンを作成するためのクローズドプロセスグループ通信モデルを提供します。スケーラビリティ、可用性、セキュリティおよびバックアップ機能のため、デフォルトの RDBMS としては Percona を選択しました。
アクティブ/スタンバイ レプリケーション では、一つのマスターノード(書き込み可)から、複数のスレーブ(読み出し専用)に同期します。仮想 IP アドレスは、常にマスターを示します。マスターノードが障害の場合は、スレーブのうちの 1つがマスターに昇格し、関連して仮想 IP が変更されます。
Pandora FMS データベース HA ツール pandora_ha は、クラスタを監視し、Pandora FMS サーバが常に動作していることを確認します。必要な場合はそれを再起動します。pandora_ha 自身は systemd によって監視されます。
|
|
これは、Linux システムの知識が必要な高度な機能です。 |
|
1.7.1 インストール
node1 および node2 の 2つのノードのクラスタを設定します。環境に合わせて、ホスト名、パスワードなどを変更します。
一方のノードで実行するコマンドにについては、ノードのホスト名を前に表示します。例:
node1# <command>
すべてのノードで実行するコマンドについては、all を前に表示します。例:
all# <command>
さらに、Pandora FMS がインストールされているノードを pandorafms とします。
all を参照した場合、それはデータベースノードのみです。追加の Pandora FMS ノードは常に pandorafms として参照され、 all の一部ではありません。
1.7.1.1 前提条件
CentOS バージョン 7 がすべてのノードにインストールされており、それぞれのホスト名の名前解決ができる必要があります。
node1# ping node2 PING node2 (192.168.0.2) 56(84) bytes of data. node2# ping node1 PING node1 (192.168.0.1) 56(84) bytes of data. pandorafms# ping node1 PING node1 (192.168.0.1) 56(84) bytes of data. pandorafms# ping node2 PING node2 (192.168.0.2) 56(84) bytes of data.
OpenSSH サーバがインストールされており、各ホストで実行されている必要があります。OpenSSH が表示するバナーを削除します。
all# [ -f /etc/cron.hourly/motd_rebuild ] && rm -f /etc/cron.hourly/motd_rebuild all# sed -i -e 's/^Banner.*//g' /etc/ssh/sshd_config all# systemctl restart sshd
|
|
Pandora FMS データベース HA ツールは、OpenSSH のバナーを調整していないと正しく動作しません。 |
|
それぞれのホストで SSH 認証鍵を生成し、公開鍵を他のホストへコピーします。
|
|
root 以外のユーザを使用した設定を行う場合は、root 以外のユーザで鍵を生成します。 |
|
node1# echo -e "\n\n\n" | ssh-keygen -t rsa node1# ssh-copy-id -p22 [email protected] node1# ssh node2 node2# echo -e "\n\n\n" | ssh-keygen -t rsa node2# ssh-copy-id -p22 [email protected] node2# ssh node1 pandorafms# echo -e "\n\n\n" | ssh-keygen -t rsa pandorafms# ssh-copy-id -p22 [email protected] pandorafms# ssh-copy-id -p22 [email protected] pandorafms# ssh node1 pandorafms# ssh node2
Pandora FMS ノードで、鍵のペアを /usr/share/httpd/.ssh/ へコピーします。Pandora FMS コンソールが、クラスタの状態を取得するために必要です。
pandorafms# cp -r /root/.ssh/ /usr/share/httpd/ pandorafms# chown -R apache:apache /usr/share/httpd/.ssh/
SSH が標準以外のポートで動作しているノードでは、以下のステップが必要です。22 を正しいポート番号に置き換えます。
all# echo -e "Host node1\n Port 22" >> /root/.ssh/config all# echo -e "Host node2\n Port 22" >> /root/.ssh/config
1.7.1.2 Percona のインストール
必要なパッケージをインストールします。
all# yum install -y http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm all# yum install -y Percona-Server-server-57 percona-xtrabackup-24
Percona サービスが無効化されていることを確認します。これは、クラスタによって管理されます。
all# systemctl disable mysqld
|
|
システムのサービスが無効化されていないと、クラスタのリソースマネージャが正しく動作しません。 |
|
MySQL 設定を実行するときに、デフォルトの Pandora FMS ISO で -ha をつけてインストールされている場合は、Pandora FMS Enteprise サーバのインストールパッケージに既に含まれている以下の自動生成を介してそれを行うことができます。
|
|
ISO を使用せずにサーバパッケージを手動でインストールした場合、HA サーバツールにアクセスするには、 -ha パラメーターを渡す必要があることに注意してください。 |
|
そのようにしていない場合は、サーバパッケージを --ha パラメータ付きで再インストールします。
./pandora_server_installer --install --ha
HA ツールを有効化してサーバをインストールしたら、データベースレプリケーションの設定ジェネレータを /usr/share/pandora_server/util/mycnf_gen.sh に見つけることができます。
例: ./mycnf_gen.sh -i serverid [-l file_location] [-d database] [-b binlog] [-u dbuser] [-p dbpass] [-s poolsize] [-h help]
Mandatory parameters:
-i --serverid Set the server id for the database (Mandatory)
Optional parameters:
-l --location Set my.cnf custom location including filename. [ default value: /etc/my.cnf ] (optional)
-d --database Set the database to be replicated. [ default value: pandora ] (optional)
-b --binlog Set binlog file. [ default value: mysql-bin ] (optional)
-u --dbuser Set dbuser for mysql connection and backups. [ default value: root ] (optional)
-p --dbpass Set dbpassword for mysql connection and backups. [ default value: pandora ] (optional)
-s --poolsize Set innodb_buffer_pool_size static size in M (Megabytes) or G (Gigabytes). [ default value: autocalculated ] (optional)
-h --help Print help.
例でわかるように、標準環境でパラメーター serverid(必須)を渡すか、ISO インストールの場合はカスタム環境用のいくつかのオプションパラメータを展開するだけで済みます。
デフォルトのユーザまたは定義されたユーザがデータベースに接続できない場合、スクリプトは接続エラーとなります。
データベース、ユーザ、パスワードを引数として渡すこともできます。それ以外の場合は、デフォルト設定が使用されます。
次に、Percona サーバを起動します。
all# systemctl start mysqld
新規のテンポラリパスワードが生成され、/var/log/mysqld.log に記録されます。Percona サーバへ接続し、root のパスワードを変更します。
all# mysql -uroot -p$(grep "temporary password" /var/log/mysqld.log | \
rev | cut -d' ' -f1 | rev)
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('Pandor4!');
mysql> UNINSTALL PLUGIN validate_password;
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora');
mysql> quit
1.7.1.3 Pandora FMS のインストール
1.7.1.3.1 新規の Pandora FMS インストール
新規で作成するデータベースに Pandora FMS をインストールします。詳細は以下を参照yしてください。
https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_ja:Installing
Pandora FMS サーバを停止します。
pandorafms# /etc/init.d/pandora_server stop
1.7.1.3.2 既存の Pandora FMS へのインストール
Pandora FMS サーバを停止します。
pandorafms# /etc/init.d/pandora_server stop
Pandora FMS データベースをバックアップします。
pandorafms# mysqldump -uroot -ppandora --databases pandora > /tmp/pandoradb.sql pandorafms# scp /tmp/pandoradb.sql node1:/tmp/
バックアップを新しいデータベースにリストアします。
node1# mysql -uroot -ppandora < /tmp/pandoradb.sql
1.7.1.4 レプリケーション設定
全データベースでレプリケーションが動作するのに必要な権限を設定します。
all# mysql -uroot -ppandora mysql> GRANT ALL ON pandora.* TO 'root'@'%' IDENTIFIED BY 'pandora'; mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'root'@'%' IDENTIFIED BY 'pandora'; mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE, SUPER, PROCESS, RELOAD ON *.* TO 'root'@'localhost' IDENTIFIED BY 'pandora'; mysql> GRANT select ON mysql.user TO 'root'@'%' IDENTIFIED BY 'pandora'; mysql> FLUSH PRIVILEGES; mysql> quit
1つ目のノードのデータベースをバックアップし、マスターログファイル名とポジションを記録します。(以下の例では、それぞれ mysql-bin.000001 と 785 です)
node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak node1# innobackupex --no-timestamp /root/pandoradb.bak/ node1# innobackupex --apply-log /root/pandoradb.bak/ node1# cat /root/pandoradb.bak/xtrabackup_binlog_info mysql-bin.000001 785
2つ目のノードにデータベースをコピーし、1つ目のノードからレプリケーションをする設定をします。(上記のステップで記録しておいた MASTER_LOG_FILE と MASTER_LOG_POS を指定します。)
|
|
Pandora FMS のインストールを ISO イメージを利用して行った場合、ノード2 から元のデータベースを削除します。両方のマシンからの情報を保存するノード1 のデータベースのみが必要です。そうすることにより、バランシングが正しく行われます。 |
|
node2# systemctl stop mysqld
node1# rsync -avpP -e ssh /root/pandoradb.bak/ node2:/var/lib/mysql/
node2# chown -R mysql:mysql /var/lib/mysql
node2# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql
node2# systemctl start mysqld
node2# mysql -uroot -ppandora
mysql> CHANGE MASTER TO MASTER_HOST='node1',
MASTER_USER='root', MASTER_PASSWORD='pandora',
MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=785;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: node1
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 785
Relay_Log_File: node2-relay-bin.000003
Relay_Log_Pos: 998
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: pandora
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 785
Relay_Log_Space: 1252
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 580d8bb0-6991-11e8-9a22-16efadb2f150
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
mysql> QUIT
all# systemctl stop mysqld
|
|
Slave_IO_Running と Slave_SQL_Running が Yes であることを確認します。その他の値は例とは異なります。 |
|
|
|
この処理を実行するのに root を 利用しない ようにしてください。競合の可能性を回避するために、データベースの管理を担当するユーザにアクセス権限を付与することをお勧めします。 |
|
1.7.1.5 2ノードクラスタの設定
必要なパッケージをインストールします。
all# yum install -y epel-release corosync ntp pacemaker pcs all# systemctl enable ntpd all# systemctl enable corosync all# systemctl enable pcsd all# cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf all# systemctl start ntpd all# systemctl start corosync all# systemctl start pcsd
Percona サーバを停止します。
node1# systemctl stop mysqld
node2# systemctl stop mysqld
クラスタ内の全ノードを認証します。
クラスタを作成し、開始します。
all# echo hapass | passwd hacluster --stdin all# cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf node1# pcs cluster auth -u hacluster -p hapass --force node1 node2 node1# pcs cluster setup --force --name pandoraha node1 node2 node1# pcs cluster start --all node1# pcs cluster enable --all node1# pcs property set stonith-enabled=false node1# pcs property set no-quorum-policy=ignore
クラスタの状態を確認します。
node#1 pcs status
Cluster name: pandoraha
Stack: corosync
Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Fri Jun 8 12:53:49 2018
Last change: Fri Jun 8 12:53:47 2018 by root via cibadmin on node1
2 nodes configured
0 resources configured
Online: [ node1 node2 ]
No resources
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
|
|
両方のノードがオンライン (Online: [ node1 node2 ]) である必要があります。その他の値は例とは異なります。 |
|
Percona pacemake replication agent をインストールします。(我々の ライブラリ からダウンロードできます)
all# cd /usr/lib/ocf/resource.d/ all# mkdir percona all# cd percona all# curl -L -o pacemaker_mysql_replication.zip https://pandorafms.com/library/wp-content/uploads/2019/12/pacemaker_mysql_replication.zip all# unzip pacemaker_mysql_replication.zip all# rm -f pacemaker_mysql_replication.zip all# chmod u+x mysql
クラスタリソースを設定します。<VIRT_IP> をあらかじめ決めておいた仮想 IP アドレスに置き換えます。
|
|
データベースの root ユーザのデフォルトパスワードを変更している場合は、関連して replication_passwd および test_passwd を更新してください。 |
|
|
|
クラスタのリソース名は、このガイドで示されているものと正確に一致する必要があります ("pandoraip" および "pandoradb") |
|
node1# export VIP=<VIRT_IP> node1# pcs resource create pandoradb ocf:percona:mysql config="/etc/my.cnf" \ pid="/var/run/mysqld/mysqld.pid" socket="/var/lib/mysql/mysql.sock" \ replication_user="root" replication_passwd="pandora" max_slave_lag="60" \ evict_outdated_slaves="false" binary="/usr/sbin/mysqld" datadir="/var/lib/mysql" \ test_user="root" test_passwd="pandora" op start interval="0" timeout="60s" \ op stop interval="0" timeout="60s" op promote timeout="120" op demote timeout="120" \ op monitor role="Master" timeout="30" interval="5" on-fail="restart" op monitor role="Slave" \ timeout="30" interval="10" node1# pcs resource create pandoraip ocf:heartbeat:IPaddr2 ip=$VIP cidr_netmask=24\ op monitor interval=20s node1# pcs resource master master_pandoradb pandoradb meta master-max="1" \ master-node-max="1" clone-max="2" clone-node-max="1" notify="true" \ globally-unique="false" target-role="Master" is-managed="true" node1# pcs constraint colocation add master master_pandoradb with pandoraip node1# pcs constraint order promote master_pandoradb then start pandoraip
クラスタの状態を確認します。
node1# pcs status
Cluster name: pandoraha
Stack: corosync
Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Fri Jun 8 13:02:21 2018
Last change: Fri Jun 8 13:02:11 2018 by root via cibadmin on node1
2 nodes configured
3 resources configured
Online: [ node1 node2 ]
Full list of resources:
Master/Slave Set: master_pandoradb [pandoradb]
Masters: [ node1 ]
Slaves: [ node2 ]
pandoraip (ocf::heartbeat:IPaddr2): Started node1
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
|
|
両方のノードがオンライン (Online: [ node1 node2 ]) である必要があります。その他の値は例とは異なります。 |
|
1.7.1.6 root 以外のユーザでの 2ノードクラスタの設定
前述の内容と同じように実施します。すでに説明しているように、ログイン情報はコピーされている必要があり、以下のステップを実行する必要があります。
# 全ノード:
useradd <usuario> passwd <usuario> usermod -a -G haclient <usuario>
# PCS ACL システムの有効化 pcs property set enable-acl=true --force
# ロールの作成 pcs acl role create <rol> description="RW role" write xpath /cib
# PCS ユーザの作成 - ローカルユーザ pcs acl user create <usuario> <rol>
# 全ノードから PCS へログイン su - <usuario> pcs status Username: <usuario> Password: *****
# 'Authorized' メッセージを待ち出力は無視します。数秒待ったのち、'pcs status' コマンドを実行します。
1.7.1.7 Pandora FMS の設定
php-pecl-ssh2 がインストールされていることを確認します。
pandorafms# yum install php-pecl-ssh2 pandorafms# systemctl restart httpd
Pandora FMS データベース HA ツールの動作を制御する 2つのパラメータが /etc/pandora/pandora_server.conf にあります。これらを好みに応じて調整します。
# Pandora FMS Database HA Tool execution interval in seconds (PANDORA FMS ENTERPRISE ONLY).
ha_interval 30
# Pandora FMS Database HA Tool monitoring interval in seconds. Must be a multiple of ha_interval (PANDORA FMS ENTERPRISE ONLY).
ha_monitoring_interval 60
Pandora FMS の DB 参照先をマスターの仮想 IP アドレスにします。(<IP> を仮想 IP アドレスに置き換えます。)
pandorafms# export VIRT_IP=<IP> pandorafms# sed -i -e "s/^dbhost .*/dbhost $VIRT_IP/" \ /etc/pandora/pandora_server.conf pandorafms# sed -i -e "s/\$config\[\"dbhost\"\]=\".*\";/\$config[\"dbhost\"]=\"$VIRT_IP\";/" \ /var/www/html/pandora_console/include/config.php
pandora_ha サービスをインストールし、開始します。
pandorafms# cat > /etc/systemd/system/pandora_ha.service <<-EOF [Unit] Description=Pandora FMS Database HA Tool [Service] Type=forking PIDFile=/var/run/pandora_ha.pid Restart=always ExecStart=/usr/bin/pandora_ha -d -p /var/run/pandora_ha.pid /etc/pandora/pandora_server.conf [Install] WantedBy=multi-user.target EOF pandorafms# systemctl enable pandora_ha pandorafms# systemctl start pandora_ha
Pandora FMS コンソールへログインし、サーバ(Servers) -> データベース HA 管理(Manage database HA) へ行きます。
新規ノード追加(Add new node) をクリックし、1つ目のノードのエントリを作成します。
次に、スレーブの作成(Create slave) をクリックし、2つ目のノードのエントリを追加します。次のような画面が表示されます。
|
|
functions_HA_cluster.php ファイルに $ssh_user の正しいパスが含まれているかどうかを確認する必要があります。 |
|
|
|
Seconds behind master は 0 に近い必要があります。増加を続けている場合は、レプリケーションが動作していません。 |
|
1.7.2 クラスタへの新規ノードの追加
OpenSSH で表示されるバナーを削除します。
node3# [ -f /etc/cron.hourly/motd_rebuild ] && rm -f /etc/cron.hourly/motd_rebuild node3# sed -i -e 's/^Banner.*//g' /etc/ssh/sshd_config node3# systemctl restart sshd
新しいホスト用の新しい SSH 認証キーを生成し、公開キーを他の各ホストにコピーします。
|
|
非 root ユーザを使用したクラスターインストールでは、非 root ユーザのキーを生成します。 |
|
node1# ssh-copy-id -p22 [email protected] node1# ssh node3
node2# ssh-copy-id -p22 [email protected] node2# ssh node3
pandorafms# ssh-copy-id -p22 [email protected] pandorafms# ssh node3
node3# echo -e "\n\n\n" | ssh-keygen -t rsa node3# ssh-copy-id -p22 [email protected] node3# ssh-copy-id -p22 [email protected] node3# ssh node1 node3# ssh node2
Pandora FMS ノードで、apache ユーザに "know_hosts" ファイルをコピーします。
pandorafms# yes | cp /root/.ssh/known_hosts /usr/share/httpd/.ssh/
次の手順は、ノードが非標準ポートで SSH を実行している場合にのみ必要です。 22 を正しいポート番号に置き換えます。
all# echo -e "Host node1\n Port 22" >> /root/.ssh/config all# echo -e "Host node2\n Port 22" >> /root/.ssh/config all# echo -e "Host node3\n Port 22" >> /root/.ssh/config
必要なパッケージをインストールします。
node3# yum install -y http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm node3# yum install -y Percona-Server-server-57 percona-xtrabackup-24
Percona サービスはクラスタによって管理されるため、無効にしてください。
node3# systemctl stop mysqld node3# systemctl disable mysqld
|
|
システムサービスが無効になっていない場合、クラスタのリソースマネージャーは正常に動作しません。 |
|
Percona を設定し、<ID> を各クラスタノード専用の番号に置き換えます。
|
|
2つのノードが同じ SERVER_ID を持っていると、レプリケーションが正しく動作しません。 |
|
node3# export SERVER_ID=<ID>
node3# export POOL_SIZE=$(grep -i total /proc/meminfo | head -1 | \
awk '{print $(NF-1)*0.4/1024}' | sed s/\\..*$/M/g)
node3# cat <<EOF > /etc/my.cnf
[mysqld]
server_id=$SERVER_ID
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
log-error=/var/log/mysqld.log
show_compatibility_56=on
max_allowed_packet = 64M
# Recommendation: not to assign a value greater than 35% of available RAM memory
innodb_buffer_pool_size = $POOL_SIZE
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
thread_cache_size = 8
max_connections = 200
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
log-bin=mysql-bin
query_cache_type = 1
query_cache_size = 32M
query_cache_limit = 8M
sql_mode=""
expire_logs_days=3
binlog-format=ROW
log-slave-updates=true
sync-master-info=1
sync_binlog=1
max_binlog_size = 100M
replicate-do-db=pandora
port=3306
report-port=3306
report-host=master
gtid-mode=off
enforce-gtid-consistency=off
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync_relay_log = 10
sync_relay_log_info = 10
slave_compressed_protocol = 1
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 10
innodb_flush_log_at_trx_commit = 2
innodb_flush_log_at_timeout = 1800
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[client]
user=root
password=pandora
EOF
Percona サーバを起動します。
node3# systemctl start mysqld
新しい一時パスワードが生成され、/var/log/mysqld.log に書かれます。 Percona サーバにログインして、root パスワードを変更します。
node3# mysql -uroot -p$(grep "temporary password" /var/log/mysqld.log | \
rev | cut -d' ' -f1 | rev)
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('Pandor4!');
mysql> UNINSTALL PLUGIN validate_password;
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora');
mysql> quit
最初のノードのデータベースをバックアップし、マスターログファイルの名前と位置(この例では mysql-bin.000001 および 785)を書き留めます。
node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak node1# innobackupex --no-timestamp /root/pandoradb.bak/ node1# innobackupex --apply-log /root/pandoradb.bak/ node1# cat /root/pandoradb.bak/xtrabackup_binlog_info mysql-bin.000001 785
2つ目のノードにデータベースをコピーし、最初のノードから複製するように構成します(MASTER_LOG_FILE およびMASTER_LOG_POS を前の手順で見つかった値に設定します)。
node3# systemctl stop mysqld
node1# rsync -avpP -e ssh /root/pandoradb.bak/ node3:/var/lib/mysql/
node3# chown -R mysql:mysql /var/lib/mysql
node3# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql
node3# systemctl start mysqld
node3# mysql -uroot -ppandora
mysql> CHANGE MASTER TO MASTER_HOST='node1',
MASTER_USER='root', MASTER_PASSWORD='pandora',
MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=785;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: node1
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 785
Relay_Log_File: node3-relay-bin.000003
Relay_Log_Pos: 998
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: pandora
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 785
Relay_Log_Space: 1252
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 580d8bb0-6991-11e8-9a22-16efadb2f150
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
mysql> QUIT
node3# systemctl stop mysqld
|
|
Slave_IO_Running および Slave_SQL_Running が Yes と表示される必要があります。他の値は例と異なる場合があります。 |
|
必要なパッケージをインストールします。
node3# yum install -y epel-release corosync ntp pacemaker pcs node3# systemctl enable ntpd node3# systemctl enable corosync node3# systemctl enable pcsd node3# systemctl start ntpd
新たなノードをクラスタに追加します。
node3# echo -n hapass | passwd hacluster --stdin node3# cd /usr/lib/ocf/resource.d/ node3# mkdir percona node3# cd percona node3# curl -L -o pacemaker_mysql_replication.zip https://pandorafms.com/library/wp-content/uploads/2019/12/pacemaker_mysql_replication.zip node3# unzip pacemaker_mysql_replication.zip node3# rm -f pacemaker_mysql_replication.zip node3# chmod u+x mysql
node1# pcs cluster auth -u hacluster -p hapass --force node3 node1# pcs cluster node add --enable --start node3
clone-max をクラスタ内のノード数(この例では 3)に設定します。
node3# pcs resource update master_pandoradb meta master-max="1" \ master-node-max="1" clone-max="3" clone-node-max="1" notify="true" \ globally-unique="false" target-role="Master" is-managed="true"
ノードの状態を確認します。
node3# pcs status
Cluster name: pandoraha
Stack: corosync
Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Fri Jun 1 10:55:47 2018
Last change: Fri Jun 1 10:55:09 2018 by root via crm_attribute on node3
3 nodes configured
3 resources configured
Online: [ node1 node2 node3 ]
Full list of resources:
pandoraip (ocf::heartbeat:IPaddr2): Started node1
Master/Slave Set: master_pandoradb [pandoradb]
Masters: [ node1 ]
Slaves: [ node2 node3 ]
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
|
|
すべてのノードがオンラインである必要があります(Online: [ node1 node2 node3 ])。 他の値は例と異なる場合があります。 |
|
"サーバ(Servers -> データベース HA 管理(Manage database HA)" メニューから Pandora コンソールにクラスタノードを登録します。
1.7.3 障害ノードの修正
例として node2 を用います。node2 をスタンバイモードにします。
node2# pcs node standby node2
node2# pcs status
Cluster name: pandoraha
Stack: corosync
Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Tue Jun 12 08:20:49 2018
Last change: Tue Jun 12 08:20:34 2018 by root via cibadmin on node2
2 nodes configured
3 resources configured
Node node2: standby
Online: [ node1 ]
Full list of resources:
Master/Slave Set: master_pandoradb [pandoradb]
Masters: [ node1 ]
Stopped: [ node2 ]
pandoraip (ocf::heartbeat:IPaddr2): Started node1
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
|
|
node2 がスタンバイ(Node node2: standby)である必要があります。他の値は例とは異なります。 |
|
Percona のデータディレクトリをバックアップします。
node2# systemctl stop mysqld node2# [ -e /var/lib/mysql.bak ] && rm -rf /var/lib/mysql.bak node2# mv /var/lib/mysql /var/lib/mysql.bak
マスターノード(この例では node1 です)のデータベースをバックアップし、マスターのログファイル名とポジションを記録します(この例では mysql-bin.000001 および 785 です)。
node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak
node1# innobackupex --no-timestamp /root/pandoradb.bak/
node1# innobackupex --apply-log /root/pandoradb.bak/
node1# binlog_info=$(cat /root/pandoradb.bak/xtrabackup_binlog_info)
node1# crm_attribute --type crm_config --name pandoradb_REPL_INFO -s mysql_replication \
-v "node1|$(echo $binlog_info | awk '{print $1}')|$(echo $binlog_info | awk '{print $2}')"
障害が発生したノードへデータベースをコピーします。
node1# rsync -avpP -e ssh /root/pandoradb.bak/ node2:/var/lib/mysql/ node2# chown -R mysql:mysql /var/lib/mysql node2# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql
node2 のスタンバイモードを無効化します。
node2# pcs node unstandby node2 node2# pcs resource cleanup --node node2
クラスタの状態を確認します。
node2# pcs status
Cluster name: pandoraha
Stack: corosync
Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Fri Jun 1 10:55:47 2018
Last change: Fri Jun 1 10:55:09 2018 by root via crm_attribute on node3
2 nodes configured
3 resources configured
Online: [ node1 node2 ]
Full list of resources:
pandoraip (ocf::heartbeat:IPaddr2): Started node1
Master/Slave Set: master_pandoradb [pandoradb]
Masters: [ node1 ]
Slaves: [ node2 ]
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
|
|
双方のノードがオンライン(Online: [ node1 node2 ])である必要があります。他の値は例とは異なります。 |
|
データベースのレプリケーション状態を確認します。
node2# mysql -uroot -ppandora
mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: node1
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 785
Relay_Log_File: node2-relay-bin.000003
Relay_Log_Pos: 998
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: pandora
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 785
Relay_Log_Space: 1252
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 580d8bb0-6991-11e8-9a22-16efadb2f150
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
|
|
Slave_IO_Running および Slave_SQL_Running が Yes であることを確認します。他の値は例とは異なります。 |
|
1.7.4 トラブルシューティング
1.7.4.1 クラスタノードの一つが動作していない場合に何をすれば良いでしょうか?
マスターノードが動作している限り、サービスには影響がありません。もしマスターノードで障害が発生した場合は、スレーブが自動的にマスターに昇格します。詳細は、 障害ノードの修正 を参照してください。
