Pandora:Docuemntation ja:MySQL Replica

From Pandora FMS Wiki

Jump to: navigation, search

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

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

概要

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

我々は、リアルタイム H/A を実現するために、仮想IP(VIP)の仕組みに UCARP アプリケーションを利用します。最も簡単なモデルでは、2つの UCARP デーモンが動作しており、マスターで障害が発生したら、セカンダリが VIP を引き継ぎ処理が通常通り動作します。スレーブが、Pandora FMS サーバとコンソールの MySQL 操作を復帰させます。ユーザは何も気にしません。

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

他の MySQL HA モデルとの比較

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

  • MySQL クラスタ: とても複雑でパフォーマンスの問題がありますが、アクティブ・アクティブ(クラスタ)な環境を実現する唯一の方法です。詳細は我々のドキュメントで説明しています。
  • MySQL レプリケーション / ucarp: まずシンプルで、高速かつとても標準的なものです。しかし、マスターをシステムに戻すためには、いくつかのスクリプトが必要であるのと複雑な部分があります。このドキュメントにて説明します。
  • DRBD / heartbeat : シンプルで、早く、システムのブロックデバイスをもとにしています。これもまた我々のドキュメントで説明しています。Pandora FMS で HA を組む場合の公式な方法です。

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

初期の環境

以下に我々のテストシナリオを示します。

192.168.10.101 (castor) -> マスター

192.168.10.102 (pollux) -> スレーブ

192.168.10.100 仮想IP

192.168.10.1 pandora -> mysql接続

MySQL サーバの設定

マスターノード (Castor)

my.cnf ファイル(Debian システム):

[mysqld]
bind-address=0.0.0.0
log_bin=/var/log/mysql/mysql-bin.log
server-id=1
innodb_flush_log_at_trx_commit=1
sync_binlog=1
binlog_do_db=pandora
binlog_ignore_db=mysql

スレーブノード (Pollux)

my.cnf ファイル:

[mysqld]
bind-address=0.0.0.0
server-id=2
innodb_flush_log_at_trx_commit=1
sync_binlog=1

レプリケーションユーザの作成

それぞれのスレーブは、MySQL のユーザでマスターへ接続しなければいけません。スレーブが接続できるようにするためのユーザがマスターに必要です。どんなアカウント名でも構いませんが、REPLICATION SLAVE 権限が必要です。

mysql> CREATE USER 'replica'@'192.168.10.102' IDENTIFIED BY 'slayer72';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'replica'@'192.168.10.102';
mysql> FLUSH PRIVILEGES;

pandora DB のインストール

マスターノード(Castor)に、インストール用の .sql ファイルから新たなデータベースを作成するか、現在のデータベースをダンプします。

マスターサーバにログインし、以下を実行します。

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

既存のデータでのレプリケーション設定

マスターノード(castor)の現在のデータベースをレプリケーションするようにします。全ての情報をスレーブにレプリケートする最初のステップとして、データベースに変更がかからないようにします。その後、ポジションとダンプを取得します。マスターデータベースで書き込みが続いても気にする必要はありません。レプリケーションは、初期のポジションからの変更をすべて複製します。更新は順番に実行されるものであり、スレーブへ複製する開始場所を固定したと考えてください。具体的には次のようにします。

1. コマンドラインのクライアントでマスターサーバに接続します。FLUSH TABLES WITH READ LOCK を実行することにより、全てのテーブルを flush し変更がかからないようにします。

mysql> FLUSH TABLES WITH READ LOCK;

2. データベースへの書き込みがブロックされています。SHOW MASTER STATUS により、現在のバイナリログファイル名とポジションを確認します。

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

最初のカラムがログファイルの名前で、Position がファイルのポジションです。この例では、バイナリログファイルが mysql-bin.000003 で、ポジションが 98 です。のちほどスレーブを設定するときに必要になります。これらは、マスターの更新をスレーブでどこから行うかを示しています。

3. シェルにて mysqldump を実行します。

$ mysqldump -u root -pnone pandora -B --master-data > /tmp/dbdump.sql

このダンプは特別で、スレーブサーバのための情報を含めています(--master-data)。また、(-B) を指定することで、データベースおよびユーザ作成の情報が SQL ダンプに含まれます。

4. MySQL マスターサーバのロックを解除します。

mysql> unlock tables;

5. スレーブサーバへ SQL ファイルをコピーします(ftp, sshなどにて)。

6. MySQL コンソールに接続し、スレーブサーバを停止します。

mysql> SLAVE STOP;

7. スレーブサーバの現在の pandora データベースを Drop します(存在する場合)。

mysql> drop database pandora;

8. マスターとの通信を確立するために次の SQL を実行します。

mysql> CHANGE MASTER TO MASTER_HOST='192.168.10.101', MASTER_USER='replica', MASTER_PASSWORD='slayer72';

現在のマスターサーバ(192.168.10.101)を指し示すことに注意してください。

9. マスターサーバで取得したダンプをインポートします。

mysql> SOURCE /tmp/dbdump.sql;

10. スレーブを開始します。

mysql> SLAVE START;

11. 同期の状態を確認します。

mysql> SHOW SLAVE STATUS;

12. 問題無いかどうか "Waiting for master to send events" を確認します。

Pandora サーバからデータベースを利用できるようにするための設定

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

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

Pandora サーバの起動

全てが問題無い状態である必要があります。

正しいか確認します。

スレーブサーバおよびマスターサーバで、次の 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 | 
+----+-------------+-----------+------+---------+------+----------------------------------------------------------

切り替え

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

mysql> STOP SLAVE; 
mysql> RESET MASTER;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

パッケージを入手し、インストールしてください。設定はとても簡単です。それぞれの 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