個人用ツール

Pandora:Docuemntation ja:MySQL Replica

提供: Pandora FMS Wiki JP

移動先: 案内, 検索

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

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

概要

This configuration is proposed to have a complete HA environment in Pandora FMS that is based on an active/passive model. The standard MySQL (not the MySQL cluster), allows to have a single MASTER (which allows INSERT/UPDATE operations) and several SLAVES, which are only allowed to read operations. This is used in various environments to have a distributed database model. In Pandora all the Read/Write operations are done against the same server of the DB, so this model cannot be used. Either way, replication is also used to have a "copy" of our main database, so if there is a bug, you can "Lift" the slave to be the master of the database and use it.

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

After failover, you will need to restart (manually, as this is a very delicate process), the Master system and transfer all data from the Slave to the Master again.

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

初期の環境

192.168.10.202 (master) -> Master server

192.168.10.203 (slave) -> Slave server

192.168.10.206 (pandora) -> Pandora Server

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

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

192.168.10.206 (pandora) -> Pandora サーバ

MySQL サーバの設定

インストールと設定

The following packages must be installed on both nodes of the mysql cluster for the cluster to work properly. In this case, a Percona cluster has been chosen in version 5.7. (Realized installation on Centos 7, perform installation on both Master and Slave nodes).

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

a) Install Percona repository

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

To install the next Percona repository you need to install the following package as long as you have access to the internet from the machine, with the root user.

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) Install Percona Server v5.7 and all the necessary components for its correct functioning. Apart from the server, client and libraries, we will also install Percona xtrabackup that we will use to make the replication between both nodes:

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


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

Once the server is installed in both nodes, we proceed to configure the /etc/my.cnf file in the master node:

双方のノードにサーバをインストールしたら、マスターサーバの /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

Once the master server is configured with this configuration we can start the mysql server in the master server.

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

Master#service mysql start

In Percona version 5.7 when you start mysql service for the first time, a temporary root password is created and can be found in the mysql /var/log/mysqld.log . Once we access the mysql server with this password we can modify it for another one that is more convenient.

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

In order to allow replication on the slave node, the appropriate grants must be added to the server.

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

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

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

First of all we have to back up the master. As we have just no information the size with which we will work for this point of replication will be quite small.

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

In order to perform the backup, we will use the xtrabackup tool in which we will have to indicate the backup parameter for its execution, the user and password of the database (if they are correctly added to the database we can omit this information) and the directory where we are going to store the backup using the parameter -target-dir (in the example /home/backup)

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

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

When completed, a directory will be created inside the indicated one with the creation date data, in the example /home/backup/2017-11-29_13-11-41

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

For the backup to be consistent, the next run must be launched:

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

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

When the backup is ready, the next step is to copy all the information to the Slave server (backup and /etc/my. cnf) To copy the backup to the slave server we will perform the following execution, knowing that the directory datadir (in the /var/lib/mysql example) of the slave server has to be empty.

バックアップができたら、次のステップは全情報(バックアップおよび /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/

We make sure that mysql directory permissions are correct:

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

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


スレーブサーバの設定

The first thing is to configure the configuration file of mysql /etc/my. cnf. This will be a direct copy of the master server configuration file with the difference that in this case the parameter server_id=2.

最初に行うのは、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


To start cluster replication the first thing is to see the contents of the xtrabackup_binlog_info file that can be found in the slave server's datadir directory.

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

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


We connect to the mysql of the slave server and introduce the following queries that will allow us to indicate who the master server is and start the slave. The parameter read_only must be applied to 1 in the slave so that no additional information is accidentally added to the slave node.

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;


If replication has been successfully started, this information will appear on the slave server:

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

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


Slave_IO_Running and Slave_SQL_Running show us the status of the cluster, while the Seconds_Behind_Master value shows the lag seconds between the information located in the master and slave.

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

Pandora DB のインストール

Create a new one from the. sql installation files or launch the current one on the master node (Castor).

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

Log on to the master server:

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

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

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

In both servers:

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

mysql> grant all privileges on pandora.* to pandora@192.168.10.1 identified by 'pandora';
mysql> flush privileges;

Once applied these permissions we should be able to see the Pandora FMS console and start the Pandora FMS server when the license has been applied correctly.

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

On slave and master servers, check which processes are running with the following SQL command:

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

mysql> show processlist;


It should show something like:

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

+----+-------------+-----------+------+---------+------+----------------------------------------------------------
| 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 | 
+----+-------------+-----------+------+---------+------+----------------------------------------------------------

切り替え

スレーブからマスターへ

In this case the MASTER server is down and the SLAVE remains active but in slave mode and with write protection enabled. To make the transition from Slave to Master, the following SQL commands must be launched on the Slave server.

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

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


Your SLAVE server is now working as MASTER. The SLAVE does not use the replication log of the MASTER and the MASTER is now "out of sync", which means that if your PANDORA FMS points to the old master server, you will get obsolete information. This is one of the most problematic aspects and most of the problems stem from it.

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

The first "Switchover", which means that when the official MASTER falls down, and the official SLAVE becomes the NEW master, is not a problem, it is something completely automatic since the systems make queries against the SLAVE/server of the new master.

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

旧マスターへの切り戻し

The problem is the "second" switchover, when you want the old master to become the official master again.

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

In this step, you will need to perform the entire process again to synchronize the entire HA model, this means:

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

1. Stop Pandora Server service.

2. Stop mysql service of the master node and delete all directory datadir.

3. Replicate the slave node database to the master node. (Point 1.3.1.3.).

4. Stop mysql service at slave node.

5. Start mysql master node mysql start

6. Start slave replication on slave node. (Point 1.3.1.4).

7. Check that it replicates correctly.

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

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

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

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

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

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

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

(OBSOLETE)

他の MySQL HA モデルとの比較

There are many ways to implement MySQL HA, we have explored three:

MySQL の HA を実現する方法は複数あります。我々は以下の 3種類を考えました。

  • MySQL Cluster: Very complex and with a performance penalty, is the unique way to have a real active/active (cluster) enviroment. Described in depth in our documentation.
  • MySQL クラスタ: とても複雑でパフォーマンスの問題がありますが、アクティブ・アクティブ(クラスタ)な環境を実現する唯一の方法です。詳細は我々のドキュメントで説明しています。
  • MySQL Binary Replica / ucarp: Simple at fist, fast and very standard, but with several scripts and complexity to get back the master in the system. This documentation.
  • MySQL レプリケーション / ucarp: まずシンプルで、高速かつとても標準的なものです。しかし、マスターをシステムに戻すためには、いくつかのスクリプトが必要であるのと複雑な部分があります。このドキュメントにて説明します。
  • DRBD / heartbeat : Simple, fast and based on system block devices. Also described in our documentation. It's the official way to implement HA in Pandora FMS.
  • DRBD / heartbeat : シンプルで、早く、システムのブロックデバイスをもとにしています。これもまた我々のドキュメントで説明しています。Pandora FMS で HA を組む場合の公式な方法です。

In our opinion, the best way to implement the HA is to have the simplest possible setup, because when something fails, any extra complexity will led to confusion and data loss if procedures are not extremely well tested and written. Most times, operators only follow procedures and cannot react to things outside the procedures, and HA could be very difficult to have a exact procedures in most cases.

我々の考えとしては、HA を実装する最も良い方法は設定が簡単であるということです。なぜなら、何らかの障害が発生したとき、手順が良くテストされていない場合には、複雑な部分があると競合やデータ消失を招きかねないからです。ほとんどの場合、オペレータは手順に従うのみで手順外のことに対応することはできません。そして、ほとんどの場合で HA は難しい手順になります。

xxx

That means: do the slave to become the master. In the event MASTER server is down, or for any reason the VIP points to the SLAVE server, you must be sure that the SLAVE server executes following SQL commands:

スレーブがマスターになることを意味します。マスターサーバがダウンしたり、その他理由により VIP がスレーブサーバに移った場合は、スレーブサーバで次の SQL コマンドを実行する必要があります。

mysql> STOP SLAVE; 
mysql> RESET MASTER;

Your Slave server is now working as MASTER. SLAVE doesnt use the replication log from the MASTER and the MASTER is now "out of sync", that means if your Pandora FMS points to the old-master server, will have old information. This is one of the most problematic points and most problems comes from here.

スレーブサーバは、マスターとして動作します。スレーブは、マスターからのレプリケーションログを利用せず、マスターは同期対象外となります。もし Pandora FMS が旧マスターサーバを参照していれば、それは古い情報となることを意味します。これは問題になりやすいポイントの一つで、ほとんどの問題は、ここから発生します。

The first "Switchover", that means, when the official MASTER goes down, and the official SLAVE becomes the NEW master, is not a problem, it's fully automatic since systems do the queries against the SLAVE / New master server. The problem is the "second" switchover, that means, when you want to have the old-master to become the official master again.

まず最初に、切り替えが意味することは、マスターがダウンした時に、スレーブが新たなマスターになることです。これは問題ではありません。完全に自動的にクエリを新たなマスターサーバ(スレーブ)に対して実行します。問題は、二回目の切り替えです。つまり、旧マスターを再度正式なマスターにしたい場合です。

In this step you need to re-done the full process to sync all the HA model, that means.

この場合、HA を同期するための全処理を再び行う必要があるということです。

1. Stop all pandoras.

1. 全ての pandora を停止します。

2. Dump the database from the old-slave (Pollux) to a clean SQL:

2. 元スレーブ(Pollux)からデータベースをダンプします。

$ mysqldump -B -u root -pnone pandora > /tmp/pandoradump.sql

3. Copy the sql dump to the official master (Castor)

3. ダンプファイルを正式なマスター(Castor)へコピーします。

4. Restore the SQL and drop all old information

4. SQL をリストアし、古い情報を drop します。

mysql> drop database pandora;
mysql> source /tmp/pandoradump.sql;

5. In this point both databases are equal, so just obtain the coordinates to set slave back "to replicate" and degrade to SLAVE. Get the coordinates from the official MASTER:

5. ここで双方のデータベースが同一になります。そこで、スレーブにレプリケーションを張るための情報を取得し、元々スレーブであったサーバをスレーブに設定しなおします。正式なマスターから、次のように情報を取得します。

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 234234   | pandora      | mysql            |
+------------------+----------+--------------+------------------+

(File and Position are the coordinates)

(ファイルおよびポジションが必要です)

6. Use this SQL in the SLAVE:

6. スレーブで以下の SQL を実行します。

mysql> SLAVE STOP;
myqsl> CHANGE MASTER TO MASTER_HOST='192.168.10.101', MASTER_USER='replica', MASTER_PASSWORD='slayer72', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=234234;
mysql> SLAVE START;

7. Everything should be ok, so you can now restart your VIP processes to asssign the VIP to the official master (Castor) and let Pollux again the slave role.

7. すべての準備が整ったので、公式なマスター(Castor)へ VIP を割り当てるために VIP プロセスを再起動し、Pollux は再びスレーブにします。

NOTE: There is another way to implement failover which supposes MASTER/SLAVE role is not fixed, but that means this "relative" role should be implemented in the VIP model, using UCARP that means to change the priority in vhid. Another way to solve this problem is to use Heartbeat VIP mechanism (See our docs about DRBD).

注意: 他にマスター・スレーブの関係を修正せずにフェイルオーバーを実装する方法があります。しかし、UCARP を使った VIP モデルでは、vhid で優先順位を定義するため、そのような実装ができません。この問題を解決するには、VIP に Heartbeat を使ってください(DRBD のドキュメントで触れています)。

ロードバランシングの設定

We are using UCARP, which uses CARP protocol (http://en.wikipedia.org/wiki/Common_Address_Redundancy_Protoco). More information on: http://ucarp.org/

我々は、CARP プロトコル( http://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol )を使う UCARP を利用しています。詳細は、http://ucarp.org/ を参照してください。

Get the package and install it. Setup is very easy, you need to have a ucarp process running on each mysql server.

パッケージを入手し、インストールしてください。設定はとても簡単です。それぞれの mysql サーバで ucarp プロセスを動かします。

Castor / マスター

ucarp --interface=eth1 --srcip=192.168.10.101 --vhid=1 --pass=pandora  --addr=192.168.10.100 --upscript=/etc/vip-up.sh --downscript=/etc/vip-down.sh &

Pollux / スレーブ

ucarp --interface=eth1 --srcip=192.168.10.102 --vhid=2 --pass=pandora  --addr=192.168.10.100 --upscript=/etc/vip-up.sh --downscript=/etc/vip-down.sh &

スクリプトの内容

[/etc/vip-up.sh]

#!/bin/bash
/sbin/ifconfig "$1":254 "$2" netmask 255.255.255.0

[/etc/vip-down.sh]

#!/bin/bash
/sbin/ifconfig "$1":254 down

追加スクリプト

[/etc/mysql-create-full-replica.sh]

#!/bin/bash
echo "FLUSH TABLES WITH READ LOCK;" | mysql -u root -pnone -D pandora
mysqldump -u root -pnone pandora -B --master-data > /tmp/dbdump.sql
echo "UNLOCK TABLES;" | mysql -u root -pnone -D pandora

[/etc/mysql-restore-replica.sh]

scp root@192.168.10.101:/tmp/dbdump.sql .
echo "SLAVE STOP; drop database pandora; SOURCE /tmp/dbdump.sql;" | mysql -u root -pnone -D pandora

[/etc/mysql-become-slave.sh]

echo "CHANGE MASTER TO MASTER_HOST='192.168.10.101', MASTER_USER='replica', MASTER_PASSWORD='slayer72'; SLAVE  START;" | mysql -u root -pnone

[/etc/mysql-become-master.sh]

echo "STOP SLAVE; RESET MASTER;" | mysql -u root -pnone