【OCI クラウド移行ガイド】 Amazon Aurora Serverlessを MySQL HeatWave Database Serviceへ移行してみた～MySQL Shell & Replication Channel 編～

OCIクラウド移行ガイドとは

オンプレミスやAWSなど、複数のプラットフォームからOracle Cloud Infrastructureへの移行プロジェクトに取り組んでいるクラウドエンジニア（@araidon,@kazunishi,@yama6）による、OCI移行手順をまとめたシリーズ記事です。
各回、サンプルワークロードから対象サービスを取り上げ、移行手順をガイドいたします。

移行したいサンプルワークロード

日々の業務でよく目にするサービスを中心に、サンプルワークロードとしてまとめてみました。このシリーズでは、主にAWSからの移行を取り上げます。
このワークロードは、ユーザがログインして、Web上で写真を共有するWebサービスをイメージしています。

移行するサービス：Amazon Aurora for MySQL

今回、移行対象とするのはAmazon Aurora Serverlessです。
MySQL Shell及び、MySQL HeatWave Database ServiceのReplication Channel機能を利用した移行手順をガイドします。

移行のイメージ

大まかな移行の流れ

1. AWS側でAurora Serverlessを立ち上げ、Dumpファイルを作成し、そこからMDSを作成します。
2. MDS側でReplication Channelを設定し、Aurora Serveerless側でのデータ更新がMDS側に反映されているか検証します。

移行手順としては、下記資料を参考にしています。
Amazon RDS/Auroraから
MySQL HeatWave Database Serviceへの移⾏

なお、本記事作成にあたり、下記の移行記事を参考に致しました。

※移行元のDatabaseがRDSもしくはAuroraからAurora Serverlessに変更となっただけで、両記事の合わせ技での移行ガイドとなります。

前提条件

AWSとOCIがVPN接続されていること、Aurora,MDSそれぞれに接続するための踏み台サーバがパブリックサブネット上に構築されていることが前提条件です。
接続手順は下記の記事を参考にしてください。

移行フロー

1. MySQL Shellを使用したDumpファイルによるデータベース移行
2. Replication Channelを使用したGTIDによるデータレプリケーション
3. 動作検証

1. MySQL Shellを使用したDumpファイルによるデータベース移行

1-1. OCI Object Storage: Dumpファイル保存用バケットを作成

まずは、Aurora ServerlessのDumpファイル保存用にOCI側でObject Storageバケットを作成します。

1-2-1. EC2：作業用サーバにてOCI接続のための権限設定：configファイル作成

次に、EC2（作業用サーバ）からOCI object Storageにdump fileを転送するための権限設定を行います。

mkdirコマンドで、.ociディレクトリ作成及び
Touchコマンドで"./.oci/config"を作成します。

[ec2-user@ip-10-1-3-181 ~]$ mkdir .oci
[ec2-user@ip-10-1-3-181 ~]$ touch ~/.oci/config

1-2-2. OCI ユーザ：作業用サーバにてOCI接続のための権限設定：APIキーの発行

OCIコンソール画面右上のプロファイルアイコン押下>ユーザー設定

リソース>API キー>APIキーの追加

「秘密キーのダウンロード」後、追加ボタン押下

構成ファイルのプレビュー欄の内容をコピー＆メモ

1-2-3. EC2：作業用サーバにてOCI接続のための権限設定：秘密キーの転送

ダウンロードしたファイル名をoci_api_key.pemに変更してください。
cloudShellの機能で、アクション>ファイルのアップロードから、cloud Shellに秘密鍵をアップロードします。

次に、一度Cloud shellに戻り、oci_api_key.pemを作業用サーバに転送します。

[cloudshell-user@ip-10-6-23-193 ~]$ scp -i test-pub-key.pem oci_api_key.pem ec2-user@52.195.190.205:/home/ec2-user/.oci
oci_api_key.pem                                                                                                                                                                                         100% 1730   788.1KB/s   00:00    
[cloudshell-user@ip-10-6-23-193 .oci]$ 

再度作業用サーバにログインし、/.ociディレクトリにoci_api_key.pemがあることを確認します。

[ec2-user@ip-10-1-3-181 .oci]$ ls
config  oci_api_key.pem

1-2-4. EC2：作業用サーバにてOCI接続のための権限設定：configの編集

viコマンドでconfigを編集します。
XXXの部分は、1-2-2の構成ファイルからコピーした内容を貼り付けてください。

[DEFAULT]
user=ocid1.user.oc1..XXX
fingerprint=XXX
tenancy=ocid1.tenancy.oc1..XXX
region=ap-tokyo-1
key_file=oci_api_key.pem

これでEC2からOCI Object Storageにファイルを送付する設定は完了です。

1-3. EC2：作業用サーバにてmysql shellのインストール

mysql shellをインストールし、バージョンを確認します。

[ec2-user@ip-10-1-3-181 ~]$ sudo dnf install mysql-shell
Last metadata expiration check: 1:56:37 ago on Tue Oct  3 01:57:08 2023.
Dependencies resolved.
～略～
[ec2-user@ip-10-1-3-181 ~]$ mysqlsh   Ver 8.0.34 for Linux on x86_64 - for MySQL 8.0.34 (MySQL Community Server (GPL))

1-4. Aurora：パラメータグループの作成

下記記事の1-1と1-2を参考に、パラメータグループを作成します。
【OCI クラウド移行ガイド】 Amazon Aurora を MySQL HeatWave Database Serviceへ移行してみた～Replication Channel 編～

1-5. Aurora Serverless：DBの作成

設定項目	値
データベース作成方法を選択	標準作成
エンジンのタイプ	Aurora (MySQL Compatible)
利用可能なバージョン	8.0.mysql_aurora.3.04.0
テンプレート	本番稼働用
DB クラスター識別子	任意の値
マスターパスワード	任意の値
インスタンスの設定	Serverless v2
最小ACU	4 (任意)
最大ACU	12 (任意)
マルチ AZ 配置	Aurora レプリカを作成しない
コンピューティングリソース	EC2 コンピューティングリソースに接続しない
ネットワークタイプ	IPv4
Virtual Private Cloud (VPC)	VPN接続を設定したVPC
DB クラスター識別子	任意の値
VPC セキュリティグループ	VPN接続を設定したセキュリティグループ
追加設定	データベースの選択肢
最初のデータベース名	任意の値
DB クラスターのパラメータグループ	1-4で作成したパラメータグループを選択
設定画面	👇

1-6. EC2 → Aurora Serverless：Aurora Serverlessへの接続とデータ投入

EC2からAurora Serverlessに接続し、sourceコマンドでemployeesデータを投入します。
データは、前回同様、下記のリポジトリから落としてきました。

[ec2-user@ip-10-1-3-181 ~]$ cd test_db/
[ec2-user@ip-10-1-3-181 test_db]$ ls
Changelog  employees.sql              employees_partitioned_5.1.sql  load_departments.dump  load_dept_manager.dump  load_salaries1.dump  load_salaries3.dump  objects.sql  show_elapsed.sql  test_employees_md5.sql  test_versions.sh
README.md  employees_partitioned.sql  images                         load_dept_emp.dump     load_employees.dump     load_salaries2.dump  load_titles.dump     sakila       sql_test.sh       test_employees_sha.sql
[ec2-user@ip-10-1-3-181 test_db]$ mysql --host serverless-instance-1.cn07mhl9cm4v.ap-northeast-1.rds.amazonaws.com -u admin -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 365
Server version: 8.0.28 Source distribution

Copyright (c) 2000, 2023, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> source employees.sql
Query OK, 0 rows affected, 1 warning (0.01 sec)

Query OK, 1 row affected (0.03 sec)

Database changed
+-----------------------------+
| INFO                        |
+-----------------------------+
| CREATING DATABASE STRUCTURE |
+-----------------------------+
1 row in set (0.01 sec)

Query OK, 0 rows affected, 6 warnings (0.06 sec)
～略～
Query OK, 7671 rows affected (0.19 sec)
Records: 7671  Duplicates: 0  Warnings: 0

+---------------------+
| data_load_time_diff |
+---------------------+
| 00:01:23            |
+---------------------+
1 row in set (0.02 sec)

mysql> exit
Bye

このあと、mysql shellからDumpファイルを取得します。

1-7. EC2：mysql shellを使用したAurora Serverlessへの接続

まずはmysql shellを起動します。

[ec2-user@ip-10-1-3-181 ~]$ cd .oci
[ec2-user@ip-10-1-3-181 .oci]$ mysqlsh
MySQL Shell 8.0.34

Copyright (c) 2016, 2023, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.

Type '\help' or '\?' for help; '\quit' to exit.
 MySQL  JS > 

Aurora Serverlessに接続します。

MySQL  JS > \connect [e-mail]
Creating a session to '[e-mail]'
Please provide the password for '[e-mail]': **********
Save password for '[e-mail]'? [Y]es/[N]o/Ne[v]er (default No): Y
Fetching schema names for auto-completion... Press ^C to stop.
Your MySQL connection id is 947
Server version: 8.0.28 Source distribution
No default schema selected; type \use <schema> to set one.
 MySQL  serverless-instance-1.cn07mhl9cm4v.ap-northeast-1.rds.amazonaws.com:3306 ssl  JS > 

1-8. Aurora：Aurora ServerlessのDump fileをOCIのObject Storageに作成

以下のコマンドでDumpファイルを作成します。

> util.dumpInstance("/test", {osBucketName: "test-dump-bucket", osNamespace: "nri4fvyjuxj1", threads:1, ocimds: true, compatibility: ["strip_restricted_grants", "strip_definers"],consistent: "false"})

util.dumpInstanceに設定したパラメータは下記のとおりです。

項目	説明
outputurl	バケット直下に作成される親ディレクトリ名。任意でOK
osBucketName	OCIで作成したObject Storageのバケット名を入力
osNamespace	OCIテナントのNameSpace名を入力。OCIコンソールの右上人型アイコンのテナンシをクリックすることで、オブジェクト・ストレージ・ネームスペースが確認出来ます。
threads	EC2のvCPU数を指定
ocimds	このオプションを true に設定すると、MySQL Database Service との互換性のチェックおよび変更が可能になります。
compatibility	MySQL Database Service との互換性のために指定された要件を適用します。
strip_restricted_grants	MySQL Database Service によって制限されている特定の権限を GRANT ステートメントから削除して、ユーザーおよびそのロールにこれらの権限を付与できないようにします
strip_definers	ビュー、ルーチン、イベントおよびトリガーから DEFINER 句を削除して、これらのオブジェクトがデフォルト定義者 (スキーマを起動するユーザー) で作成されるようにし、ビューおよびルーチンの SQL SECURITY 句を変更して、DEFINER のかわりに INVOKER を指定します。
consistent	ダンプ中にインスタンスをバックアップ用にロックして、一貫性のあるデータダンプを有効 (true) または無効 (false) にします。

下記記事で設定したパラメータとの差分は、consistentを追加し、false（無効）にしている点です。

実行結果は、次の通りとなりました。

Initializing - done 
2 out of 6 schemas will be dumped and within them 6 tables, 2 views.
8 out of 11 users will be dumped.
Gathering information - done 
WARNING: The dumped value of gtid_executed is not guaranteed to be consistent
Checking for compatibility with MySQL Database Service 8.0.34
NOTE: User 'rds_superuser_role'@'%' had restricted privileges (RELOAD, ROLE_ADMIN, SESSION_VARIABLES_ADMIN, SET_USER_ID, SHOW_ROUTINE) removed
NOTE: User 'rdsadmin'@'localhost' had restricted privileges (AUDIT_ABORT_EXEMPT, AUDIT_ADMIN, BINLOG_ADMIN, BINLOG_ENCRYPTION_ADMIN, CREATE TABLESPACE, ENCRYPTION_KEY_ADMIN, FILE, FLUSH_OPTIMIZER_COSTS, FLUSH_STATUS, FLUSH_TABLES, FLUSH_USER_RESOURCES, GROUP_REPLICATION_ADMIN, INNODB_REDO_LOG_ENABLE, PASSWORDLESS_USER_ADMIN, RELOAD, REPLICATION_SLAVE_ADMIN, ROLE_ADMIN, SERVICE_CONNECTION_ADMIN, SET_USER_ID, SHOW_ROUTINE, SHUTDOWN, SUPER, SYSTEM_USER, TABLE_ENCRYPTION_ADMIN) removed
NOTE: Database `employees` had unsupported ENCRYPTION option commented out
NOTE: Database `serverless` had unsupported ENCRYPTION option commented out
NOTE: View `employees`.`dept_emp_latest_date` had definer clause removed
NOTE: View `employees`.`dept_emp_latest_date` had SQL SECURITY characteristic set to INVOKER
NOTE: View `employees`.`current_dept_emp` had definer clause removed
NOTE: View `employees`.`current_dept_emp` had SQL SECURITY characteristic set to INVOKER
Compatibility issues with MySQL Database Service 8.0.34 were found and repaired. Please review the changes made before loading them.
Validating MDS compatibility - done        
Writing global DDL files
Writing users DDL
Running data dump using 1 thread.
NOTE: Progress information uses estimated values and may not be accurate.
Writing schema metadata - done       
Writing DDL - done         
Writing table metadata - done       
Starting data dump
100% (3.92M rows / ~3.91M rows), 960.02K rows/s, 32.98 MB/s uncompressed, 8.59 MB/s compressed                  
Dump duration: 00:00:05s                                                                      
Total duration: 00:00:06s                                                                     
Schemas dumped: 2                                                                             
Tables dumped: 6                                                                              
Uncompressed data size: 141.50 MB                                                             
Compressed data size: 36.82 MB                                                                
Compression ratio: 3.8                                                                        
Rows written: 3919015                                                                         
Bytes written: 36.82 MB                                                                       
Average uncompressed throughput: 25.87 MB/s                                                   
Average compressed throughput: 6.73 MB/s   

Aurora Serverlessのユーザには、FLUSH TABLES WITH READ LOCK ステートメントを使用してグローバル読取りロックを設定する実行権限が付与されておらず、consistentをfalseに設定しないと下記のエラーが発生します。

consistent: "false"を設定しなかった場合の実行結果

NOTE: Backup lock is not available to the account 'admin'@'%' and DDL changes will not be blocked. The dump may fail with an error if schema changes are made while dumping.
Acquiring global read lock
WARNING: The current user lacks privileges to acquire a global read lock using 'FLUSH TABLES WITH READ LOCK'. Falling back to LOCK TABLES...
ERROR: The current user does not have required privileges to execute FLUSH TABLES WITH READ LOCK.
    Backup lock is not available to the account 'admin'@'%' and DDL changes cannot be blocked.
    The gtid_mode system variable is set to OFF or OFF_PERMISSIVE.
    The log_bin system variable is set to OFF or the current user does not have required privileges to execute SHOW MASTER STATUS.
The consistency of the dump cannot be guaranteed.
ERROR: Unable to acquire global read lock neither table read locks.
Global read lock has been released
Util.dumpInstance: While 'Initializing': Unable to lock tables: Consistency check has failed. (MYSQLSH 52002)

このMYSQLSH 52002について調べたところ、下記リファレンスのP.83にこのような記載がありました。
「ダンプ ユーティリティが「テーブル ロック」に関する「エラー」を生成する場合に限り、consistent: false オプションを使用します」

オブジェクトストレージを参照すると、testフォルダ配下にDumpファイルが格納されていることを確認できました。

1-9. MDS：OCIのObject StorageのDumpファイルからMDSを作成

取得したAurora ServerlessのDumpファイルから、MySQL HeatWave Database Serviceを作成します。
基本的に下記の記事を参考にして値の入力、選択をします。

DumpファイルからDBを作成するため、「拡張オプションの表示」を押下します。
さらに「データのインポート」タブに切り替え、「既存のバケットに対するPAR URLを作成するには、ここをクリックします。」のラベルをクリックします。

右側にスライドでポップアップが出てくるため、「PAR URLの作成と設定」を押下します。

押下すると、PARソースURLに DumpファイルのURLが表示されます。

作成ボタンを押下します。
しばらくすると、DBがアクティブになります。

1-10. MDS：接続確認＆データ確認

まずは作成したMDSにパブリックインスタンスのCompute VMからログインします。

[opc@test-instance ~]$ mysql -h 10.2.1.219 -u admin -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 31
Server version: 8.0.34-u3-cloud MySQL Enterprise - Cloud

Copyright (c) 2000, 2023, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> 

次に、Aurora Serverlessで作成したデータが格納されているか確認します。

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| employees          |
| information_schema |
| mysql              |
| mysql_audit        |
| performance_schema |
| serverless         |
| sys                |
+--------------------+
7 rows in set (0.00 sec)

mysql> use employees;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+----------------------+
| Tables_in_employees  |
+----------------------+
| current_dept_emp     |
| departments          |
| dept_emp             |
| dept_emp_latest_date |
| dept_manager         |
| employees            |
| salaries             |
| titles               |
+----------------------+
8 rows in set (0.00 sec)

employeesデータを確認することができました！

2. Replication Channelを使用したGTIDによるデータレプリケーション

主に、下記記事の流れに従います。

2-1. Aurora Serverless：Replicationユーザの作成

CREATE USER repluser2@'%' IDENTIFIED BY '任意のパスワード';
Query OK, 0 rows affected (0.55 sec)
GRANT REPLICATION SLAVE on *.* to repluser2@'%';
Query OK, 0 rows affected (0.03 sec)

2-2. Aurora Serverless：GTIDの確認と設定

下記のコマンドで、Aurora ServerlessのGTIDを確認しましょう。

mysql> show global variables like 'GTID%';
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| gtid_executed                    |       |
| gtid_executed_compression_period | 0     |
| gtid_mode                        | ON    |
| gtid_owned                       |       |
| gtid_purged                      |       |
+----------------------------------+-------+
5 rows in set (0.00 sec)

Aurora Serverlessはgtid_modeをONにしても、デフォルトでGTIDを持たないようです。
では設定しましょう。設定には、下記の記事を参考にしました。

mysql> call mysql.rds_gtid_purged('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
Query OK, 0 rows affected (0.01 sec)

mysql> show global variables like 'GTID%';
+----------------------------------+-----------------------------------------+
| Variable_name                    | Value                                   |
+----------------------------------+-----------------------------------------+
| gtid_executed                    | 3e11fa47-71ca-11e1-9e33-c80aa9429562:23 |
| gtid_executed_compression_period | 0                                       |
| gtid_mode                        | ON                                      |
| gtid_owned                       |                                         |
| gtid_purged                      | 3e11fa47-71ca-11e1-9e33-c80aa9429562:23 |
+----------------------------------+-----------------------------------------+
5 rows in set (0.00 sec)

2-3. MDS：GTIDの設定と確認

Aurora Serverlessで設定したGTIDをMDS側でも設定します。

mysql> call sys.set_gtid_purged('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
Query OK, 0 rows affected (0.00 sec)

mysql> show global variables like 'GTID%';
+----------------------------------+-----------------------------------------+
| Variable_name                    | Value                                   |
+----------------------------------+-----------------------------------------+
| gtid_executed                    | 3e11fa47-71ca-11e1-9e33-c80aa9429562:23 |
| gtid_executed_compression_period | 0                                       |
| gtid_mode                        | ON                                      |
| gtid_owned                       |                                         |
| gtid_purged                      | 3e11fa47-71ca-11e1-9e33-c80aa9429562:23 |
+----------------------------------+-----------------------------------------+
5 rows in set (0.00 sec)

このGTIDを両方のDBに持たせて、Aurora (ソース) でコミットされた各トランザクションをMDS（ターゲット）に反映し、レプリケーションを実現します。

2-4. MDS：Replication Channelの作成

上記記事を参考に、Replication Channelを作成します。

チャネルがアクティブになれば成功です。

3. 動作検証

Aurora側でDBを更新し、MDS側でも同様の更新が自動的に行われるか検証します。

3-1. Aurora：データの更新

departments（部署テーブル）に新しくIT部門を追加してみます。

mysql> select * from departments;
+---------+--------------------+
| dept_no | dept_name          |
+---------+--------------------+
| d009    | Customer Service   |
| d005    | Development        |
| d002    | Finance            |
| d003    | Human Resources    |
| d001    | Marketing          |
| d004    | Production         |
| d006    | Quality Management |
| d008    | Research           |
| d007    | Sales              |
+---------+--------------------+
9 rows in set (0.00 sec)

mysql> insert into departments values ('d100','IT department');
Query OK, 1 row affected (0.04 sec)

mysql> select * from departments;
+---------+--------------------+
| dept_no | dept_name          |
+---------+--------------------+
| d009    | Customer Service   |
| d005    | Development        |
| d002    | Finance            |
| d003    | Human Resources    |
| d100    | IT department      |
| d001    | Marketing          |
| d004    | Production         |
| d006    | Quality Management |
| d008    | Research           |
| d007    | Sales              |
+---------+--------------------+
10 rows in set (0.01 sec)

d100でIT departmentが追加されました。

3-2. MDS：データの確認

これがMDS側で反映されているか確認してみます。

mysql> select * from departments;
+---------+--------------------+
| dept_no | dept_name          |
+---------+--------------------+
| d009    | Customer Service   |
| d005    | Development        |
| d002    | Finance            |
| d003    | Human Resources    |
| d100    | IT department      |
| d001    | Marketing          |
| d004    | Production         |
| d006    | Quality Management |
| d008    | Research           |
| d007    | Sales              |
+---------+--------------------+
10 rows in set (0.00 sec)

d100でIT departmentが追加されたことが確認でき、レプリケーションによるデータ反映が検証できました。

まとめ

今回は、Aurora ServerlessからMySQL HeatWave Database Serviceへの移行を試してみました。
これまでの記事の合わせ技になりましたが、util.dumpInstance実行時のパラメータ追加や、GTIDの設定など、RDS for MySQLやAurora MySQLと移行方法に多少の違いがありました。

とはいえ、異なるプラットフォームのフルマネージドDBサービスであっても、MySQL Shellやmysql固有のパラメータを活用して移行可能であることがご理解いただけたかと思います。

次回は、DynamoDBから、Oracle NoSQL Database Cloud Serviceの移行についてガイドを作成します。

参考