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にしたときに複数のトランザクションをまとめる。単位はパラメータで調整可能 |
参考ページ https://www.server-world.info/query?os=CentOS_7&p=mariadb&f=3 http://qiita.com/suzutsuki0220/items/e5be03ea8f44ad2f6533
救われた面もあるのでなんともだが、遅延が酷いと1時間近くにもなることがある。 slave stop & start すると復帰するが、原因は突き止めたい。
SHOW SLAVE STATUS¥G 中略 Seconds_Behind_Master: 1
SHOW MASTER STATUS¥G
master | slave |
File: mysql-bin.000024 | Master_Log_File: mysql-bin.000023 |
Position: 198937070 | Read_Master_Log_Pos: 198837070 |
ファイルに差分があれば、ネットワーク転送でボトルネックがあることになる。
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オプションを利用して、移行対象を絞るべし
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.2/255.255.255.255' IDENTIFIED BY 'hogehoge';
上記の操作でユーザーの追加と権限付与が一度に行える!
[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)
この番号は更新がなければ変わらないようだ。
$ mysqldump -u root -p --all-databases --lock-all-tables --events | gzip > mysql_dump.sql.gz
unlock tables;
$ mysql -u root -p < /var/tmp/mysql_dump.sql
MariaDB [(none)]> change master to master_host='MASTER_IP', master_user='newrepl', master_password='hogehoge',master_log_file='mysql-bin.000001',master_log_pos=245;
MariaDB [(none)]> start slave;
show slave status\G
-- -- 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'@'%'
ダンプからレプリケーションをスタートさせてしばらくは順調だったが、1週間後にのぞいたらこのエラー。
手動の確認手順が多いため、VPS同士であればバックアップからのリカバリーの方が楽だろう。
# プロセス(クエリ)が流れてないことを確認(なかなか消えないので下の数値が一致していればよしとした) mysql> SHOW PROCESSLIST; # 書き込みロックを実行する(ロックが外れるのでmysqlから出ない) mysql> FLUSH TABLES WITH READ LOCK; Query OK, 0 rows affected (0.00 sec) # positonの確認 MariaDB [(none)]> SHOW MASTER STATUS\G *************************** 1. row *************************** File: mysql-bin.000037 Position: 3524806 Binlog_Do_DB: Binlog_Ignore_DB: 1 row in set (0.00 sec)
# レプリケーション(IO_THREAD)を停止する mysql> STOP SLAVE IO_THREAD; # Has read all relay logが出るまで待機 mysql> SHOW PROCESSLIST; # Master_Log_FileとRead_Master_Log_Posをメモ mysql> SHOW SLAVE STATUS\G
# レプリケーション系の設定を初期化 mysql> RESET SLAVE ALL; mysql> RESET MASTER;
ansibleタスク利用。
旧マスターは新マスターのIPへ 新マスターはlocalhostへ