by shigemk2

当面は技術的なことしか書かない

memo 2000万アカウントの無停止データ移行の裏側 #datamigrationnight

アジェンダ

  1. ゴール
  2. 課題
  3. 新旧同期Replicatorとは
  4. 新旧同期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する場合はズレに注意する事
      • 最終的に整合性あえばよい
    • 循環同期
      • 更新者を明示してクエリの更新を止め、循環しないようにする
  • データの矛盾確認
    • マッピングに従って同期するだけ
    • データに矛盾がないか分からない
    • codeception(PHP)でテストを生成
  • vert.x