ToAurora.pdf

第25回 中国地方DB勉強会 in 鳥取（倉吉）LT

Transcript

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. ありがとうございました