2018.12.01 ChugokuDB LT

1. オンプレ MySQL から Aurora への移⾏
（要約版）
@hmatsu47（まつひさ）

2. はじめに
⾃⼰紹介はありません
話す内容＝個⼈の⾒解です
基本的に作業時点で確認した情報です（2017/6 〜 9）
詳細は Qiita にまとめています
https://qiita.com/hmatsu47
https://hmatsu47.hatenablog.com/aurora

3. 今⽇話す内容
移⾏前後の環境
データ移⾏
性能問題
その他の制約（Failover 処理／バグ／未サポート機能）

4. 移⾏前の環境
よくある 1 ラックの構成
VMware vSphere
MySQL 5.5 × 2（メインは 1 台）
データは 1TiB 未満（DB／ファイル）
Webサーバ数台（Java 8／Tomcat 8）

5. 移⾏後の環境
Web サーバは EC2 へ（東京 AZ-a と AZ-c に分散配置）
Aurora は db.r3.2xlarge がメイン（途中で db.r4 へ）
ファイルは S3 へ

6. データ移⾏
DMS は使わず MySQL Replication で複製
お⾏儀の悪いデータ（0000-00-00 00:00:00）の存在
キャラクタセット︓UTF8MB4 ⾮サポート
タイムゾーン不⼀致問題（オンプレ側設定もれ）
「SYSTEM」が指す時刻︓JST(オンプレ)／UTC(Aurora)
対応策︓オンプレ側で明⽰的に JST(Asia/Tokyo) を設定
バグも踏む（後述）

7. 性能問題
Connection Pooling の性能問題が発⽣
ピーク時クエリ数を捌けない
AZ 内のネットワークレイテンシの影響
オンプレ⽐ 1.5 〜 2 倍のレイテンシ（移⾏当時）
その後幾分改善（AWS の性能向上）
AZ 間のネットワークレイテンシの影響
ms オーダーなので、DB データ書き込み時に必要な数の
ACK が返るまでの時間がどうしても⻑くなる
改善策 1︓Java GC 時間の調整
改善策 2︓Connection Pooling ⼊れ替え︓DBCP2 → HikariCP
ほかにバッチ処理の実⾏時間の延⻑問題も

8. その他の制約／Failover 処理
Aurora Failover で Writer 向けの Connection が Reader に接続
してしまう
通常は MariaDB Connector/J で Failover 対応する
MySQL Connector/J と挙動が違うので断念
Connecion Validation ⽤のストアドを作成して対応
Reader に接続したらエラー→ Connection Pooling 側で再
接続するように

9. その他の制約／バグと未サポート機能
バグ︓MySQL 5.6.10／MySQL 5.7.12 より後に Fix されたバグ
のうち AWS が対処せず残したもの
例︓レプリケーションフィルタが使⽤されていると
LAST_INSERT_ID が不正にレプリケートされる (バグ
#69861)
バージョン 1.17 で Fix (2018/3/13)
未サポート機能︓MySQL 5.6.10／MySQL 5.7.12 より後に実装
された機能の⼤半
例 1︓RANDOM_BYTES()／MySQL 5.6.17 でサポート
例 2︓MySQL 8.0 で実装された JSON 関数のバックポート
／MySQL 5.7.22 でサポート

10. まとめ
Aurora 固有の問題というより AWS 環境（複数 AZ による冗⻑
化）にフィットさせるのに苦労した（レイテンシ問題）
Aurora 固有の問題は、MySQL で Fix or 追加実装された機能の
取り込みが追い付いていない点への対処がメインだった
「MySQL 5.x 互換」といってもベースのバージョンが
5.6.10 / 5.7.12 であることに注意（これ重要︕）

11. ありがとうございました