AWS の RDS Classic から VPC内の RDS へのレプリケーションについて

3824 ワード
MySQL Aurora AWS MySQL テキストリンク

今年の前半、AWSのClassic環境に構築されたシステムをVPC環境に移行するという作業を担当した。
数年前にも同様にClassic環境のものをVPC環境に移行することを実施した手前、まぁ、どうとでもなるでしょうと作業に着手した。
表題の通り、ClassicのRDSからVPCのRDSへのオレオレレプリカの構築について記載する。
(ただし、数年前の記憶をもとに記載しており、正しく無い場合があるかもなので、オチのほうの利用をオススメしる)

なぜClassic環境からVPC環境へのオレオレレプリカの構築の必要性に迫られたかと言えば、なるべくダウンタイムは少なくして移行する必要性があったためである。
ということなので、

メンテナンスin → DBバックアップ → VPC環境に設置 → 疎通テスト

ではなく

オレオレレプリカでレプリケーション → メンテナンスin → オレオレレプリカの昇格 → 疎通テスト

を採用した。

オレオレレプリカを作成する手順

※privateサブネット内に設置されるRDSインスタンスからのレプリケーションを想定

  1. 本番のRDSにレプリケーション位置を取得する用のレプリカを追加
  2. Classic側のMASTERと作成したレプリカのbinlog保存期間を適当な時間にセットして保存するように設定
  3. 作成したレプリカのレプリケーションを手動停止
  4. レプリケーションを停止した位置を取得(show slave status\G コマンドで表示される Read_Master_Log_Pos と Master_Log_File の値を控える)
  5. レプリケーションを止めたレプリカからVPC内に起動する用のスナップショットを作成
  6. 移行するVPC内に上記で作成したスナップショットからRDSのインスタンスを生成
  7. オレオレレプリカを設置するVPCのnatゲートウェイに設定したElastic IPを控える
  8. (Classic環境のため、RDS専用のセキュリティグループを設定)VPC内のprivateサブネットにあるRDSインスタンスからレプリケーションするため、CIDR/IPの設定で上記で控えたElastic IPを指定した穴を作成(たぶんこれで疎通したはず)
  9. Classic環境のRDSのエンドポイントをdigコマンドあたりで掘ってhostを取得
  10. VPC側のインスタンスからClassic側のMASTERをレプリケーションのMASTERとして指定する (CALL mysql.rds_set_external_master(‘masterのホスト名', 3306, ‘レプリケーションユーザー名', 'レプリケーションユーザーパスワード', ‘上記で取得したMaster_LogFileのバイナリログファイル名', 上記で取得したRead_Master_Log_Posのpositionの値, 0);)
  11. コマンドが通り、SLAVEとして設定され、Seconds_Behind_Masterが追いついたらレプリケーション完了

・・・・いろんな状況の設定やレプリカの準備等、事前準備が多数必要だ・・・_(´ཀ`」 ∠)_
まぁ、面倒ではあるけど、実際に作業しよう。

んん？( ﾟдﾟ)

(つд⊂)ｺﾞｼｺﾞｼ

（；ﾟДﾟ） なん・・・だと・・・！？

ざわ・・・ざわ・・・
AuroraはVPC環境でしか利用できないし、ClassicのRDSインスタンスのアクションの選択肢としてこいつがあるのはどういうことだ・・・
　 　 　ざわ・・・ざわ・・・

まさか・・・マネージドのサービスでClassicのRDSのAuroraのレプリカをVPC内に投入できるというのか！？


。　　　　　　　 ＊
　☆ ☆　°　。☆ ☆ 。
☆　　 ☆　　☆　　 ☆
☆　　　∧☆∧　　　 ☆
｡☆　　 (´･ω･)　　 ☆
　☆　　| 二⊃==○☆
　＊☆　|　 |　　　　＊
　。　☆(ノＵ　 。
　　　　☆　 ※
　　　　　☆　　°

できた。
普通に本番のDBを選択し、ダウンタイムも無くVPC内にAuroraレプリカを作成することができた。

時間を置くと
Seconds_Behind_Masterが「0」になり、
ちゃんと追いついていることも確認できた。

ついでにこの手順で作成したAuroraレプリカをAWSのコンソール上からSLAVEからMASTERに普通に昇格できた・・・

　
ふおぉぉぉおおぉぉおぉぉ
こんな便利機能3年前には無かったはずだぞ・・・_(:3」∠)_
Amazonさんこういう機能はもっと早く作ってくれぃーヾ(:3ﾉｼヾ)ﾉｼ
あんな面倒な思いをしてオレオレレプリカを作った私の苦労はいったい＼(^o^)／

閑話休題

結局、今回のVPCへの移行にあたっては、

移行当日の朝に本番DBからAuroraレプリカの作成
↓
追いつくまで少し置く
↓
メンテナンスin
↓
レプリケーションの停止
↓
AWSコンソールからMASTERへの昇格
↓
疎通テスト

という一番問題であったろう箇所がとてもすんなり行くといううれしい誤算だった。
まぁ、他の部分がブラックボックス過ぎて、paravirtualのAMIを強引にhvmにしてClassicのインスタンスをVPC内に持ち運んだり、テスト環境がClassicに取り残されたりと、美しい移行とまではいかなかったが良しとしておく。

結論

ClassicからのVPCへのDB移行はマネージドのAuroraレプリカを使いませう＼(^o^)／

当時参考にさせてもらった記事