はじめに
最近 Amazon RDS Blue/Green Deployments なるものがリリースされました。今回は実際に Blue/Green のスイッチオーバーまでやってみました。
検証準備
- Aurora MySQL クラスターの準備。最初 MySQL8.0系を選択しましたが、こちらは対応しておりませんでした。ちゃんとドキュメント読んでからやりましょう。今回は MySQL5.7系で起動しておきます。
- パラメータグループを編集して、バイナリログを有効化します。(binlog_format → MIXED)
検証開始
クラスターを選択し、「アクション」から「ブルー/グリーンデプロイの作成」をクリックする。
ブルー/グリーンデプロイの作成画面にて、「Blue-Green 環境識別子」を入力する。今回は推奨とあるので、MySQL8.0系へのスイッチオーバーを実施してみる。(失敗フラグ)
「Green DB インスタンスの月額料金の見積もり」も出してくれるのでとても安心できますね。内容に問題が無ければ、「ステージング環境の作成」をクリックします。
しばらくして、「Blue-Green 環境の作成に失敗しました」とエラーが表示されました。
エラーステータスでロールが「ブルー/グリーンデプロイ」となっているリソースを選択し、「ログとイベント」で確認してみると、今回ブルー環境で指定した t3.small は MySQL8.0系インスタンスがサポートしていないタイプなので起動できていない事がわかりました。(じゃあ、推奨で。と突き進み、無事フラグ回収)
ちなみに、起動している様に見えるグリーン環境は MySQL5.7系で起動されていました。笑
一旦「ブルー/グリーンデプロイ」ロールを削除し、ブルー環境と同バージョンで再挑戦。
次はうまく行ったようです。特にエラー無くグリーン環境が作成されたました。
グリーン環境のクラスターに MySQL クライアントで接続してみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 |
MySQL > show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 172.23.15.0 Master_User: rdsrepladmin Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin-changelog.000004 Read_Master_Log_Pos: 154 Relay_Log_File: relaylog.000004 Relay_Log_Pos: 273 Relay_Master_Log_File: mysql-bin-changelog.000004 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: mysql.rds_replication_status,mysql.rds_monitor,mysql.rds_sysinfo,mysql.rds_configuration,mysql.rds_history Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 154 Relay_Log_Space: 592 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1770043869 Master_UUID: dd0bf094-bc87-3287-81fe-6c29fcc3c712 Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.02 sec) MySQL > |
やはり、普通に MySQL レプリケーションが設定されていました。正常にレプリケーションができている事がわかったので、「アクション」から「切り替え」をクリックします。
切り替えの概要、レプリカ設定の詳細を確認します。タイムアウトの設定は、切り替えにかかる制限時間を指定できます。この時間をすぎるとスイッチオーバーはされません。では、切り替えをクリックします。
スイッチオーバーが完了すると、下記のよう状態になります。database-1 が database-1-old1 に名前変更され、staging-database-1 が database-1 に名前変更されるイメージでしょうか。これを手動でやると名前変更時にインスタンス再起動が走るので、そのあたりはブルー/グリーン両方で一時的に書き込みをロックし、データの整合性を保った上で名前変更処理をマネージドサービス内でうまいことやってくれてる感じなんですかね。
まとめ
今までは、スナップショットから別のクラスターを起動させ、ポジションをログから取得して手動で MySQL レプリケーションを設定する場面などありましたが、そのあたりが完全にマネージドサービス化された印象です。他にもマネージドサービスならではの機能がありますが、今回の検証はここまでにします。
今後、バージョンアップ対応やメンテナンス対応がスムーズに行える良い機能ですね。是非活用して行きたいです。
投稿者プロフィール
-
AWS認定12冠
趣味 : スプラトゥーン
最新の投稿
- AWS2024年1月9日Amazon S3 Express One Zone を使ってみた
- マイグレーション2024年1月9日AWS Migration Hub を使ってみた
- AWS2024年1月9日AWS Application Discovery Service (ADS) を使ってみた
- AWS2023年7月5日AWS DMS Serverless を使ってみた