こんにちは。テクニカルサポート課の森本です。
今回の記事では、DMS タスクのソースデータベースに使用しているデータベースを、RDS Blue/Green Deployments を使用してアップグレードできるかという問い合わせを受けた際に検証した内容をまとめます。
DMS 使用時のDBインスタンスのアップグレード可否について
まず前提として、DMS タスクを実行している場合、アップグレード前にタスクを停止する必要があります。 またアップグレード完了後、停止したタスクは再起動ではなく再開する必要があります。 こちらの説明は既存のDBインスタンスのインプレースアップグレードを示しています。
If you want to upgrade your source or target databases, then stop any AWS DMS tasks that are running on these databases. Resume your tasks after your upgrades are complete.
Restart or resume an AWS DMS task in the failed status | AWS re:Post
RDS Blue/Green Deployments とは
本番環境(Blue環境)の非同期レプリケーション環境(Green環境)を作成し、本番環境を運用しながら別環境の検証ができる、またある時点で切り替えを行うことにより旧データベースから新データベースへの切り替えのダウンタイムを極力短縮することができる機能です。
旧データベースと新データベースで異なるデータベースエンジンバージョンや設定を使用することができるため、それらの変更を本番環境に適用する前に検証する用途などに有効です。
You can make changes to the Aurora DB cluster in the green environment without affecting production workloads. For example, you can upgrade the major or minor DB engine version or change database parameters in the staging environment. You can thoroughly test changes in the green environment. When ready, you can switch over the environments to transition the green environment to be the new production environment. The switchover typically takes under a minute with no data loss and no need for application changes.
Overview of Amazon Aurora Blue/Green Deployments - Amazon Aurora
今回の場合、ソースデータベースのメジャーバージョンアップグレード時のダウンタイムを最小化したいというご要望があり、検証を行ってみました。
今回の構成
今回は、DMS のソースデータベースを Aurora MySQL 5.7 から Aurora MySQL 8.0 にアップグレードを行います。以下の構成のとおり、既存のソースデータベースに対して Blue/Green Deployment 環境を作成し、最終的にはソースデータベースを Green 環境へ切り替えます。
手順
- DMS タスク (フルロード + CDC) の環境を作成する
- ソースデータベースにBlue/Green Deployments を作成する
- DMS タスクを停止する
- Blue/Green Deployments のスイッチオーバーを行う
- DMS タスクを再開する
結果
スイッチオーバー後にDMS タスクを再開した際、DMS タスクがソースデータベースから変更ログ(バイナリログ)を読み取ることができなくなり、最終的にタスクが停止しました。
原因
Blue 環境と Green 環境で、バイナリログのファイル名とポジションの整合性が取れていないことが原因でした。
具体的には、DMS ではタスクを停止する際、タスク停止時の Blue環境のバイナリログのファイル名とポジションを記録しますが、Blue 環境と Green 環境で作成されるバイナリログは基本的に別物のため、タスクに記録された内容とGreen環境の整合性が取れず、タスクの再開に失敗している状況でした。
DMS タスク停止時のバイナリログファイルのファイル名とポジション
checkpoint:V1#28#mysql-bin-changelog.000002:3773:-1:3804:8589938180:mysql-bin-changelog.000002:3656#0#0#*#0#105
タスク再開前にBlue環境で確認したもの
mysql> show binary logs; +----------------------------+-----------+ | Log_name | File_size | +----------------------------+-----------+ | mysql-bin-changelog.000001 | 154 | | mysql-bin-changelog.000002 | 3804 | +----------------------------+-----------+ 2 rows in set (0.00 sec) mysql> show binlog events in 'mysql-bin-changelog.000002'; (中略) | mysql-bin-changelog.000002 | 3773 | Xid | 782672328 | 3804 | COMMIT /* xid=38043 */ (中略)
タスク再開前にGreen 環境で確認したもの
mysql> show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 154 | No | | mysql-bin-changelog.000002 | 2124 | No | <- mysql-bin-changelog.000002 の 3804 は存在しない | mysql-bin-changelog.000003 | 154 | No | | mysql-bin-changelog.000004 | 356 | No | | mysql-bin-changelog.000005 | 1104 | No | | mysql-bin-changelog.000006 | 154 | No | | mysql-bin-changelog.000007 | 2947 | No | +----------------------------+-----------+-----------+ 7 rows in set (0.04 sec)
発生したエラーメッセージの例
[SOURCE_CAPTURE ]E: Error 1236 (Client requested source to start replication from position > file size) reading binlog [1020493] (mysql_endpoint_capture.c:1263)
なお、エラーメッセージから推察すると、保存されているポジションがファイルサイズより大きい といったエラーのように見受けられました。
もし仮にこれが Green側のログファイルに存在するポジションであった場合はレプリケーションを再開できた可能性もありますが、それがターゲットに既に適用されている内容との整合性が取れている保証がないため、このまま再開するのはベストプラクティスではないと考えられました。
対策
このような場合に取りうる対策は３つ考えられました。(他にもあるかもしれません)
対策その1
タスクを再開(=Resume)ではなく、再起動(=Reboot)する
メリット
タスクの再起動を行うことにより、特に複雑な設定を行うことなくレプリケーションを再開できる
また、ソースデータベースのダウンタイムが最も少ないことが期待される
デメリット
フルロードからのやり直しとなるため、場合によっては非常に時間やコストがかかる
なお、ターゲットテーブル準備モードが何もしない(= Do nothing)の場合、ターゲットに重複データを作成してしまう可能性があるので事前に確認が必要です。
Restart - When you restart a task, AWS DMS begins replication from the start, and uses the table preparation mode that you chose when you created the task. For example, table preparation modes include Drop table on target, Truncate, and Do nothing.
Restart or resume an AWS DMS task in the failed status | AWS re:Post
対策その2
別途CDC のみのタスクを作成する
CDC 開始時点をGreen 環境のバイナリログのログファイル名とポジションに合わせて実行します。
メリット
再度フルロードを行う必要がない
デメリット
既にターゲットに移行されているデータとの整合性を担保するため、ソース側での書き込みを明示的に一時停止する必要があり、Blue/Green Deployments のメリットと相反することが発生する
なお、既存の フルロード + CDC タスクの CDC 開始点を上書きすることはできないので、新規の CDC のみのタスクを使用します。 また、マネジメントコンソールからは設定できないため、AWS CLI を使用して CDC タスクを作成する、または作成済みのタスクを変更する必要があります。
From a CDC native start point – You can also start from a native point in the source engine's transaction log.
Creating tasks for ongoing replication using AWS DMS - AWS Database Migration Service
対策その3
Blue/Green Deployments を使用せず、インプレースアップグレードを行う
これは元も子もないですが、最もシンプルな方法です。
メリット
既存のタスクを再利用でき、またフルロードを行う必要もない
デメリット
アップグレード時にダウンタイムが発生する
まとめ
DMS の ソースデータベースを Blue/Green Deployments を使用してバージョンアップできるか検証してみました。 アップグレード自体は可能なものの、DMS タスクを継続するためには一筋縄でいかず、様々な対策を取り得ることがわかりました。
この記事がどなたかのお役に立てば幸いです。
