More Related Content Similar to サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技 (20) サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技36. バックアップ手法のおさらい
論理バックアップ
ファイル構造に依存せずにSQLでデータを取ってくる(要は全部のテ
ーブルに SELECT * FROM .. を繰り返す)
なのでバージョンをまたいだりコンフィグが変わっている場合でもリストアができ
る
というかバージョンアップの手順の一つとして後悔されていたりもする(ex. 5.5
からmysqldump + 5.6にそれをリストア)
MySQL :: MySQL 5.6 リファレンスマニュアル :: 2.11.1.3 MySQL 5.5 から
5.6 へのアップグレード
‐
mysqldump がその代表格
派生としてパラレルでバックアップを採れる mydumper, mysqlpump
‐
概ねリストアが遅めでファイルサイズが小さい
インデックスやトランザクション管理領域はリストア時に新たに構築される
‐
35/88
44. 向き先を合わせる #とは
マスターではこんな感じ
$ mysqlbinlog mysql-bin.008547 --start-position=70540318 | less
# at 70540318
#180301 16:27:14 server id 57913 end_log_pos 70540383 CRC32 0x24
734a71 GTID [commit=yes]
SET @@SESSION.GTID_NEXT= 'd47cc0b1-6c70-11e7-aeea-70106f4d304c:39
55500836'/*!*/;
..
INSERT INTO t1 VALUES (1, 2, 3, 4, 5)
/*!*/;
43/88
45. 向き先を合わせる #とは
でもスレーブだと全然違うファイル名とポジションに書かれ
ている
$ mysqlbinlog mysql-bin.014800 | less
# at 216401979
#180301 16:27:14 server id 57913 end_log_pos 216402044 CRC32 0xf
8740c26 GTID [commit=yes]
SET @@SESSION.GTID_NEXT= 'd47cc0b1-6c70-11e7-aeea-70106f4d304c:39
55500836'/*!*/;
..
INSERT INTO t1 VALUES (1, 2, 3, 4, 5)
/*!*/;
44/88
47. mysqldumpのマスターとスレーブの打ち分け
gitd_mode= OFFの場合
体感ではマスターで mysqldump --master-data のパターンが多い気
がしますよ
‐
フルバックアップ元 コマンド例 バイナリーログコピー元
マスター mysqldump –master-
data
マスター
マスター x(この組み合わせは不可) スレーブ
スレーブ mysqldump –master-
data
マスター スレーブ(*2)
スレーブ mysqldump –dump-slave
(*1)
スレーブ マスター
(*1) –dump-slave はバックアップ中に STOP SLAVE してしまう
ので注意
(*2) ただし レプリケーションフィルター を使用していないこ
46/88
50. マスターとスレーブのバイナリーログ with GTID
gtid_mode=ON になっている場合、
マスターで更新がコミットされるたびにGlobal
Transaction IDがマスターのバイナリーログに埋め込まれ
スレーブも自分が実行したGTIDをおぼえておくようになる
(バイナリーログまたは mysql.gtid_executed テーブルに記
録)
既に実行済みのGTIDを振られたクエリーを複数回受信した
場合、最初の1回以外はクエリーがスキップされる
つまり、 ポジションを特に気にせずにあるだけ食わせても
二重適用にはならない
49/88
66. ほどほどのフルバックアップ
$ mysqldump --all-databases --single-transaction
--routines --triggers --events
--master-info=2 --hex-blob --quick
gtid_mode= ON の時は --master-data=2 は無くてもいい(あ
っても毒にはならない)
MySQL :: MySQL 5.6 リファレンスマニュアル :: 4.5.4
mysqldump — データベースバックアッププログラム
65/88
67. ほどほどのフルバックアップ
デイリーで mysqldump
--all-databases で全データベースのダンプを指定
--single-transaction (InnoDBのみの場合はこれでOK) ま
たは --lock-all-tables を指定しないとバックアップ中に更
新が走るとデータがズレる
--master-info=2 で mysqldump 実行時の SHOW MASTER
STATUS の値をダンプファイルに記録
スレーブから取る場合( SHOW SLAVE STATUS の Exec_Master_Log_Pos
とかを使いたい場合)は --dump-slave=2
‐
--triggers, --routines, --events を指定しないとトリガ
ー、ストアドルーチン、ストアドファンクション、イベント
スケジューラーのジョブの内容がバックアップされない
66/88
77. リストア
gtid_mode= OFF でポジションベースで指定する時
最新のデータまで進める場合には最後の --stop-position はつけな
い
‐
$ mysqld --initialize-insecure
$ mysql -uroot < /path/to/mysqldump.sql
$ head -30 /path/to/mysqldump.sql | grep CHANGE
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.008547', MASTER_LO
G_POS=70540318;
$ mysqlbinlog --start-position=70540318 mysql-bin.008547 | mysql
-uroot
$ mysqlbinlog mysql-bin.008548 | mysql -uroot
$ mysqlbinlog mysql-bin.008549 | mysql -uroot
..
$ mysqlbinlog mysql-bin.008999 --stop-position=32764 | mysql -uro
ot
76/88
81. mysqldumpからのリストアトラブルあるある
5.7.18までの mysqldump は mysql.gtid_executed テーブル
をバックアップしてしまってリストア後に不正なGTIDを掴
まされる
5.7.19とそれ以降にアップデートしましょう。 mysqldump のバグな
のでクライアントだけアップデートしてもいいです。
‐
MySQL Bugs: #82848: Restarting a slave after seeding it with
a mysqldump loses it’s position
‐
爆発しろ‐
80/88