Pandora: Docuemntation ja: MySQL Replica

From Pandora FMS Wiki
Jump to: navigation, search

Pandora FMS ドキュメント一覧に戻る

1 HA のための MySQL レプリケーションモデル

1.1 概要

ここでは、Pandora FMS をアクティブ・スタンバイの完全な HA 構成にする説明をします。通常の MySQL (MySQL クラスタではありません) では、1台の(INSERT/UPDATE操作ができる)マスターと、複数台の読み込みのみのスレーブを持つことができます。これは、分散データベースモデルのいくつかの環境で使われます。Pandora では、すべての読み書き操作は一つの DB サーバに対して実行されます。そのためこのモデルは使えません。しかしながら、レプリケーションはプライマリデータベースの "コピー" をもつためにも使われます。そこで、障害時にスレーブをマスターデータベースに "昇格" させて使うことができます。

フェイルオーバーの後、マスターだったシステムを復旧し、スレーブからマスターにデータを転送する必要があります(とても慎重に行う必要のある処理なので手動で行います)。

1.2 初期の環境

192.168.10.202 (master) -> マスターサーバ

192.168.10.203 (slave) -> スレーブサーバ

192.168.10.206 (pandora) -> Pandora サーバ

1.3 MySQL サーバの設定

1.3.1 インストールと設定

両方の MySQL ノードに以下のパッケージをインストールする必要があります。ここでは Percona cluster バージョン 5.7 を選択しました。(マスターおよびスレーブ双方で CentOS 7 で実行しています)

a) Percona リポジトリのインストール

Percona リポジトリのインストールには、次のパッケージをインストールする必要があります。root ユーザでインターネットアクセスできる必要があります。

Master & Slave# yum install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
Retrieving http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
  Preparing...                ########################################### [100%]
  1:percona-release        ########################################### [100%]

b) Percona Server v5.7 のインストール および動作に必要なパッケージをインストールします。 サーバ、クライアント、ライブラリとは別に、Percona xtrabackup をインストールします。これは、両方のノード間のレプリケーションに利用します。

Master & Slave# yum install Percona-Server-shared-compat-57 Percona-Server-client-57 Percona-Server-server-57 Percona-Server-shared-57 percona-xtrabackup


1.3.2 マスターサーバの設定と起動

双方のノードにサーバをインストールしたら、マスターサーバの /etc/my.cnf を設定します。

[mysqld]
#Basic configuration parameters
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0

#Optimization parameters (for a server with 4Gb RAM)
max_allowed_packet = 64M
innodb_buffer_pool_size = 256M
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
innodb_io_capacity = 100
thread_cache_size = 8
max_connections = 100
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
query_cache_type = 1
query_cache_size = 4M
query_cache_limit = 8M
sql_mode=""
innodb_flush_log_at_trx_commit=1

# Parameters for the correct operation of binary replication.
# Deleting Binary Logs
expire_logs_days = 3
# Activation of binary logs for replication
log-bin=mysql-bin
sync_binlog=1
# Maximum size of binary logs. The smaller they are, the better the synchronization process will be and the less time it will take. 
there will be. 
max_binlog_size = 100M 
# Master server ID 
server_id=1

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[client]
# Here you can define the default password of the client to simplify the following steps
user=root
password=pandora

マスターサーバで上記の設定をしたら、マスターサーバの mysql を起動できます。

Master#service mysql start

Percona バージョン 5.7 では、最初に mysql サービスを起動するときに一時的な root のパスワードが生成され、/var/log/mysqld.log に書かれます。このパスワードで mysql サーバへアクセスしたら、パスワードを変更します。

スレーブノードへのレプリケーションを許可するために、サーバで適切な権限を追加します。

Master|mysql> GRANT REPLICATION SLAVE ON *.*  TO 'repl'@'slave' IDENTIFIED BY ‘password’;

1.3.3 xtrabackup を使ったマスターからスレーブへのデータベースレプリケーション

まず最初にマスターのバックアップを取ります。まだ情報が蓄えられていないので、レプリケーションのためのこのバックアップはとても小さいです。

バックアップを実行するには、xtrabackup ツールを使用します。実行に必要なバックアップパラメータ、データベースのユーザとパスワード(データベースに正しく追加されている場合はこの情報を省略することができます)、およびバックアップを保存するディレクトリを -target-dir パラメータで指定する必要があります(この例では /home/backup)。

Master# xtrabackup --backup --user=root --password=password --target-dir=/home/backup/   
xtrabackup: completed OK!

完了すると、データを作成した日付のディレクトリが作成されます。例えば /home/backup/2017-11-29_13-11-41 です。

一貫性のあるバックアップを作成するには、次の実行をする必要があります。

Master#xtrabackup --user=root --password=password --prepare --target-dir=/home/backup/2017-11-29_13-11-41 

バックアップができたら、次のステップは全情報(バックアップおよび /etc/my.cnf)をスレーブサーバにコピーします。 スレーブサーバへバックアップをコピーするには次のようにします。スレーブサーバのデータディレクトリ(例えば/var/lib/mysql)は空にします。

Master# rsync -avpP -e ssh /home/backup/2017-11-29_13-11-41 Slave:/home/backup/

Slave#mv /home/backup/2017-11-29_13-11-41/* /var/lib/mysql/

mysql ディレクトリのパーミッションが正しいか確認します。

Slave#chown –R mysql:mysql /var/lib/mysql/


1.3.4 スレーブサーバの設定

最初に行うのは、mysql の /etc/my.cnf ファイルを設定することです。これは、マスターサーバからコピーしたファイルで、この場合、違いは server_id=2 の部分です。

[mysqld]
#Basic configuration parameters
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0

#Optimization parameters (for a server with 4Gb RAM)
max_allowed_packet = 64M
innodb_buffer_pool_size = 256M
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
innodb_io_capacity = 100
thread_cache_size = 8
max_connections = 100
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
query_cache_type = 1
query_cache_size = 4M
query_cache_limit = 8M
sql_mode=""
innodb_flush_log_at_trx_commit=1

# Parameters for the correct operation of binary replication.
# Deleting Binary Logs
expire_logs_days = 3
# Activation of binary logs for replication
log-bin=mysql-bin
sync_binlog=1
# Maximum size of binary logs. The smaller they are, the better the synchronization process will be and the less lag there will be. 
max_binlog_size = 100M 
# Master server ID 
server_id=2

[mysqld_safe]
log-error=/var/log/mysqld.log 
pid-file=/var/run/mysqld/mysqld.pid

[client]
# Here you can define the default password of the client to simplify the following steps
user=root
password=pandora
We boot the mysql server on the slave node: 
Slave#service mysql start


レプリケーションを開始するために最初に実施することは、xtrabackup_binlog_info の内容を確認です。スレーブサーバのデータディレクトリ内にあります。

Slave#cat /var/lib/mysql/xtrabackup_binlog_info
Master-bin.000001	380


mysql のスレーブサーバへ接続し、マスターサーバの指定とスレーブの開始を行う次のクエリを実行します。スレーブサーバに意図せず書き込みが行われないように、read_only を 1 に設定します。

Slave|mysql> 'CHANGE MASTER TO MASTER_HOST='master', 
MASTER_USER='repl',MASTER_PASSWORD='password',MASTER_LOG_FILE='TheMaster-bin.000001',MASTER_LOG_POS=380;
Slave|mysql> START SLAVE;
Slave|mysql>SET GLOBAL read_only = 1;


正しくレプリケーションが開始すると、スレーブサーバは以下の状態になります。

Slave|mysql> SHOW SLAVE STATUS \G
         ...
         Slave_IO_Running: Yes
         Slave_SQL_Running: Yes
         ...
         Seconds_Behind_Master: 8
         ...


Slave_IO_Running および Slave_SQL_Running がレプリケーションの状態を表します。Seconds_Behind_Master がマスターとスレーブの間の情報伝達の差を秒で表します。

1.4 Pandora DB のインストール

インストール用の .sql ファイルからマスターサーバで新規作成します。

マスターサーバで以下を実行します。

mysql> create database pandora;
mysql> use pandora;
mysql> source /tmp/pandoradb.sql;
mysql> source /tmp/pandoradb_data.sql;

1.4.1 Pandora が利用できるようにするための DB サーバの設定

双方のサーバで以下を実行します。

mysql> grant all privileges on pandora.* to [email protected] identified by 'pandora';
mysql> flush privileges;

権限を設定したら Pandora FMS コンソールからアクセスできるようになり、ライセンスを正しく適用したら Pandora FMS サーバを起動できます。

スレーブおよびマスターサーバで、次の SQL コマンドで実行中の処理を確認します。

mysql> show processlist;


つぎのような内容が表示されます。

+----+-------------+-----------+------+---------+------+----------------------------------------------------------
| Id | User        | Host      | db   | Command | Time | State                                                                 | Info             |
+----+-------------+-----------+------+---------+------+----------------------------------------------------------
| 32 | root        | localhost | NULL | Sleep   |   72 |                                                                       | NULL             | 
| 36 | system user |           | NULL | Connect |  906 | Waiting for master to send event                                      | NULL             | 
| 37 | system user |           | NULL | Connect |    4 | Has read all relay log; waiting for the slave I/O thread to update it | NULL             | 
| 39 | root        | localhost | NULL | Query   |    0 | NULL                                                                  | show processlist | 
+----+-------------+-----------+------+---------+------+----------------------------------------------------------

1.5 切り替え

1.5.1 スレーブからマスターへ

この場合、マスターサーバがダウンし、スレーブは生きていますがスレーブモードであり書き込みができません。スレーブをマスターに昇格させるには、以下の SQL コマンドをスレーブサーバで実行する必要があります。

Slave|mysql>  STOP SLAVE; 
Slave|mysql> RESET MASTER;


スレーブであったサーバは、マスターとして動作します。スレーブはレプリケーションログを利用せず、マスターは同期していない状態です。これは、PANDORA FMS が古いマスターサーバーを指している場合に古い情報を取得することを意味します。これはよくある問題の 1つであり、問題の大部分はこれに由来します。

最初の切り替わりでは、当初のマスターがダウンし、当初のスレーブが新たなマスターになりました。システムが元スレーブであった新マスターサーバに対して自動的にクエリを出すようになれば問題はありません。

1.5.2 旧マスターへの切り戻し

問題は、元々マスターであったサーバをもとに戻す時の 2回目の切り替わりです。

この場合、同期の処理を再度行う必要があります。

1. Pandora サーバのサービス停止

2. 元マスターノードの mysql サービスを停止し、データディレクトリの全データの削除

3. スレーブノード(新マスター)のデータベースをマスターノードへコピー (Point 1.3.1.3.).

4. スレーブノードの mysql サービス停止.

5. マスターノードで mysql を起動

6. スレーブノードでのレプリケーション開始 (Point 1.3.1.4).

7. レプリケーションができているかどうかの確認