アジェンダ
- ゴール
- 課題
- 新旧同期Replicatorとは
- 新旧同期Replicator移行の流れ
ゴール
新環境旧環境で同期させる
課題
- データ構造が異なるDBへ移行する
- 全然違うデータ構造だった
- 停止は避けたい
- いろんなメンテが走っているから
切り替えタイミングを任意としたい
- 各プロジェクトが最適なタイミングで
プラットフォームの見せ所
実現に何が必要か
機能要件
- 双方向レプリ
- スキーマのマッピング
- リレーログの永続性
非機能要件
- 低レイテンシー
設計
- 2つのマスターがあって、レプリケーターが2つ
- RabbitMQのキューを配置(binlogの永続化)
マッピング情報はymlで
- いろいろできるyml
- insert/update
- green
mysql replicator
- rabitmq adapter
- query mapper
query executor
SQL Parser/Source Query/Destination Query
- 性能実績 4000req/secが限界
- 更新クエリ99%を15msで同期
同期の流れ
- 同期できる状態で新APIの提供
- 1処理で大量のcommitする場合はズレに注意する事
- 最終的に整合性あえばよい
- 循環同期
- 更新者を明示してクエリの更新を止め、循環しないようにする
- 1処理で大量のcommitする場合はズレに注意する事
- データの矛盾確認
- マッピングに従って同期するだけ
- データに矛盾がないか分からない
- codeception(PHP)でテストを生成
- vert.x