- 本日、弊社ではオフラインメンテナンスを行い、データベースサーバのスケールアップを行った次第ですよ。
- んで、色々あったので、
恥をさらしてみる。ハマった事案を共有してみる。
概要
- Master サーバのクラスを m1.small から m1.large に上げる。
- RDBMS は MySQL 5.5 系
- Read Replica は 2 台
- Master の Availability Zone は ap-northeast-1b
- 大人の事情で Multi-AZ にしていない (´･ω･`)
- あ、ちなみに「そもそも m1.small とか NE-YO!!!」ってツッコミは MySQL Casual の時に散々受けてますので、以下その話題禁止ｗ
- ダウンタイムは最大2時間を予定。
- 勿論、夜中 (27:00〜29:00) に実施。
計画
- 普通に AWS Management Console から Modify でクラスを変更するだけの簡単なお仕事。
- 「ダウンタイムはせいぜい10分とかだろ。」
実際
- 世の中、そんなに甘くはないっすね！
- 10分どころか、余裕で1.5時間掛かっちゃいましたよ。ええ。
- まぁ、事前調査・検証が足りてなかったのが諸悪の根源なわけですが。
事象 / 其の壱
ハマったコト
- プルダウンから m1.large を選択して Apply Immediately にチェックして実行！
- Cannot modify the instance class because there are no instances of the requested class available in the current instance's availability zone. Please try your request again at a later time.
- 「………え？」
- どうやら、ap-northeast-1b では m1.large を選択出来ない様子。
- 「マジかよ！！！」
- 詳しい情報は調べ切れていないが、Availability Zone 単位に選択出来るクラスに制限というか上限があるっぽい。
- ちなみに、m1.medium もダメだった。
- 大人の事情的に m1.xlarge とかは試してない。
やったコト
- m1.large として既存の Master サーバの Read Replica を作る。
- 新しい Master 候補のサーバを Promote Read Replica で昇格させる。
- 廃止予定の Master サーバの DB Instance Identifier を変更して避難させる。
- この間、サービスダウン。
- DB Instance Identifier を元々の名前にする。
事象 / 其の弐
ハマったコト
- Read Replica の作成から〜の〜、Promote Read Replica までは普通に進む。
- んで、いざ Promote した Master 候補の状態を見てみると…。
- 「ありゃ？ Read Replica が 1 台も居ない…？」
- まぁ、そりゃ冷静に考えてみたら、Promote したインスタンスは完全に独立した Master サーバになるわけで、既存の Read Replica が付いてきてくれるワケないっすよねー！
- どこまでレプリケーションしたか、とかその辺の情報がズレるわけだから、あたりまえ体操。
やったコト
- 新しく作った Master 候補をベースにした Read Replica を 2 台 (元々の台数分) 作成。
- 既存の DB サーバ群 (3台) の名前を退避。
- 新規の DB サーバ群 (3台) の名前を元々の名前にする。
結果
- 上記二つの「やったコト」のお陰で、どうにかメンテナンスを終了させることが出来た。
- なお、元々ミッションクリティカルなデータ書き込みが存在しないような状態にしてあったので、End Point の名称切り替え中などに大きな問題は起きず。
- いや、「そういう問題じゃないっしょ！」ってお話しなのは重々承知してますよ。ええ。
結論
- 事前の調査と検証はしっかりやりましょう。
- そもそもの考え方として、既存のサーバ群のクラス変更とかは行わずに、新規に同等のサーバ群を作成して、向き先をガツッと切り替える方法を採るのが正解だったかも。
- こういった Ops 系の上手な運用ノウハウとか学ばないとなぁ…。