AWS DMS を使って Aurora MySQL の無停止エンジン更新を試してみた

こんにちは、SaaSプロダクト開発部の滝波です。弊社プロダクト「PLAY VIDEO STORES」のエンジニアを担当しています。

昨年末、AWSから重要な通知が届きました。

Amazon Aurora MySQL は、2024 年 1 月 15 日にバージョン 3.01 と 3.02 (MySQL 8.0.23 互換) を廃止する予定です。
お客様の AP-NORTHEAST-1 リージョンでは前述した Aurora MySQL マイナーバージョンで実行されている Aurora MySQL クラスターが 1 つ以上あるため、3 か月前にお知らせします。

多くの場合、DBエンジンの更新にはインスタンスの再起動が不可欠であり、その間にサービスを停止させる必要があります。
Amazon RDS を利用したアプリケーション開発を行う上で、インスタンスの再起動は避けられない物であり、誰もがサービス無停止で実施する方法を考えると思います。
今回は AWS DMSを活用したサービス無停止でのDB移行によるDBエンジンの更新手順を紹介します。

前提と手順
事前準備
- 移行元のDBの設定
- 移行先のDBの設定
  - インデックス・制約の移行
DMSの設定
レプリケーション状態と遅延を確認する
接続先切り替え
まとめ

前提と手順

さっそく、本題に移りましょう。

サービスの中断を最小限に抑えつつ、最新のエンジンで構築した新しいDBに移行することで、DBエンジンの更新を行います。
今回は AWS DMS を使用して、Amazon Aurora MySQLからAmazon Aurora MySQLへの移行となります。

移行元DB：Amazon Aurora MySQL 3.02.1
移行先DB：Amazon Aurora MySQL 3.05.1
移行ツール：AWS Database Migration Service（DMS）

移行の手順とDMSの全体図は以下の通りです。

移行元Aurora MySQLクラスター（ソース）のbinlogを有効にする
移行先Aurora MySQLクラスター（ターゲット）を構築しておく
DMSで移行元と移行先クラスターをレプリケーションさせる
レプリケーション状態と遅延を確認する
アプリケーションからの接続先を移行先クラスターのエンドポイントに向ける
移行元Aurora MySQLクラスターを縮退する

事前準備

移行元のDBの設定

まずは移行元DBの設定です。
DMSの移行元（ソース）にAurora MySQLを利用する場合は、binlog_formatがROWで設定されている必要があります。
RDSのパラメータグループから、binlog_formatの設定を確認しましょう。
※ binlog_formatがROWになっていない場合は、設定の変更とインスタンスの再起動が必要になります。

docs.aws.amazon.com

移行先のDBの設定

次に移行先（ターゲット）となるDBを準備します。
DBのエンジンバージョンを3.05.1に設定し、初期構築を行います。

インデックス・制約の移行

※ DMSでは外部キー等の制約を自動移行できないので、別途手動での移行が必要になります。

docs.aws.amazon.com

移行元のDBのSchema情報をあらかじめ取得しておき、移行先のDBに移しましょう。

mysqldump --no-data sourceDB > schema.sql
mysql targetDB < schema.sql

移行元DBと移行先DBのインデックス・制約が一致するかを確認します。

-- インデックスの確認
SELECT 
    TABLE_SCHEMA, 
    TABLE_NAME, 
    COLUMN_NAME, 
    INDEX_NAME 
FROM INFORMATION_SCHEMA.STATISTICS 
ORDER BY TABLE_NAME;

-- 制約の確認
SELECT 
    TABLE_NAME,
    COLUMN_NAME,
    CONSTRAINT_NAME,
    REFERENCED_TABLE_NAME,
    REFERENCED_COLUMN_NAME 
FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE 
WHERE REFERENCED_TABLE_NAME IS NOT NULL 
ORDER BY TABLE_NAME;