メニューを閉じる

テクノモバイルグループ

メニューを開く

2021.01.28

DB

【AWS】RDSの多段レプリケーションによるUpgrade実施

JTです。
AWSの(RDS)MySQL5.5→5.7への強制Upgrade予告に対応するため、リードレプリカによる多段レプリケーションを組んだところ、シーケンシャルに行うと4時間弱のサービス停止が20分程度に抑えられたので手順を残しておきます。

AWS公式の案内は以下を参照のこと
Amazon RDS for MySQLでMySQLエンジンバージョンを5.5から5.7へアップグレードする方法

【概要】

2020年の秋、AWSから以下の様なメールが届いた

Amazon RDS for MySQL 5.5 は、UTC 協定世界時間の 2021 年 2 月 9 日 00:00:01 (JST 日本標準時間の 2021 年 2 月 9 日(火) 09:00:01) に廃止されます。
(中略)
2021 年 2 月 9 日までにデータベースをアップグレードしていない場合、RDS は、2021 年 2 月 9 日 00:00:01 UTC (2021 年 2 月 9 日 09:00:01 JST) から 2021 年 3 月 9 日 00:00:01 UTC (2021 年 3 月 9 日 09:00:01 JST) の間に、スケジュールされたメンテナンスウィンドウ内で MySQL 5.5 のデータベースをバージョン 5.7 にアップグレードします。2021 年 3 月 9 日 00:00:01 UTC (2021 年 3 月 9 日 09:00:01 JST) の時点で、残りのすべての Amazon RDS for MySQL 5.5 インスタンスは、メンテナンスウィンドウ中であるかどうかに問わず、バージョン 5.7 にアップグレードされます。

 

検証環境を作成してMySQL5.7での動作に問題がないことは確認できたが、Upgrade作業の間のサービス断をできるだけ短くしたい。

 

【初期測定】

AWSを利用し始めた最初期の頃のサービス群が対象となるが、運用期間も長くデータも大量で、試しにシーケンシャルにUpgradeを実行したところ(MySQLは一気に5.5→5.7とは出来ず、5.5→5.6、5.6→5.7と1段階ずつUpgradeが必要だった)、本番RDSをクローンした環境で

MySQL5.5→5.6で3時間
MySQL5.6→5.7で30分

かかった。

【解決策】

4時間弱のサービス停止は厳しいな……と思っていたところ、最初に記載した素敵な手順書が。
Amazon RDS for MySQLでMySQLエンジンバージョンを5.5から5.7へアップグレードする方法

RDSのリードレプリカを用いて、

MySQL5.5(親)→MySQL5.6(子)→MySQL5.7(孫)

の様な多段レプリケーションを構成し、レプリケーションが出来たらメンテインして親の更新を止め、孫をマスタに昇格する、といった内容。この手順を使った結果、サービス停止は20分でUpgradeが完了した。(あまり焦ると親→孫間のレプリケーションラグがありうるので確認は慎重に!)

 

【多段レプリケーション作成】

[準備]
1)親(hoge-db)のリードレプリカ(子リードレプリカ:hoge-rr)を作成
2)子リードレプリカ(hoge-db-rr)が作成できたら、そのリードレプリカをUpgradeする(MySQL5.5→5.6)
3)子リードレプリカ(hoge-db-rr)がUpgradeできたら、hoge-db-rrに対してさらにリードレプリカ(孫リードレプリカ:hoge-db-rr-rr)を作成する
4)孫リードレプリカ:hoge-db-rr-rrが作成できたら、そのリードレプリカをUpgradeする(MySQL5.6→5.7)

【3世代イメージ】

世代
DB名 hoge-db hoge-db-rr hoge-db-rr-rr
エンジンバージョン 5.5.57 5.5.57→5.6.49 5.6.49→5.7.31
サイズ db.t3.medium db.t3.medium db.t3.medium
ストレージ SSD300GiB SSD300GiB SSD300GiB
Multi-AZ あり なし ★あり
オプショングループ default:mysql-5-5 og-hoge-db-mysql5-6 og-hoge-db-mysql5-7
パラメータグループ pg-hoge-db-mysql5-5 pg-hoge-db-mysql5-6 pg-hoge-db-mysql5-7
バックアップ保持期間 なし ★5.6にUpgrade後「1日間」に変更 1日間

※備考の★印が今回ハマったところ。
– 親がMulti-AZの場合は孫のRRをMulti-AZにしておくことで昇格後のMulti-AZ構成変換しないですむようにする
– 参考にした手順では「 ※ リードレプリカインスタンスを作成するためには、自動バックアップを有効化する必要有り」とありましたが、より具体的には子のバックアップ保持期間を1日以上にして有効にすることで孫RRが作成可能でした。
参考になれば。

【作業ログ】

1)サービスメンテイン

– ALB等でWebUIの流入停止
– cronバッチ、サービス等DBのupsertがあるものを停止

2)マスタRDSのリネーム

hoge-db→hoge-db-org
[すぐに適用]
→エンドポイント名が変わるので、サービスはDBに接続できなくなるが、JavaなどDNSキャッシュするものもあるため以下の手順でプロセスの停止とレプリケーション状態を確認する

3)レプリケーション状態確認

※ここで焦らずレプリケーション漏れがないことを確認する。
■親

■子

■孫

4)孫RR昇格

[アクション]-昇格
設定はデフォルトのままで昇格を実施

5)孫RRリネーム

hoge-db-rr-rr→hoge-db
[すぐに適用]

6)メンテアウト

7)MySQLクライアントのUpgrade

必要に応じてMySQLクライアントをUpgradeしておいてください
(クライアントが5.5のままだとMySQLDumpができなくなる)

【感想】

今後MySQL5.6も強制Upgrade対象となる可能性大なので、RRを使ったUpgradeをやっていきたいですね!


【テクノモバイルではエンジニア/デザイナーを積極採用中です!】

下記項目に1つでも当てはまる方は是非、詳細ページへ!
  • 自分でアプリを作ってみたい
  • ITで世の中にワクワクを生み出したい
  • 使いやすさ、デザインにこだわったWebサイトを開発したい

採用情報の詳細はこちら


Qangaroo(カンガルー)

  • 徹底した見やすさと優れた操作性で、テストの「見える化」を実現。
  • テストの進捗が見える。開発がスマートに進む。
  • クラウド型テスト管理ツール『Qangaroo(カンガルー)』
https://qangaroo.jp/

最近の記事

SNS共有

X CLOSE
X CLOSE
X CLOSE