2 ．マスターサーバーにレプリケーション用ユーザーを作成 (GTID 有効 )
• "REPLICATION SLAVE" 権限を付与してユーザーを作成
3 ．バックアップを取得してスレーブサーバーへリストア (GTID 有効 )
• コールドバックアップを取得してリストアする
– datadir
配下のauto.cnf
を削除しておく(
マスターとスレーブでserver-uuid
を一意にするため( ※ ))
※ GTID
のフォーマットにはserver-uuid
が含まれているため、server-uuid
を一意にしておく必要あり3 ．バックアップを取得してスレーブサーバーへリストア (GTID 有効 )
• mysqldump でバックアップを取得してリストアする
– mysql.gtid_executed
テーブルの情報を最新状態にして一貫性のあるバックアップを取得するために、必ず
--flush-logs
と--single-transaction
を指定する–
バックアップ取得例$ mysqldump --user=root --password=root --master-data=2 ¥ --flush-logs --socket=/usr/local/mysql/data/mysql.sock ¥ --hex-blob --default-character-set=utf8 --all-databases ¥
--single-transaction --triggers --routines --events > mysql_bkup_dump.sql
※ Warning
発生を防ぐために”--triggers --routines --events”
も指定※ GTID
モードで取得したmysqldump
には、”SET @@GLOBAL.GTID_PURGED=‘XXX’;”
が含まれる補足： gtid_execute の値の例
• マスターサーバーでの実行例
mysql> show master status;
+---+---+---+---+---+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +---+---+---+---+---+
| binlog.000009 | 2189 | | | c86493ae-9714-11e5-b9d8-080027ff56de:1-29 | +---+---+---+---+---+
1 row in set (0.00 sec)
mysql> select * from mysql.gtid_executed;
+---+---+---+
| source_uuid | interval_start | interval_end | +---+---+---+
| c86493ae-9714-11e5-b9d8-080027ff56de | 1 | 11 |
| c86493ae-9714-11e5-b9d8-080027ff56de | 12 | 14 |
| c86493ae-9714-11e5-b9d8-080027ff56de | 15 | 18 |
| c86493ae-9714-11e5-b9d8-080027ff56de | 19 | 22 | +---+---+---+
4 rows in set (0.00 sec)
値が違う補足： gtid_execute の値の例（続き）
• マスターサーバーでの実行例
mysql> FLUSH BINARY LOGS;
Query OK, 0 rows affected (0.05 sec) mysql> show master status;
+---+---+---+---+---+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +---+---+---+---+---+
| binlog.000010 | 194 | | | c86493ae-9714-11e5-b9d8-080027ff56de:1-29 | +---+---+---+---+---+
1 row in set (0.00 sec)
mysql> select * from mysql.gtid_executed;
+---+---+---+
| source_uuid | interval_start | interval_end | +---+---+---+
| c86493ae-9714-11e5-b9d8-080027ff56de | 1 | 29 | +---+---+---+
1 row in set (0.00 sec) FLUSH BINARY LOGS
により、値が同じになった
補足： mysqldump のオプション
• --flush-logs
–
ダンプを取得する前に、バイナリログをフラッシュする• --master-data=2
–
バックアップ取得のバイナリファイル名とバイナリファイル内の位置( Position )
を コメントとしてバックアップファイルに記録• --hex-blob
–
バイナリ型( BINARY
、VARBINARY
、BLOG )
とBIT
型のデータを16
進数表記で出力• --default-character-set
– mysqldump
がデフォルトで利用するキャラクタセットを指定。通常は
MySQL
サーバのシステム変数default-character-set
と同じものを指定すれば良い• --all-databases
–
全てのデータベースをバックアップ• --single-transaction
– InnoDB
がサポートしているトランザクションの仕組みを利用して、InnoDB
テーブルに限り一貫性のとれたバックアップを取得する注意事項： mysqldump によるバックアップ
•
データの整合性を保つために、バックアップ取得中は、テーブルに関するDDL
文( ※ )
を実行しないこと※ ALTER TABLE, CREATE TABLE, DROP TABLE,RENAME TABLE, TRUNCATE TABLE
•
マニュアルの“--single-transaction”
オプションの説明部分より引用–
「--single-transaction
ダンプの処理中、ダンプファイルが正当である(
テーブルの内容と バイナリログ座標が正しい)
ことを保証するために、ほかの接続でALTER TABLE
、CREATE TABLE、DROP TABLE、RENAME TABLE、TRUNCATE TABLE ステートメントを使用しないようにし
てください。一貫性読み取りはこれらのステートメントから分離されないため、ダンプされるテーブル でこれらを使用すると、mysqldump
によって実行され、テーブルの内容を取得するSELECT
が、正しくない内容を取得したり失敗したりすることがあります。」