Amazon Web Services ブログ

GTID ベースのレプリケーションを使用したフォールバックオプションで Amazon Aurora MySQL へ移行する

本番アプリケーションを移行する場合、多くの場合、フォールバックオプションを備えていることが重要です。このブログ記事では、グローバルトランザクション識別子 (GTID) ベースのレプリケーションを使用して、Amazon RDS MySQL ワークロードを Amazon Aurora MySQL に移行する方法を説明します。また、問題が発生した場合にフォールバックメカニズムを使用する方法についても説明します。

GTID ベースのレプリケーションの詳細については、「Amazon Aurora for MySQL 互換エディションでグローバルトランザクション 識別子 (GTID) によるレプリケーションがサポートされるようになりました」をご覧ください。

この記事では、レプリケーショントポロジには、2 つのリードレプリカ (RDS MySQL リードレプリカと Aurora MySQL レプリカ) を持つマスター RDS MySQL インスタンスがあります。移行中に問題が発生した場合のフォールバックインスタンスとして RDS MySQL リードレプリカを使用し、元の RDS MySQL マスターが影響を受けないようにします。ただし、元の RDS MySQL マスターインスタンスをフォールバックオプションとして使用することもできます。移行が成功すると、Aurora MySQL レプリカが RDS MySQL レプリカインスタンスのマスターインスタンスになります。

GTID ベースのレプリケーションを使用する主な利点は、すべてのトランザクションに一意の識別子を割り当てられ、レプリケーショントポロジ内の各 MySQL サーバーがすでに実行したトランザクションを追跡できることにあります。GTID ベースのレプリケーションはトランザクションベースであるため、マスターとレプリカ間のデータの一貫性を簡単に判断できます。マスターでコミットされたすべてのトランザクションがレプリカにもコミットされている場合、2 つの間に一貫性があります。これにより、auto-positioning が可能になります。これは、binlog ファイルの名前または位置を指定することなく、レプリカがマスターインスタンスをポイントする機能です。

前提条件

このチュートリアルを実行するには、次の前提条件を満たしている必要があります。

  • レプリケーショントポロジでは、マスターインスタンスとフォールバックレプリカが RDS MySQL 上にあること。RDS MySQL インスタンスでは、GTID ベースのレプリケーションは、RDS MySQL バージョン 5.7.23 以降と MySQL 5.7 バージョンでサポートされています。
  • ターゲット移行サーバーは Aurora MySQL であるため、GTID ベースのレプリケーションは、Aurora MySQL バージョン 2.04 以降の MySQL 5.7 互換クラスターでサポートされています。

GTID ベースのレプリケーションは、Aurora MySQL バージョン 2.04 以降、RDS MySQL バージョン 5.7.23 以降と MySQL 5.7 バージョンでサポートされています。レプリケーション設定のすべての RDS MySQL DB インスタンスは、この要件を満たす必要があります。GTID ベースのレプリケーションは、RDS MySQL 5.5、5.6、または 8.0 ではサポートされていません。詳細については、「Aurora MySQL で GTID ベースのレプリケーションを使用する」と「Amazon RDS MySQL で GTID ベースのレプリケーションを使用する」を参照してください。

ソリューションの概要

このチュートリアルには、次の手順が含まれています。

  1. GTID ベースのレプリケーションを設定する
  2. Aurora MySQL を新しいマスターインスタンスとして設定し、RDS MySQL レプリカにフォールバックオプションをセットアップする
  3. アプリケーションを Aurora DB クラスターに切り替える
  4. RDS MySQL レプリカへのフォールバックを設定する

GTID ベースのレプリケーションの設定

次の図は、可能性がある 2 つのレプリケーションシナリオを示しています。マスターレプリカとリードレプリカに応じて、マスター RDS MySQL と新しいリードレプリカ間、または既存のレプリカ間で GTID ベースのレプリケーションを設定することを選択します。

新しいリードレプリカの GTID ベースのレプリケーションの設定

このレプリケーショントポロジのすべてのインスタンスにはカスタムパラメータグループがあり、GTID ベースのレプリケーションを有効にするパラメータで設定されています。詳細については、「GTID ベースのレプリケーションのパラメータ」を参照してください。

マスター (RDS MySQL) と新しいリードレプリカ (RDS MySQL リードレプリカ) 間の GTID ベースのレプリケーションの設定

マスター (RDS MSQL) と新しいレプリカ (RDS MySQL リードレプリカ) の間で GTID ベースのレプリケーションを設定するには、次の手順を実行します。

  1. gtid-mode = ON と enforce_gtid_consistency = ON のパラメータ を使用して、マスター RDS MySQL インスタンスのカスタムパラメータグループを作成します。
  2. DB インスタンスを変更して、パラメータグループを関連付けます。
  3. RDS MySQL インスタンスを手動で再起動して、DB インスタンスが新しい DB パラメータグループを使用できるようにします。
    RDS MySQL インスタンスに関連付けられたカスタムパラメータグループがすでにある場合、GTID ベースのレプリケーションを有効にするには、gtid-mode = ON と enforce_gtid_consistency = ON パラメータを設定します。これらのパラメータは RDS では静的であるため、RDS MySQL インスタンスを再起動する必要があります。詳細については、「DB パラメータグループの使用」と「DB インスタンスの再起動」を参照してください。
  4. マスター RDS MySQL インスタンスでバイナリログを有効にします。
    すでにバックアップを有効にしている場合、バイナリログは自動的に有効になります。バックアップが有効になっていない場合は、バックアップ保持期間を 0 以外の値に設定して (0 からゼロ以外の値に変更する場合、再起動する必要があります)、RDS MySQL インスタンスでバイナリログを有効にします。
    RDS MySQL でバイナリログを有効にするには再起動する必要があるため、カスタムパラメータグループの設定中にこの手順を組み込むことができます。
  5. マスター RDS MySQL インスタンスでバイナリログの保持時間を設定します。
    デフォルトでは、RDS MySQL インスタンスはできるだけ早くバイナリログをパージします。バイナリログ保持期間を設定するには、手順 mysql_rds_set_configuration を使用して、バイナリログ保持時間の設定パラメータと、bind ファイルをマスター RDS MySQL インスタンスに保持する時間数を指定します。MySQL DB インスタンスの場合、最大のバイナリログ保持時間は 168 (7 日間) です。次のコマンドを参照してください。

    mysql> call mysql.rds_set_configuration('binlog retention hours', 24);
  6. RDS MySQL リードレプリカを作成します。詳細については、「リードレプリカの作成」と「MySQL リードレプリカの使用」を参照してください。
    デフォルトでは、リードレプリカはマスターインスタンスのパラメータグループを継承します。ベストプラクティスとして、マスターのカスタムパラメータグループの依存関係を削除する必要があります。マスター DB インスタンスに固有のマスター DB パラメータグループ内のパラメータに変更が発生した場合、その変更はそのパラメータグループに関連付けられているすべての DB インスタンスにも適用されます。
  7. リードレプリカの新しいカスタムパラメータグループを作成し、gtid-mode = ON と enforce_gtid_consistency = ON パラメータを設定します。
  8. インスタンスを変更して新しく作成したカスタムパラメータグループを関連付け、手動でインスタンスを再起動します。
    これで、RDS MySQL リードレプリカインスタンスは新しいカスタム DB パラメータグループを使用します。
  9. GTID ベースのレプリケーションが有効になっていて、マスター RDS MySQL と RDS MySQL リードレプリカ間でレプリケーションが期待どおりに機能していることを確認します。
    a.) マスターで、SHOW MASTER STATUS\G コマンドを入力し、Executed_Gtid_Set 列を確認します。これは、マスターで実行されたトランザクションの GTID を示します。次のコマンド出力を参照してください。 

    mysql> SHOW MASTER STATUS\G;
*************************** 1. row ***************************
File: mysql-bin-changelog.000038
Position: 194
Binlog_Do_DB: 
Binlog_Ignore_DB: 
Executed_Gtid_Set: 7d90b125-77f6-11e9-b3b1-02bb8ffa5a04:1-19

    b.) レプリカで、コマンド SHOW SLAVE STATUS\G を入力し、次の列を確認します。

    Slave_IO_Running: Yes
Slave_SQL_Running: Yes

    これらの値は、レプリケーションが期待どおりに機能していることを意味します。出力から Retrieved_Gtid_Set と Executed_Gtid_Set を調べることができます。次の出力例は、レプリカがトランザクションを取得し、マスターインスタンスで実行されたのと同じトランザクション (1〜19) を実行したことを示しています。

    mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Master_Log_File: mysql-bin-changelog.000038
Read_Master_Log_Pos: 194
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_Errno: 0
Last_Error: 
Master_Server_Id: 2052411434
Master_UUID: 7d90b125-77f6-11e9-b3b1-02bb8ffa5a04
Retrieved_Gtid_Set: 7d90b125-77f6-11e9-b3b1-02bb8ffa5a04:11-19
Executed_Gtid_Set: 7d90b125-77f6-11e9-b3b1-02bb8ffa5a04:1-19
Auto_Position: 1

    前の手順では、マスター RDS MySQL インスタンスと RDS MySQL リードレプリカ間のレプリケーションが GTID ベースのレプリケーションで設定されていることを確認します。

マスター (RDS MySQL) と新しいレプリカ (Aurora MySQL) 間の GTID ベースのレプリケーションの設定

マスター (RDS MySQL) と新しいレプリカ (Aurora MySQL) の間で GTID ベースのレプリケーションを設定するには、次の手順を実行します。

  1. マスター RDS MySQL DB インスタンスから Aurora リードレプリカを作成します。
    詳細については、「Aurora リードレプリカを使用して MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターにデータを移行する」と「RDS MySQL DB インスタンスから Amazon Aurora リードレプリカを作成する」を参照してください。 。
    デフォルトでは、Aurora クラスターはデフォルト設定 gtid-mode = OFF_PERMISSIVE のデフォルトパラメータグループを使用します。リードレプリカとして、設定は GTID のあるトランザクションとないトランザクションの両方を受け入れます。ただし、レプリケーショントポロジに従って、これはフォールバックオプションのターゲットマスターサーバーです。
  2. すべてのトランザクションに GTID があることを保証するには、カスタムクラスターパラメータグループを作成し、gtid-mode = ON と enforce_gtid_consistency = ON パラメータを設定します。
  3. クラスターを変更して、クラスターパラメータグループを新しく作成された Aurora クラスターに関連付けます。
  4. クラスターを手動で再起動します。
  5. GTID ベースのレプリケーションが有効になっていて、マスター RDS MySQL と Aurora リードレプリカ間でレプリケーションが期待どおりに機能しているかどうかを確認します。
    a.) マスターで SHOW MASTER STATUS\G; を入力し、Executed_Gtid_Set 列を確認します。この列には、マスターで実行されたトランザクションの GTID が表示されます。次のコマンド出力を参照してください。

    mysql> SHOW MASTER STATUS\G;
*************************** 1. row *************************
File: mysql-bin-changelog.000059
Position: 868
Binlog_Do_DB: 
Binlog_Ignore_DB: 
Executed_Gtid_Set: 7d90b125-77f6-11e9-b3b1-02bb8ffa5a04:1-46

    b.) レプリカで、SHOW SLAVE STATUS\G; と入力し、次の列を確認します。

    Slave_IO_Running: Yes
Slave_SQL_Running: Yes

    これらの値は、レプリケーションが期待どおりに機能していることを意味します。出力から Retrieved_Gtid_Set と Executed_Gtid_Set を調べることができます。次の出力例は、レプリカがトランザクションを取得し、マスターインスタンスで実行されたのと同じトランザクション (1〜46) を実行したことを示しています。

    mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Master_Log_File: mysql-bin-changelog.000059
Read_Master_Log_Pos: 868
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_Errno: 0
Last_Error:
Seconds_Behind_Master: 0
Master_Server_Id: 2052411434
Master_UUID: 7d90b125-77f6-11e9-b3b1-02bb8ffa5a04
Retrieved_Gtid_Set: 7d90b125-77f6-11e9-b3b1-02bb8ffa5a04:11-46
Executed_Gtid_Set: 7d90b125-77f6-11e9-b3b1-02bb8ffa5a04:1-46
Auto_Position: 1

    前の手順では、マスター RDS MySQL インスタンスと Aurora リードレプリカ間のレプリケーションが GTID ベースのレプリケーションで設定されていることを確認します。

既存のリードレプリカでの GTID ベースのレプリケーションの設定

このレプリケーショントポロジのすべてのインスタンスにはカスタムパラメータグループがあり、GTID ベースのレプリケーションを有効にするパラメータで設定されています。

デフォルトでは、RDS MySQL のリードレプリカを作成するとき、バイナリログファイルとそれらの位置を使用して、マスターとレプリカの間で同期されます。そのため、GTID ベースのレプリケーションを使用しないリードレプリカ (RDS MySQL および Aurora MySQL) を使用する既存の RDS MySQL DB インスタンスの場合、GTID ベースのレプリケーションを手動で設定する必要があります。

マスター (RDS MySQL) と既存のレプリカ (RDS MySQL および Aurora MySQL) の間で GTID レプリケーションを有効にする

マスター (RDS MySQL) と既存のレプリカ (RDS MySQL レプリカと Aurora MySQL レプリカ) の間で GTID レプリケーションを有効にするには、次の手順を実行します。

  1. RDS MySQL インスタンスのバージョンを確認します。
    RDS MySQL バージョン 5.7.22 以前を使用している場合は、RDS MySQL バージョンを 5.7.23 以降の MySQL 5.7 バージョンにアップグレードします。詳細については、「MySQL DB エンジンのアップグレード」を参照してください。
  2. Aurora DB クラスターのバージョンを確認する
    Aurora MySQL バージョンが 2.04 より低い場合、Aurora DB クラスターバージョンを 2.04 以降にアップグレードします。
  3. 不要になるまでマスターインスタンスでバイナリログを設定します。
    デフォルトでは、RDS MySQL インスタンスはできるだけ早くバイナリログをパージします。mysql_rds_set_configuration を使用してバイナリログ保持期間を設定し、binlog retention hours の設定パラメータと、マスター RDS MySQL インスタンスでバイナリログファイルを保持する時間数を指定します。MySQL DB インスタンスの場合、最大のバイナリログ保持時間は 168 (7 日間) です。次のコマンドを参照してください。

    mysql> call mysql.rds_set_configuration('binlog retention hours', 24);

    ベストプラクティスとして、マスターのカスタムパラメータグループの依存関係を削除する必要があります。

  4. マスター RDS MySQL インスタンスと RDS MySQL レプリカインスタンスに異なるカスタムパラメータグループを作成します。
  5. Aurora MySQL レプリカでは、カスタムクラスターパラメータグループを作成します。
  6. マスター RDS MySQL インスタンス、RDS MySQL リードレプリカ、および Aurora MySQL リードレプリカのカスタムパラメータグループを gtid-mode = OFF_PERMISSIVE と enforce_gtid_consistency = WARN で設定します。
  7. RDS DB インスタンスを変更して、パラメータグループをそれぞれ RDS インスタンスに関連付けます。
  8. DB インスタンスのデフォルトのパラメータグループ (マスター RDS MySQL、RDS MySQL リードレプリカ、Aurora MySQL レプリカ) を変更した後、DB インスタンスが新しいカスタムパラメータグループを使用する前にインスタンスを手動で再起動します。
  9. 次の手順に進む前に、エラーログに警告が生成されていないことを確認してください。
    警告がある場合は、GTID 互換機能のみを使用し、警告を生成しないようにアプリケーションを調整します。詳細については、MySQL ウェブサイトの「GTIDs を持ったレプリケーションの制限」を参照してください。
  10. エラーログに警告が生成されていないことを確認した後、gtid-mode = ON_PERMISSIVE と enforce_gtid_consistency = WARN で、マスター RDS MySQL とリードレプリカ (RDS MySQL リードレプリカ、および Aurora MySQL レプリカ) のパラメータグループを設定します。
  11. DB インスタンスがパラメータを使用できるように、インスタンスを手動で再起動します。
  12. GTID が割り当てられていないトランザクションがリレーログにないことを確認してください。
    これらの匿名トランザクションを検証するには、両方のリードレプリカ (RDS MySQL と Aurora MySQL) で次のコマンドを実行します。SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';。 次のコマンド出力を参照してください。

    mysql> SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
+-------------------------------------+-------+
| Variable_name                       | Value |
+-------------------------------------+-------+
| Ongoing_anonymous_transaction_count | 0     |
+-------------------------------------+-------+
  13. 匿名トランザクションがないことを確認した後、gtid_mode = ON と enforce_gtid_consistency = ON でマスターとリードレプリカのカスタムパラメータグループの GTID を設定します。
  14. インスタンスを手動で再起動します。
  15. 両方のリードレプリカに匿名トランザクションがないことを確認してください。
  16. 両方のリードレプリカで rds_set_master_auto_position を実行します。
    これにより、GTID ベースのレプリケーション方式を使用するようにレプリケーションモードが設定されます。次のコマンドを参照してください。

    mysql> CALL mysql.rds_set_master_auto_position (1);
  17. マスター RDS MySQL とリードレプリカ (RDS MySQL レプリカと Aurora MySQL レプリカ) に接続し、GTID が有効で、レプリケーションが期待どおりに機能していることを確認します。
    a.) マスターで SHOW MASTER STATUS\G; を入力し、Executed_Gtid_Set 列を確認します。この列には、マスターで実行されたトランザクションの GTID が表示されます。次のコマンド出力を参照してください。

    mysql> SHOW MASTER STATUS\G;
*************************** 1. row ***************************
File: mysql-bin-changelog.119716
Position: 194
Binlog_Do_DB: 
Binlog_Ignore_DB: 
Executed_Gtid_Set: d8e0b642-62b2-11e9-a674-06f30def75ee:1-5091

    b.) レプリカで、SHOW SLAVE STATUS\G; と入力し、次の列を確認します。

    Slave_IO_Running: Yes
Slave_SQL_Running: Yes

    これらの値は、レプリケーションが期待どおりに機能していることを意味します。出力から Retrieved_Gtid_Set と Executed_Gtid_Set を調べることができます。次の出力例は、レプリカサーバーがトランザクションを取得し、マスターインスタンスで実行されたのと同じトランザクション (1〜5091) を実行したことを示しています。

    mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Log_File: mysql-bin-changelog.119716
Read_Master_Log_Pos: 194
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_Errno: 0
Last_Error: 
Seconds_Behind_Master: 0
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Retrieved_Gtid_Set: d8e0b642-62b2-11e9-a674-06f30def75ee:5090-5091
Executed_Gtid_Set: d8e0b642-62b2-11e9-a674-06f30def75ee:1-5091
Auto_Position: 1

    前の手順では、マスター RDS MySQL とリードレプリカ (RDS MySQL リードレプリカと Aurora リードレプリカ) 間のレプリケーションが GTID ベースのレプリケーションで設定されていることを確認します。次の図は、この設定を示しています。

Aurora MySQL レプリカを新しいマスターインスタンスとフォールバックオプションとして設定する

レプリケーションはデフォルトでは非同期であるため、開始する前に、レプリケーションが同期していることを確認してください。レプリケーションラグは、主にシングルスレッドプロセスでレプリカに適用する必要があるマスター上の書き込みの量に基づいて変わる可能性があります。したがって、アプリケーションを停止し、レプリケーションが同期しているかどうかを確認することをお勧めします。

Aurora MySQL レプリカを新しいマスターインスタンスとフォールバックオプションとして設定するには、次の手順を実行します。

  1. インスタンスを読み取り専用として設定して、マスター RDS MySQL DB インスタンスに書き込みがないことを確認します。
    インスタンスを読み取り専用モードに設定するには、インスタンスに割り当てられているカスタムパラメータグループを変更します。read_only パラメータは、{TrueIfReplica} の値にデフォルト設定されます。このユースケースでは、この値を 1 に設定します。これは、インスタンスが読み取り専用モードであることを示します。このパラメータにはダイナミックな適用タイプがあります。つまり、変更はすぐに有効になり、再起動する必要はありません。
  2. 実行中のトランザクションが両方のレプリカインスタンス (Aurora MySQL レプリカと RDS MySQL レプリカ) に完全にレプリケートされるのを待ちます。
  3. 確認するには、レプリカインスタンスに接続し、比較的短い期間に SHOW SLAVE STATUS\G; を数回入力します。
  4. Slave_IO_State、Slave_IO_Running 、 Slave_SQL_Running 、 Slave_SQL_Running_State 、 Seconds_Behind_Master と Executed_Gtid_Set 列を確認します。
    出力から Executed_Gtid_Set を調べることができます。これは、レプリカが同期している場合、マスターの Executed_Gtid_Set と同じである必要があります。レプリカが RDS MySQL マスターと同期している場合、Seconds_Behind_Master は当然 0 になります。 SQL_IO_State と SQL_SQL_Running_State は、次のようになります。

    Slave_IO_Running: Yes
Slave_IO_State: Waiting for master to send event
Slave_SQL_Running: Yes
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

    詳細については、MySQL ウェブサイトの「レプリケーションスレーブ I/O スレッド状態」と「レプリケーションスレーブ SQL スレッド状態」を参照してください。

  1. レプリカが同期したら、Aurora MySQL を新しいマスターインスタンスとして設定し、RDS MySQL リードレプリカへのフォールバックオプションを設定します。
    次の図は、このアーキテクチャを示しています。

Aurora MySQL DB クラスターをマスターとして設定する

Aurora MySQL DB クラスターをマスターとして設定するには、次の手順を実行します。

  1. Aurora リードレプリカをスタンドアロン Aurora DB クラスターに昇格させます。
    詳細については、「Aurora リードレプリカの昇格」を参照してください。
  2. Aurora DB クラスターから RDS MySQL リードレプリカへの GTID ベースのレプリケーションを設定します。
    これを行うには、Aurora DB クラスターでバイナリログを有効にする必要があります。詳細については、「レプリケーションマスターでのバイナリログの有効化」を参照してください。
    クラスターパラメータグループを binlog_format =“ MIXED” で更新します (ROW や STATEMENT といった他の形式を使用することもできますが、MIXED と設定することをお勧めします)。詳細については、MySQL ウェブサイトの「バイナリログ形式の設定」と「ステートメントベースおよび行ベースのレプリケーションの利点と欠点」を参照してください。
  3. Aurora DB クラスターを再起動します。
  4. バイナリログが生成されていることを確認するには、Aurora クラスターに接続し、SHOW BINARY LOGS; と入力します。次のコマンド出力を参照してください。 
    mysql> SHOW BINARY LOGS;
+----------------------------+-----------+
| Log_name                   | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.000001 |       154 |
| mysql-bin-changelog.000002 |      3030 |
+----------------------------+-----------+
  5. Aurora クラスターに接続している間に、レプリケーションアカウントを作成します。次のコマンドを参照してください。 
    mysql> CREATE USER 'repl_user'@'<domain_name>' IDENTIFIED BY '<password>';

    セキュリティ上の理由から、このアカウントはレプリケーションにのみ使用してください。詳細については、MySQL ウェブサイトの「レプリケーション向けのユーザーの作成」を参照してください。

  6. レプリケーションユーザーに REPLICATION SLAVE 特権を付与します。次のコマンドを参照してください。 
    mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'<domain_name>' IDENTIFIED BY '<password>';

RDS MySQL リードレプリカインスタンスを Aurora MySQL DB クラスターのレプリカとして設定する

RDS MySQL リードレプリカインスタンスをフォールバックオプションのための Aurora MySQL DB クラスターのレプリカとして設定するには、次の手順を実行します。

  1. RDS MySQL リードレプリカをスタンドアロン DB インスタンスとして昇格させます。
  2. インスタンスを再起動します。
    詳細については、「リードレプリカをスタンドアロン DB インスタンスに昇格させる」を参照してください。
  3. マスターユーザーを使用して RDS MySQL リードレプリカに接続し、rds_set_external_master_with_auto_position を入力します。
    このストアドプロシージャが必要な変更を実行し、RDS MySQL リードレプリカが Aurora MySQL DB クラスターに接続して、バイナリログをリクエストできるようになります。さらに、グローバルトランザクション ID をベースに、レプリケーションも設定します。次のコマンドを参照してください。

    mysql> CALL mysql.rds_set_external_master_with_auto_position (AuroraClusterEndpoint',3306,'repl_user','password',0,0);
  4. リセットスレーブを実行して、古い参照をクリアします。次のコマンドを参照してください。 
    mysql> reset slave;

    詳細については、MySQL ウェブサイトの「リセットスレーブステートメント」を参照してください。

  5. ターゲット RDS MySQL リードレプリカでレプリケーションを開始します。次のコマンドを参照してください。 
    mysql> call mysql.rds_start_replication();

上記の手順では、新しいマスターインスタンス (Aurora MySQL) とレプリカインスタンス (RDS MySQL リードレプリカ) の間に GTID ベースのレプリケーションを設定します。

アプリケーションを切り替えて Aurora DB クラスターを使用する

これで、アプリケーションを切り替えて新しい Aurora MySQL マスターを使用する準備ができました。MySQL (RDS またはオンプレミス) から Aurora MySQL に移行する場合、Aurora は InnoDB ストレージエンジンを使用して MySQL (5.6 および 5.7) とワイヤー互換性があることを知っておくことが重要です。MySQL に現在使用しているほとんどのドライバー、コネクター、およびツールを、ほとんどまたはまったく変更せずに Aurora MySQL で使用できます。したがって、ほとんどのアプリケーションは、移行プロセス中にアプリケーションコードを変更することなく機能します。

Aurora DB クラスターを使用するようにアプリケーションを切り替えるには、次の手順を実行します。

  1. アプリケーションを新しい Aurora クラスターエンドポイントに向けます。これを行うには、アプリケーションで使用されているアプローチに応じて 2 つの方法があります。
  • Aurora クラスターエンドポイントを持つすべてのアプリケーションの接続文字列を変更します。
  • アプリケーションがデータベースエンジンのホスト名を指すカスタムの正規名 (CNAME) を使用している場合、Aurora クラスターエンドポイントでドメインネームシステム (DNS) の CNAME レコードを更新します。
  1. アプリケーションが Aurora DB クラスターを指したら、レプリケーションが期待どおりに実行されていることを確認します。
    a.) マスター Aurora DB クラスターで、SHOW MASTER STATUS\G; と入力し、Executed_Gtid_Set を確認します。次のコマンド出力を参照してください。

    mysql> SHOW MASTER STATUS\G;
*************************** 1. row ***************************
File: mysql-bin-changelog.000002
Position: 4615
Binlog_Do_DB: 
Binlog_Ignore_DB: 
Executed_Gtid_Set: 5c619be5-381d-3436-9104-3d8fbb228334:1-10,
7d90b125-77f6-11e9-b3b1-02bb8ffa5a04:1-24:26-46

    b.) スレーブ RDS リードレプリカで、SHOW SLAVE STATUS\G; と入力します。次のコマンド出力を参照してください。

    mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: AuroraClusterEndpoint.us-west-2.rds.amazonaws.com
Master_User: repl_user
Master_Port: 3306
Master_Log_File: mysql-bin-changelog.000002
Read_Master_Log_Pos: 4615
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_Errno: 0
Last_Error: 
Exec_Master_Log_Pos: 4615
Seconds_Behind_Master: 0
Master_UUID: 5c619be5-381d-3436-9104-3d8fbb228334
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Retrieved_Gtid_Set: 5c619be5-381d-3436-9104-3d8fbb228334:1-10
Executed_Gtid_Set: 5c619be5-381d-3436-9104-3d8fbb228334:1-10,
7d90b125-77f6-11e9-b3b1-02bb8ffa5a04:1-46
Auto_Position: 1

上記の結果から、次のパラメータは重要な情報を提供します。

  • Master_Host は、スレーブが新しく設定された Aurora DB クラスターにマスターとして接続されていることを確認します
  • Retrieved_Gtid_Set と Executed_Gtid_Set は、データがマスターからスレーブに期待どおりにレプリケートされていることを確認します
  • Exec_Master_Log_Pos は、スレーブがマスターのバイナリログ位置に自動配置されたことを示します

検証により、マスターインスタンス (Aurora MySQL) とレプリカインスタンス (RDS MySQL リードレプリカ) 間のレプリケーションが実行され、GTID ベースのレプリケーションで設定されていることが確認できました。

RDS MySQL レプリカにフォールバックする

フォールバックを設定するには、次の手順を実行します。

  1. アプリケーションを停止します。
  2. Aurora クラスターを読み取り専用として設定します。
    これにより、Aurora DB クラスターに書き込みがないことが保証されます。クラスターを読み取り専用に設定するには、クラスターに割り当てられているカスタムクラスターパラメータグループを変更します。read_only パラメータは、{TrueIfReplica} の値にデフォルト設定されます。このユースケースでは、この値を 1 に設定します。これは、Aurora MySQL Cluster が読み取り専用モードであることを示します。このパラメータにはダイナミックな適用タイプがあります。つまり、変更はすぐに有効になり、再起動する必要はありません。
  3. 実行中のトランザクションがレプリカ (RDS MySQL リードレプリカ) に完全にレプリケートされるのを待ちます。
  4. レプリケーションが同期していることを確認します。
  5. レプリカ (RDS MySQL リードレプリカ) に接続し、比較的短い期間に SHOW SLAVE STATUS\G; を数回入力します。
  6. Slave_IO_State、Slave_IO_Running 、 Slave_SQL_Running 、 Slave_SQL_Running_State 、 Seconds_Behind_Master と Executed_Gtid_Set 列を確認します。
    出力から Executed_Gtid_Set を調べることができます。これは、レプリカが同期している場合、マスターの Executed_Gtid_Set と同じである必要があります。レプリカが Aurora MySQL マスターと同期している場合、Seconds_Behind_Master は当然 0 になります。SQL_IO_State と SQL_SQL_Running_State は次のようになります。

    Slave_IO_Running: Yes
Slave_IO_State: Waiting for master to send event
Slave_SQL_Running: Yes
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

    レプリカがマスターインスタンスで最新であることを確認したら、レプリカ (RDS MySQL リードレプリカ) でレプリケーションを停止しても安全です。

  7. -CALL mysql.rds_stop_replication; と reset slave; のコマンドを実行します。
    これにより、マスター Aurora MySQL インスタンスからのレプリケーションが終了します。
    この時点で、RDS MySQL リードレプリカはスタンドアロン DB インスタンスです。フォールバックオプションとして、アプリケーションをスタンドアロン DB インスタンスのエンドポイントにリポイントできるようになりました。

まとめ

この記事では、RDS MySQL リードレプリカをロールバックオプションとして使用して、RDS MySQL インスタンスを Aurora MySQL DB クラスターに移行するプロセスを示しました。このシナリオでは GTID ベースのレプリケーションを使用して、複雑なレプリケーションストリームで整合性を保ち、バイナリログの自動配置を実施するなどの利点を活用しました。GTID ベースのレプリケーションを使用して、オンプレミスの MySQL または EC2 MySQL インスタンスを Amazon Aurora MySQL に移行することもできます。

 

著者について

 

Vijay Karumajji は、アマゾン ウェブ サービスのデータベースソリューションアーキテクトです。お客様と協力してデータベースプロジェクトに関する助言や技術支援を行い、AWS を使用する場面でソリューションの価値を向上させる手助けをしています。