---

構成

今回の構成図は以下となります。

移行方法の概要

今回の移行では、同一バージョンのMySQL間で移行を行います。

• Amazon RDS for MySQL：MySQL 8.0.41
• Oracle MySQL HeatWave：MySQL 8.0.41

移行の流れは以下の通りです。

1. MySQL ShellのcopyInstanceユーティリティ機能を使用し、Amazon RDS for MySQL上のデータをOracle MySQL HeatWaveにエクスポートします。
2. エクスポート中にAmazon RDS for MySQL側で発生した更新内容をOracle MySQL HeatWaveのレプリケーション機能を用いてOracle MySQL HeatWave側に反映させます。

本移行では、MySQL Shellを実行するためのEC2を踏み台（実行環境）として利用しています。

MySQL Shellのバージョンは8.4を使用しています。

※本記事では、VPC・EC2・RDS・VCN・VPN接続・HeatWaveの構築手順については割愛しています。
　

データ移行とレプリケーションの構成

Amazon RDS for MySQL側でバイナリログの設定確認

Amazon RDS for MySQLからOracle MySQL HeatWaveへ移行を行います。

はじめに、下記コマンドでAmazon RDS for MySQL側のバイナリログの設定の確認を行います。

1.MySQL ShellコマンドでAmazon RDS for MySQLのデータベースに接続
　mysqlsh ユーザ名@ホスト名 --password
2.バイナリログの設定が有効化されているか確認
　SELECT @@log_bin;
3.バイナリログの形式がROWになっているか確認
　SELECT @@binlog_format;
4.バイナリログが存在しているか確認
　show binary logs;

以下は、実際にコマンドを実行した結果となります。

バイナリログの保持設定を変更

続いて、バイナリログの保持設定の変更を行います。

Amazon RDS for MySQLでは、デフォルト設定のままだとバイナリログが自動的に削除されてしまいます。

その為、後続のレプリケーション設定時に必要なバイナリログがすでに削除されている可能性がありエラーが発生するケースがあります。

このようなトラブルを防ぐため、以下のコマンドを使用してバイナリログを一定期間保持するように設定を変更します。

1.バイナリログの現在の保持設定を確認
　call mysql.rds_show_configuration;
2.バイナリログの保持設定を変更
　call mysql.rds_set_configuration('binlog retention hours',24);
3.バイナリログの設定が変更されているか確認
　call mysql.rds_show_configuration;
※今回はデータ量が少ない為保持期間を24時間に変更しています。
　大量データを移行する場合や作業に時間がかかる見込みがある場合は、より長めの保持期間に設定する
　ことをおすすめします。

以下は、実際にコマンドを実行した結果となります。

レプリケーション用ユーザの作成

次に、レプリケーションで使用するユーザの作成と権限の付与を行います。

このユーザーは、Amazon RDS for MySQL側のバイナリログにアクセスしOracle HeatWave MySQLへデータを同期するために使用します。

以下のコマンドを実行します。

1.レプリケーション用ユーザの作成
　create user 'ユーザ名'@'ホスト名' identified by 'パスワード';
2.レプリケーション権限の付与
　grant replication slave on . to 'ユーザ名'@'ホスト名';
3.作成したレプリケーション用ユーザの確認
　select user from mysql.user where user = 'ユーザ名';
4.権限の確認
　show grants for 'ユーザ名'@'ホスト名'

以下は、実際にコマンドを実行した結果となります。

データのエクスポート（RDS→HeatWave）

次に、Amazon RDS for MySQLのデータをOracle MySQL HeatWaveへエクスポートします。

MySQL ShellのcopyInstanceユーティリティ機能は、移行元インスタンスに存在する全ての任意に作成されたスキーマを対象にデータをコピーします。

その為、不要なスキーマやデータが含まれる場合は、copyInstanceユーティリティ機能ではなくスキーマ単位・テーブル単位で移行できる他のコマンドのご利用を検討してください。

詳細はコマンドや使用方法については、本記事末尾の「参考記事・ドキュメントセクション」に記載のMySQL Shell 8.4コマンドリファレンスをご参照ください。

まず、移行元である Amazon RDS for MySQLに存在するデータベース一覧を以下のコマンドで確認します。

1.移行元データベースを確認
　show databases;

以下は、実際にコマンドを実行した結果となります。

移行元のデータベースを確認したら、次にMySQL ShellのcopyInstanceユーティリティ機能を使用してデータの移行を実行します。

まずは、実際のデータを移行せずに設定内容や互換性を検証するDry Run（試行モード）を実行します。

以下のコマンドを実行します。

1.JavaScriptモードへ切り替え
　\js
2.試行モード実行
util.copyInstance(
  'mysql://ユーザ名@ホスト名',
  {
    "compatibility": [
      "force_innodb",
      "skip_invalid_accounts",
      "strip_definers",
      "strip_restricted_grants",
      "strip_tablespaces",
      "ignore_wildcard_grants",
      "strip_invalid_grants",
      "create_invisible_pks"
    ],
    updateGtidSet: "append",
    users: "true",
    threads: 4,
    dryRun: "true"
  }
)

以下は、実際にコマンドを実行した結果となります。

実行結果に「ERROR]が含まれていなければ、基本的に問題ありません。

Dry Runで互換性や構文エラーなどの問題がなかったことを確認できましたので、データ移行を実行します。

Dry Runの設定から「dryRun: "false"」に変更して以下のコマンドを実行します。

1.データ移行を実行
util.copyInstance(
  'mysql://ユーザ名@ホスト名',
  {
    "compatibility": [
      "force_innodb",
      "skip_invalid_accounts",
      "strip_definers",
      "strip_restricted_grants",
      "strip_tablespaces",
      "ignore_wildcard_grants",
      "strip_invalid_grants",
      "create_invisible_pks"
    ],
    updateGtidSet: "append",
    users: "true",
    threads: 4,
    dryRun: "false"
  }
)

以下は、実際にコマンドを実行した結果となります。

こちらも実行結果に「ERROR]が含まれていなければ、基本的に問題ありません。

実行結果の中に表示されている赤枠で囲っている「Binlog_file」と「Binlog_position」の値はこのあと行うOracle MySQL HeatWave側でのレプリケーション設定で使用しますので控えておきます。

続いて、Amazon RDS for MySQLからOracle MySQL HeatWaveへの移行が正しく行われたかを確認していきます。

以下のコマンドを実行します。

1.MySQL ShellコマンドでOracle HeatWave MySQLのデータベースへ接続
　mysqlsh ユーザ名@ホスト名 --password
2.データベース一覧を表示
　show databases;

以下は、実際にコマンドを実行した結果となります。
実行結果から移行元に存在していた「test」データベースがOracle MySQL HeatWave側にも確認できた為データベース移行が正常に完了できたことが確認できます。

RDS側でデータの更新

データのエクスポートが完了し、移行元と移行先で初期データの整合が確認できたところで次はAmazon RDS for MySQLからOracle MySQL HeatWaveへのレプリケーションを行います。

今回は、エクスポート作業中に移行元で更新が発生したケースを想定し、あらかじめworkテーブルにデータを追加しておきます。

1.MySQL ShellコマンドでAmazon RDS for MySQLのデータベースに接続
　mysqlsh ユーザ名@ホスト名 --password
2.workテーブルのデータを確認
　select * from test.work;
3.workテーブルにデータを追加
　insert into test.work VALUES(4, 'aaaaaaaaaa');
  insert into test.work VALUES(5, 'aaaaaaaaaa');
　commit;
5.workテーブルのデータを確認
　select * from test.work;

以下は、実際にコマンドを実行した結果となります。

レプリケーションの設定

続いて、Amazon RDS for MySQL側で発生した変更を Oracle MySQL HeatWave側に同期させるために、レプリケーションの設定を行います。

OCIコンソールメニューから「データベース」→「チャネル」を選択します。

「チャネルの作成」を選択し、以下の項目を入力します。

• 名前：任意（chanel-rds）
• 作成時に自動的に有効化：チェックを入れる
• ホスト名：RDSのホスト名
• データベース・ポート：3306
• ユーザ名：レプリケーション用に作成したユーザ（repuser）
• パスワード：任意
• パスワードの確認：任意
• SSLモード：必須（REQUIRED）
• ソースGTID設定：ソースでは、GTID自動ポジショニングを使用できません
• UUIDを手動で指定を選択
• バイナリ・ログ・ファイル名：先ほど控えたログファイル名
• バイナリ・ログ・オフセット：先ほど控えたポジション
• 主キーのない表：許可（ALLOW）
• ターゲットDBシステム：移行先のDB
• 共通フィルタ・テンプレート：AWS RDS MySQL 8.0

レプリケーションの確認

レプリケーションの設定が完了したら、Oracle MySQL HeatWave側にAmazon RDS for MySQLの変更内容が正しく反映されているかを確認します。
まずは、Oracle MySQL HeatWave側でレプリケーションが正常に機能しているかを確認します。
以下のコマンドを実行します。

1.MySQL ShellコマンドでOracle HeatWave MySQLのデータベースへ接続
　mysqlsh ユーザ名@ホスト名 --password
2.レプリケーションの状態を確認
　SHOW REPLICA STATUS\G

以下は、実際にコマンドを実行した結果となります。
実行結果の赤枠の項目の値から、HeatWaveがRDSに追いついておりレプリケーションが正常に機能していることが確認できます。

• Replica_IO_Running：Yes
• Replica_SQL_Running：Yes
• Seconds_Behind_Source：0
• Replica_SQL_Running_State：Replica has read all relay log; waiting for more updates

パラメータ名	説明
Replica_IO_Running	ソースのバイナリログを読み取る I/O スレッドが実行されているかどうかを示します。レプリケーションが正しく開始されていれば、このステータスは通常Yesとなります。
Replica_SQL_Running	リレーログ内のイベントを実行する為のSQLスレッドが実行中かどうかを示します。レプリケーションが正しく機能している状態ではYesとなります。
Seconds_Behind_Source	レプリケーションSQLスレッドが、ソース側のバイナリログを処理し終えるまでに遅れている秒数を示します。0に近いほどリアルタイムに同期されていることを意味し、数値が大きい場合はレプリカがソースのイベント処理に追いついていない可能性があります。
Replica_SQL_Running_State	レプリカ側で動作しているSQLスレッドの現在の状態を示します。「Replica has read all relay log; waiting for more updates」と表示されている場合、レプリカ側のSQLスレッドは現時点で利用可能なリレーログを全て読み終え、新しいイベントが届くまで処理を待機している状態になります。

最後に、Amazon RDS for MySQL側で追加したレコードがOracle MySQL HeatWave側にも正しく反映されているかを確認します。

以下のコマンドを実行します。

1.workテーブルのデータを確認
　select * from test.work;

以下は、実際にコマンドを実行した結果となります。
Amazon RDSfor MySQL側で追加したレコードがOracle MySQL HeatWave側に反映されており、レプリケーションが正常に動作していることが確認できます。

今回の移行方法に関する注意点

binlog_format は「ROW」を設定すること

・Amazon RDS for MySQLのバイナリログ形式（binlog_format）を行ベース（ROW）に設定する必要があります。
Oracle MySQL HeatWaveが行ベースレプリケーションのみをサポートする為です。

RDS 内でレプリケーションを構成している場合

・現在のAWS環境内にRDSレプリケーションが構成されている場合、リーダ・インスタンスをレプリケーションソースとすることをおすすめします。
RDSインスタンスに対して多数の同時実行処理がある場合に、ライター・インスタンスを使用して移行を実施するとデータベースのパフォーマンスに影響が発生する可能性がある為です。

MySQL Shellのバージョン

・使用するMySQL Shellのバージョンは、移行先のバージョンと同じかそれ以上である必要があります。

さいごに

本記事では、Amazon RDS for MySQLからOracle MySQL HeatWaveへの移行方法についてご紹介しましたがいかがでしたでしょうか。

今回、ご紹介したMySQL ShellのcopyInstanceユーティリティ機能を用いたデータ移行は移行元のデータをエクスポートしながら同時に移行先へインポートを実行してくれる為、従来のようにダンプファイルを保持するストレージ領域を確保する必要がなく作業時間の短縮やストレージ使用量の削減といった大きな利点があります。

皆さまの環境でも移行の検討・実施を行う際の参考になり、問題解決の一助となれば幸いです。

以上となります。最後までご覧頂き、ありがとうございました。

参考記事・ドキュメント

以下の参考記事・ドキュメントもあわせてご参照ください。

本記事では割愛した構成手順や、Oracle MySQL HeatWaveへの移行全体像について解説されています。

AWS-OCI間のVPN接続の手順について
https://cloudii.jp/news/blog/aws/awsocivpn/

HeatWave MySQLへの移行ガイド
https://go.oracle.com/HeatWaveMigration_ja

MySQL Shell 8.4コマンドリファレンス
https://dev.mysql.com/doc/mysql-shell/8.4/en/mysql-shell-utils-copy.html#mysql-shell-utilities-copy-about