MySQLでのレプリケーションの設定

▲ ▼

レプリケーションとは

通常、データベースを別のサーバに複製することを、「レプリケーション」という。レプリケーションのメリットは、次のとおり。

データベースのバックアップ
データベースの冗長化
サーバの負荷分散

MySQLは標準でレプリケーション機能を備えているが、その方式は「マスタ-スレーブ方式」で、データベースの更新を受け付ける「マスタ」と、マスタから伝搬されたデータを受け付ける「スレーブ」からなる、一方通行の複製になる。

細かいことは、参照先のページを見ること。

▲ ▼

今回の目的

まったく同一構成の2台のマシンがあるので、 1台をマスタ、もう1台をスレーブにして、データベースのバックアップと冗長化をはかる。

▲ ▼

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

スレーブがマスタに接続するための専用ユーザを、マスタで作成する。与える権限は「REPLICATION」「SLAVE」のみ。今回は、ユーザ名「repl」、パスワード「password」で、どのコンピュータからの接続も受け付ける（'%'）ようにする。

master# mysql -u root -p
...
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%' IDENTIFIED BY 'password';

▲ ▼

マスターのデータをスレーブにコピー

マスターの全データを、スレーブにコピーする。

今回は、稼働中のデータベースにレプリケーションを設定するため、次のようなややこしい操作をする。詳細は、参考に書いたページを見ること。

マスタになるよう、設定ファイル（/etc/my.cnf）に追加する
```
[mysqld]
log-bin
server-id=1
```
MySQLを再起動する
マスタで、tarコマンドを使って全データのバックアップをとる
```
master# cd /var/lib/mysql
master# tar cpf /var/tmp/mysql-snapshot.tar .
```
マスタで、すかさずmysqlコマンドを使って、データベースが更新されないよう、書き込みロックをする（別端末で用意しておくとよい）
```
mysql> FLUSH TABLES WITH READ LOCK;
```
マスタで、もう一度tarコマンドを使って全データのバックアップをとる
```
master# tar cpf /var/tmp/mysql-snapshot.tar .
```

マスタで、mysqlコマンドを使って、マスタのバイナリログの位置情報を確認する。
あとで使うので、必ずメモしておくこと

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_do_db | Binlog_ignore_db |
+------------------+----------+--------------+------------------+
| mysql-bin.00002  | 35389    |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

マスタで、書き込みロックを解除する
```
mysql> UNLOCK TABLES;
```
マスタでバックアップしたデータをスレーブにコピーする
```
master# scp /var/tmp/mysql-snapshot.tar slave:/var/tmp/
```

▲ ▼

スレーブを開始する

スレーブのための設定をする。ここからの作業は、失敗してもマスタには影響がないので、何回でもやり直しできる。

スレーブで、起動中のmysqldを停止する
```
slave# service mysql stop
```

マスタからコピーしたデータを展開する

slave# cd /var/lib/mysql
slave# rm -rf *
slave# tar xpf /var/tmp/mysql-snapshot.tar

展開したら、マスタで使っていたバイナリログ用ファイルやエラーログ用ファイルなどを削除する
```
slave# rm -f mysql-bin.????? mysql-bin.index
slave# rm -f マスタのホスト名.pid マスタのホスト名.err
```
スレーブで、/etc/my.cnfを編集して、「server-id」をマスタのと違う数字にする
```
[mysqld]
server-id=2
```
スレーブで、サーバを起動する
```
slave# service mysqld start
```

スレーブで、mysqlコマンドを使って、マスタの情報を設定する

mysql> CHANGE MASTER TO
    -> MASTER_HOST = 'master',
    -> MASTER_USER = 'repl',
    -> MASTER_PASSWORD = 'password',
    -> MASTER_LOG_FILE = 'mysql-bin.00002', （メモしたバイナリログのファイル名）
    -> MASTER_LOG_POS = 35389; （メモしたバイナリログの位置）

スレーブを開始する
```
mysql> START SLAVE;
```
レプリケーションが成功したら、スレーブで、/etc/my.cnfを編集して、マスタの情報を設定する（情報は/var/lib/mysql/masater.infoにすでに書き込まれている）
```
[mysqld]
server-id=2
master-host=master
master-user=repl
master-password=password
```

▲ ▼

追記：my.cnfへの設定の追加

CentOSのバージョンが上がると、いつの間にか、バイナリログファイルを置く場所が変わってしまっていた。ファイル名もホスト名ベースから、デフォルトの「mysql-bin」になってしまっていた。

変更前：/var/lib/mysql/<hostname>-bin.XXXXX
変更後：/var/run/mysqld/mysql-bin.XXXXX

したがって、ここまでに書いた設定では、レプリケーション側がうまく動作しなくなってしまい、問題が生じる。

とりあえず、バイナリログファイル関係（マスタ側）やリレーログファイル関係（スレーブ側）の設定を、/etc/my.cnfに追加する必要がある。詳しくは、下の情報を参照。

CentOSでMySQLのレプリケーション

CentOS5.1でMySQLのレプリケーションを設定。
セオリー通りに設定して無事動いたんですが、
サーバを物理的に再起動すると、あらまバイナリログが初期化される・・・。
で、セカンダリのMySQLはログを見失いレプリケーションが崩れる。。。

色々見ていると、どうもMySQLのバイナリログの保存先が"/var/run/mysql"とかになってる。
で、"/var/run"以下は再起動時に綺麗にお掃除されるため、バイナリログももれなく削除。
と言うことで、起動ファイルに下記を追加して難を凌ぎました。

というわけで、ざっくり書くと、マスタサーバの/etc/my.cnfに次の情報を書いた上で、作業を進める。

log-bin=/var/lib/mysql/mysqld-bin

さらに、スレーブサーバ側の作業を進める時に、次の設定を/etc/my.cnfに用意しておく。

#log-bin=/var/lib/mysql/mysqld-bin ←コメントアウトするか削除する
relay-log=/var/lib/mysql/mysqld-relay-bin
relay-log-index=/var/lib/mysql/mysqld-relay-bin

▲ ▼

追記2：さらにmy.cnfへの設定の追加

Moodleのアップグレードの際に、その途中で、データベースのログにエラーが記録されていた。それに対応するために、次の設定を「/etc/my.cnf」に追加した。

…
binlog_format=row
…

行ベースでバイナリログファイルに記録することになるので、バイナリログファイルの大きさが結構大きくなるみたい……

KAWANO's PukiWiki Plus! - MySQLでのレプリケーションの設定