CA MOBILE TECH BLOG

株式会社シーエー・モバイルのエンジニア・デザイナーの活動を綴るブログです

株式会社シーエー・モバイルの技術広報による、
技術に特化したブログです。
エンジニアとデザイナーの活動や思想を綴ってゆきます。

【 AWS移管物語-上- 】MySQl 5.1 から AWS Auroraへ(にわっちのインフラ奮闘記vol6)

f:id:cam-engineer:20180214172735p:plain

サービス移管プロジェクトでDBを担当しました、にわっちです。

ここ一年くらいは変化、変化、適応、変化の日々を過ごしていましたε≡≡ヘ( ´Д`)ノ

 

さっそくですが、 MySQl 5.1系からAWS Auroraに移管した話です。

ミッション

2ヶ月間で他社DCにあるMySQl 5.1系のデータを損失なくAWS Auroraに移管

手段

他社DCがAWS Direct Connectを引いた実績があったため、AWS Direct Connectを敷設。

Direct Connectの経路で多段レプリケーションを組む

f:id:niwattitti:20180214154958p:plain

構築

mysql 5.1 → MySQL 5.5 (EC2)

  • public のサブネットにMySQL 5.5を構築
  • dump を取って入れ込む
  • CHANGE MASTER TOコマンドを利用して レプリケーション構築

mysql 5.5 (EC2) → MySQL 5.6 (RDS)

  • public のサブネットにMySQL 5.6 (RDS)を構築
  • dump を取って入れ込む
  • CALL mysql.rds_set_external_masterコマンドを利用してレプリケーション構築

mysql 5.6 (EC2) → Aurora 5.6 (RDS)

  • パラメーターグループの作成
  • GUI上からprivate のサブネットにMySQL 5.6 (RDS)リードレプリカの作成

事前作業

  • 各インスタンス構築
  • ECインスタンスのスナップショット取得
  • 関連DNSの設定をttl短めに
  • 接続ユーザー作成

メンテナンス作業

  • 復旧しやすいようにレプリケーションで利用しているサーバー以外の3306 portをiptablesで停止
  • レプリケーションの停止
  • 各インスタンスのポジションの確認
  • 事前に作成しておいたテーブルに完了レコードをINSERT
  • end to end (MySQL 5.1 Master とAurora)でスクリプトを作成、実行し、文字コードやテーブルの行数、テーブル数等を確認
  • GUIコンソールからリードレプリカのAuroraを昇格
  • 移管元からDNSの変更
  • ansibleで既存サーバーから接続テスト

詰まったところ

  • mysql 5.5 (EC2) → MySQL 5.6 (RDS)のレプリケーション

    → old_passwordsが有効だと Last_IO_Errno: 2049がでる。old_passwordsを無効にして再度ユーザー作成

    → レプリケーション設定コマンドが異なる

  CALL mysql.rds_set_external_master('host', 3306, 'replication', 'パスワード', 'ip.000613', 21099097, 0);

  hostはIPで指定 名前解決できないので下記のように指定してはいけない

  ip-xxxxxxx.ap-northeast-1.compute.internal


  • Direct Connectを引いたことによる、ルートテーブルの変更

    → 行き(インターネット)と戻り(Direct Connect)の経路がことなるため、メンテンス時一部サービスがアクセス不能になった

    → VPCのサブネットの設定で特定のIPを指定してnat gatewayを向けることで解決


  • パラメータグループを複製して dynamic でないパラメータを値を変更し再起動したところ、5sのレプリ遅延

    • リードレプリカをもう一台遅延が発生しているauroraと同じAZに作成
    • 遅延が発生しているauroraを削除で解決

    サポートには、原因解明のため遅延状態のauroraを残しておくか、削除するかを迫られるw


  • ダイレクトコネクト以外の移管方法の考案と検証

    • 他社DCにmysql proxy サーバーの構築と利用

      → private サブネットにauroraを立てるためnginx等をパブリックサブネットに立てる必要あり

      → 暗号化する必要あり

    • 他社DCインスタンスとEC2インスタンス間でSSH トンネルを用いたレプリケーション

      → データの損失の可能性あり

    • dmsの検証

      → auto incrementがなくなる等の制約あり docs.aws.amazon.com

    • Xtrabackupの利用

      auroraの対象バージョンが 5.6.22くらいまでで、最新バージョンや5.6.29あたりだとリストア・auroraの作成ができなかった


  • EC2 スナップショット取得後に、インスタンスタイプを変更した後のインスタンスへの接続不良

    → ボリュームをディタッチして、新規にインスタンスを作成してアタッチ

auroraで障害や不具合等、何か起きたときに必要な情報

  • SHOW PROCESSLIST
  • エラーログ、もしあればスロークエリログ
  • 正常時と事象発生時の SHOW ENGINE INNODB STATUS\G の結果
  • information_schema の innodb_trx, innodb_locks, innodb_lock_waits 等の情報
  • (オプション)拡張モニタリングの有効化

※再起動したり、インスタンスタイプを変更したりすると上記のデータの一部は消失します。

S3に定期的に保存する等の処置をすると原因解明へつながります

おわりに

今回は初めてのことが多く、短期間というのもあり、 記載した他にもバックアップの設定やパラメーターグループの設定、フェイルオーバー、復元等の 検証も含め不安な部分もありました。

一つずつ検証を重ね、進めながらもよりよい方法を常に模索し、 粘り強く取り組んだことで無事完了することができました。

身近に関わってくださり、アドバイスをくださった皆様、 本当にありがとうございました(´ω`)

より精進して技術力を高めるよう尽力します(`・ω・´)ゞ