DB/MySQL/レプリケーションの履歴(No.10)

MySQLのレプリケーションについて

用語まとめ
GTIDを利用したレプリケーション
- 注意点
設定
トラブルシューティング
- レプリケーションユーザーでつながらない

用語まとめ†

GTID	Global Transaction IDの略。サーバーIDと合わせて世界で一意となるID。MySQL5.6から導入。これを利用した設定情報公開はまだ少数派
MHA	マスター自動昇格のためのツール。GTID導入以前はこのツールが使われていたが、今でも十分
I/Oスレッド	バイナリろぐの転送
SQLスレッド	SQLの差分実行。こちらがボトルネックになることが多く、SBM(SecondsBehindMaster)を発生させる。5.7では同一DB内の平行SQLスレッドにより改善された。
トポロジ	masterに対してslaveが複数や、slaveが他のslaveのmasterになる多段構成、マルチマスタも可能
準同期レプリケーション	非同期が基本だが、IOスレッドまでは同期を保証する。設定が必要でslaveのDiskI/Oに影響されるため導入は慎重に！5.7の改良でロスレスになった！
マルチソースレプリケーション	複数のmasterからのレプリケーション
グループコミット	sync_binlog=1にしたときに複数のトランザクションをまとめる。単位はパラメータで調整可能

↑

GTIDを利用したレプリケーション†

↑

注意点†

create table ... selectなどが使えない。enforce_gtid_sconsistency = WARNにして様子を見て切り替える。
master/slaveともbinlogの設定が必要。

↑

設定†

参考ページ https://www.server-world.info/query?os=CentOS_7&p=mariadb&f=3 http://qiita.com/suzutsuki0220/items/e5be03ea8f44ad2f6533

↑

遅延対策†

救われた面もあるのでなんともだが、遅延が酷いと１時間近くにもなることがある。 slave stop & start すると復帰するが、原因は突き止めたい。

↑

slaveの状態を確認†

Seconds_Behind_Masterの値が0であればよい。

SHOW SLAVE STATUS¥G
中略
Seconds_Behind_Master: 1

↑

Seconds_Behind_Masterが0なのに、遅延が発生している場合†

master側のbinログのポジションを確認

SHOW MASTER STATUS¥G

master	slave
File: mysql-bin.000024	Master_Log_File: mysql-bin.000023
Position: 198937070	Read_Master_Log_Pos: 198837070

ファイルに差分があれば、ネットワーク転送でボトルネックがあることになる。

↑

AWSのRDSの場合(専用のプロシージャーを利用する)†

http://takeshiyako.blogspot.jp/2014/12/mysqlamazon-rds.html

mysql> CALL mysql.rds_set_external_master('100.100.100.100',3306,'userrds','passwordrds','mysql-bin.000855',846543983,0);

mysql> CALL mysql.rds_start_replication;

すべてのデータベースをdumpするとmysqlデータベースインポート中にエラーになるので個別にやるしかない。databasesオプションを利用して、移行対象を絞るべし

↑

マスターの設定†

↑

ユーザーの追加(IPをスレーブのものに限定)†

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.2/255.255.255.255' IDENTIFIED BY 'hogehoge';

上記の操作でユーザーの追加と権限付与が一度に行える！

↑

マスターのmy.cnf変更して再起動†

[mysqld]
log-bin=mysql-bin
server-id=1
expire_logs_days=7

mysql-binでバイナリログを有効にして、server-idはかぶらないものをつける。expire_log_daysは7日間はバイナリログを保存する（それ以上にレプリケーションがとまるとダンプしなおし)

↑

スレーブの設定†

[mysqld]
log-bin=mysql-bin
server-id=102
read_only=1
# 自身のホスト名を定義(show slave hostsのときに出てくる)
report-host=slavehost

↑

ダンプとリカバリー†

↑

マスター†

MariaDB [(none)]> flush tables with read lock;
Query OK, 0 rows affected (0.01 sec)

MariaDB [(none)]>  show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 22826177 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

この番号は更新がなければ変わらないようだ。

別ターミナルでdump

$ mysqldump -u root -p --all-databases --lock-all-tables --events | gzip > mysql_dump.sql.gz

終わったらunlock

unlock tables;

状態の確認

↑

スレーブ†

$ mysql -u root -p < /var/tmp/mysql_dump.sql

MariaDB [(none)]> change master to master_host='MASTER_IP', master_user='repl', master_password='hogehoge',master_log_file='mysql-bin.000001',master_log_pos=22826177;

レプリケーションスタート

MariaDB [(none)]> start slave;

状態の確認

show slave status\G

dumpファイルに記載がある状態からもスタート可能

--
-- Position to start replication or point-in-time recovery from
--

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000015', MASTER_LOG_POS=245;

change master to master_host='HOST', master_user='repl', master_password='hogehoge',master_log_file='mysql-bin.000015',master_log_pos=245;

↑

トラブルシューティング†

↑

レプリケーションユーザーでつながらない†

ユーザー登録時にパスワードが設定されてないユーザーで接続しようとしていた。作成時にパスワード設定忘れた模様！

SHOW GRANTS FOR 'repl'@'%';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'

Counter: 3992, today: 2, yesterday: 1

DB/MySQL/レプリケーション の履歴(No.10)