この記事では、Percona LIVE 2019 1日目に行われたセッションの後編として午後の最後に行われた2セッションを取り上げます。
MySQL Backup and Restore at Facebook scale
Facebook社の Berjak 氏による、Facebookが自社のデータベースに対して行っているバックアップ＆リストア戦略に関するセッションです。この規模の企業が実際のノウハウについてオープンにすることは非常に貴重なので、参加してよかったです。以下、セッションの内容をまとめます。
- バックアップが必要となるタイミングは「3つ」ある
- 悪意のある攻撃（クラッキング）
- ハードウェア障害
- ヒューマンエラー（操作ミス）
- 論理バックアップと物理バックアップの比較
| 論理バックアップ | 物理バックアップ | |
|---|---|---|
| ビジネスロジック | Easy | Complex |
| デバッグ | Easy | Complex |
| 単一テーブルのリストア | Easy | Complex |
| ポータビリティ | Consistent | Inconsistent |
| リストアにかかる時間 | Long | Short |
- 毎日、全データベース（全テーブル）の論理バックアップを取得している
- Facebook ではバックアップツールとして mysqldump を使用しているが、いくつかカスタマイズされている
→ GitHubで公開されている - インデックスは独自の “trailing index” を使用している
- mysqldumpによる全体バックアップと合わせて、差分バックアップ（”DIFFS”と呼称）も取得している
→ 最新のdumpファイルとその直前のdumpファイルを、テーブルの行数を比較して差分を見つける - DIFFSは DiffDatabase というプロシージャで取得する
- base dump と DIFFS をマージすることで、完全な dump ファイルを生成する
- dumpファイルを効率的に圧縮するために、zstdを開発した
- バックアップコマンドの流れは「mysqldump –single-transaction –skip-lock | compress & add index | upload」となる
- バイナリログには、全データベースに対する全トランザクションが記録されている
→ バイナリログも保存対象（zstdで圧縮）
→ メタデータ（GTID）のズレを監視する - 「バックアップ時のログ」も監視している
- リストアは以下のようなステップで実施
SELECT → DOWNLOAD → LOAD → VERIFY → REPLAY → CHECKSUM
From MySQL to TiDB and back again
元OracleのProduct Managerである Morgan Tocker 氏によるセッションです。同氏は現在、HTAP向けDBとして注目を集める「TiDB」を開発する PingCAP社に所属しています。
まず、HTAP（エイチタップ）とは「Hybrid Transaction／Analytical Processing」の略称で、トランザクション処理（OLTP）と分析処理（OLAP, DWH）を統合的に行うシステムのことを指します。データベースでは、IBMのDb2やSAPのHANAなどが有名だと思います。
このHTAPをMySQL互換で実現できるのが TiDB です。これまで商用DBの独壇場に見えた領域にオープンソースDBとして切り込む姿が注目を集めています。本セッションの趣旨は、そんなTiDBに興味を持ったMySQLユーザが、試しに移行をしようとした時の手順をデモ形式で解説することでした。
また、この時に強調していたのは「簡単に切り戻し（ここではTiDB→MySQL）できることは、リスクの最小化として重要」という点です。これは、TiDBに限らずあらゆる移行案件で重要なことだと思いました。
まず最初のステップとして、「TiDB → TiDB binlog → MySQL」という環境を作ります。
この時の手順は、公式ページのチュートリアルが最も分かりやすいそうです。今後、dbdeployerにも対応したいと言っていたので、期待大ですね（シングルノードであれば既に対応されているようです）。
上記の TiDB binlog はその名の通り、MySQLのバイナリログと似たようなもので 、TiDBの更新をそのままMySQLに流すことができます。そうすることで、TiDBで何か問題があった場合にMySQLに簡単に切り戻しができます。ちなみに、kafka などでも代用できるようです。
次のステップは、構築したTiDBの上に「MySQL → DM（syncer+mydumper） → TiDB」という環境を作ります。ちなみに、実際に本番環境から移行するケースでは間にスレーブを挟み「本番MySQLマスタ → 中継用MySQL → DM …」とするのが推奨されるそうです。
上記の”DM”とは、PingCAPが提供しているデータマイグレーションツールのことです。詳細はGitHubを参照してください。内部的には、mydumperが使用されており、これを使うことでMySQL→TiDBを繋げること（レプリケーション）ができます。
注意点としては、TiDBは「MySQL5.7」互換であり、MySQL5.6および8.0との接続についてはサポートしていない（テストしていない）らしいです。
以上の手順でMySQL→TiDB→MySQLという環境で出来上がったら、重要な作業が残っています。それは「テスト」です。具体的には、一番上のMySQLに対して任意のデータをLOADした時に、「先頭」のMySQLと「末尾」のMySQLの間でデータのチェックサムが一致しているか確認することです。これがもし一致しない場合、TiDBを挟むことでデータ整合性が崩れていることになり、移行は現実的ではないでしょう。
このテストに使用するツールとしては、pt-upgradeが紹介されていましたが、聴衆から「それでは上手くいかないのでは？」という指摘もあり、方法については少々検討が必要かもしれません。
→ ちなみにこの時はルーム全体から意見が飛び交い、熱い議論が展開されていました
本セッションは、MySQLに対して深い知見を持つMorgan氏の立場を活かした内容だったと思います。私個人としても TiDB について殆ど知らない状態で参加しましたが、MySQLの要素が強いこともあって、理解しやすかったです。
次世代のOSSDBとしてTiDB自体にもかなり興味が湧いたので、今後空いた時間に検証して弊社ブログなどでも取り上げていきたいと思います。
