AWS RDS (MySQL) で本番運用している環境のうち、データベース全体でそろそろ 50GB を超えそうな環境があってそのバックアップ、というかテスト環境への転用などをどうしよう、と考えている。
デカめのデータベースの運用経験、 PostgreSQL 8.0.1x あたりまでなら 1TB 近い環境を運用したことあって、 autoVACUUM 実行時の性能劣化とかモロに食らった事あるので環境移行含めて色々知見あるんだけど、 MySQL はそこまで肥大化した環境を運用した経験がなくて、今まさにリアルタイムで悩んでいる。
以下の内容、以前も書かなかったっけ？ と思っているがとりあえず書いたので出しておく。
バックアップ雑感
今は RDS のスナップショット機能でお茶を濁しているのだけど、このままスナップショットから復旧するとすると RDS でしか持ち回れない。
で、いわゆる SQL ベースのダンプファイルか、 /var/lib/mysql/data などの ibd など実ファイル形式でエクスポート・インポートをできるようにしないと、テストに本番相当の環境を持ち回れなくて辛い、という話が出ている。
現代のバックアップ手法
全然知らなかったんだけど、現代では mysqldump は時代遅れで mysqlpump を使ったほうがいいらしい、知らなかった……！
それとは別にで MySQL Shell Instance Dump Utility and Dump Loading Utility など MySQL Shell を使っている環境ならこっちのほうがよさそう、というのもある。
ただこれらは MySQL のトランザクション内に入ってしまうのでロックが発生していわゆる参照できないダウンタイムのようなものが生まれてしまう可能性があり、大きいテーブルを含むデータベース全体を定期的に取得したい、という用途では向いていない気がする。
XtraBackup
ということで、結局みんなお世話になっている Percona の XtraBackup が良い気がする。
何が良いかって、冒頭に書いた通り AWS RDS で動いている環境をバックアップしたい、オンラインで、無停止で！ というわがまま放題の要件なので、これで S3 にストリームできるのであれば、用途を限定する (ここから本番用に復旧する、とかなると一貫性を担保できないので) なら物理バックアップなので、環境を問わないのが強い、という向きだ。
ただ暗号化もクソもないのが物理バックアップなので、取り扱いなどは注意する必要がある (個人情報や名寄せに使えるテーブルを排除するなど、事前検討が必要そう)。
CLONE PLUGIN
ドキュメント読んだだけで実際に使ってないのでなんとも言えないけど、
クローニング操作を監視するために、「パフォーマンススキーマ」テーブルおよびインストゥルメンテーションが用意されています。 セクション5.6.7.9「クローニング操作の監視」を参照してください。
などの記述があるので、MySQL のトランザクションで処理される？ という疑惑があって、物理バックアップだけどロックが発生するのでは？ みたいな疑惑がある。 使う前に実際に調査が必要。 ただ暗号化とか色々 MySQL のことを慮った実装っぽいので、許されるならこれを使ったほうが安定していそうな話ではある。
オチ
調査だけで実際に試していないのが本当に良くないので、時間をとって試す、という所信表明みたいになっている。
が、基本的に CyberAgent の記事にかかれている通り、論理バックアップは MySQL Shell Instance Dump Utility and Dump Loading Utility (次善で mysqlpump)、物理バックアップなら Percona XtraBackup と考えておいてよさそう。
XtraBackup の INSTANT 機能を使っているとコケる、という点は以下に解説が書いてあった。
なので、MySQL 8.0.29以上かつ SELECT NAME FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE TOTAL_ROW_VERSIONS > 0 でマッチする行があるとエラるようになっている(MySQL 8.0.28とそれ以前にはそもそも total_row_versions カラムがない)
とのことなので、 SELECT NAME FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE TOTAL_ROW_VERSIONS > 0 してみるなど事前対策をあつくする方向で。
現代の XtraBackup とかでは治ってるのかはあとで調べる。
オチ２
そもそもパフォーマンス劣化する原因の特定クソデカテーブル (ユーザーヒストリーなどを記録している) だけ取得すればいいので、まあここまで悩まなくてもいいのかもしれない、と書いていて楽観的になってきた。 ガハハ！
おまけ：復元
XtraBackup からの復元、S3にデータ保存していればそこからできるよ、と AWS 公式ドキュメントがこれまた読みづらいけど後悔されている。
いやマジで読みづらいな AWS 公式、この企業規模に対してこのドキュメントかぁ……という気持ちは結構ある。
