MySQL リードレプリカの使用 - Amazon Relational Database Service
MySQL でのリードレプリカの設定MySQL でのレプリケーションフィルターの設定MySQL での遅延レプリケーションの設定MySQL でのリードレプリカの更新MySQL でのマルチ AZ リードレプリカのデプロイの使用カスケードリードレプリカの使用MySQL リードレプリカのモニタリングMySQL リードレプリカでのレプリケーションのスタートと停止MySQL リードレプリカに関する問題のトラブルシューティング

MySQL リードレプリカの使用

以下では、 MySQL の RDS でのリードレプリカの操作に関する特定の情報を確認することができます。リードレプリカと使用手順の概要については、「DB インスタンスのリードレプリカの操作」を参照してください。

MySQL でのリードレプリカの設定

MySQL DB インスタンスがレプリケーションのソースとして機能するには、ソースの DB インスタンスで自動バックアップを有効にする必要があります。これを行うには、バックアップ保持期間の値を 0 以外の値に設定します。この要件は、別のリードレプリカのソース DB インスタンスであるリードレプリカにも適用されます。自動バックアップは、MySQL の任意のバージョンを実行するリードレプリカでサポートされています。レプリケーションは、MySQL DB インスタンスのバイナリログ座標に基づいて設定できます。

RDS for MySQL バージョン 5.7.37 以降の MySQL 5.7 バージョンおよび RDS for MySQL 8.0.28 以降の 8.0 バージョンでは、グローバルトランザクション識別子 (GTID) を使用してレプリケーションを設定できます。詳細については、「Amazon RDS for MySQL の GTID ベースレプリケーションを使用する」を参照してください。

同一リージョン内の 1 つの DB インスタンスから、最大 15 個のリードレプリカを作成できます。レプリケーションを効率的に実行するには、各リードレプリカにソース DB インスタンスと同程度のコンピューティングリソースとストレージリソースが必要です。ソースの DB インスタンスをスケールした場合は、リードレプリカもスケールする必要があります。

RDS for MySQL では、リードレプリカのカスケードをサポートしています。リードレプリカのカスケードを設定する方法については、「RDS for MySQL でのカスケードリードレプリカの使用」を参照してください。

同じソースの DB インスタンスを参照する複数のリードレプリカの作成や削除の操作は同時に実行できます。その操作を実行するには、ソースインスタンスごとに作成できるリードレプリカを 15 個に制限します。

MySQL DB インスタンスのリードレプリカは、ソース DB インスタンスよりも低い DB エンジンバージョンを使用できません。

MyISAM を使用する MySQL DB インスタンスを準備する

MySQL DB インスタンスで MyISAM などの非トランザクションエンジンを使用する場合は、以下のステップに従ってリードレプリカを設定する必要があります。このステップは、リードレプリカとデータの整合性を保つために必要です。すべてのテーブルが InnoDB などのトランザクションエンジンを使用している場合には、このステップは必要ありません。

  1. ソース DB インスタンスの非トランザクションテーブルのすべてのデータ操作言語 (DML) とデータ定義言語 (DDL) の操作を停止します。SELECT 記述で実行を続けます。

  2. ソース DB インスタンスでテーブルをフラッシュおよびロックします。

  3. 以下のセクションのいずれかの方法を使用してリードレプリカを作成します。

  4. DescribeDBInstances API オペレーションなどを使用して、リードレプリカの作成の進捗状況を確認します。リードレプリカが使用可能になったら、ソース DB インスタンスのテーブルのロックを解除し、通常のデータベース操作を再開します。

MySQL でのレプリケーションフィルターの設定

レプリケーションフィルターを使用して、リードレプリカでレプリケートするデータベースとテーブルを指定できます。レプリケーションフィルターは、データベースとテーブルをレプリケーションに含めることも、レプリケーションから除外することもできます。

レプリケーションフィルターの使用例は以下のとおりです。

  • リードレプリカのサイズを縮小します。レプリケーションフィルタリングを使用すると、リードレプリカで必要のないデータベースとテーブルを除外できます。

  • セキュリティ上の理由から、データベースとテーブルをリードレプリカから除外するため。

  • 異なるリードレプリカで、特定のユースケースごとにさまざまなデータベースとテーブルを複製するため。例えば、分析やシャーディングに特定のリードレプリカを使用できます。

  • 異なる AWS リージョン にリードレプリカがある DB インスタンスで、異なる AWS リージョン に異なるデータベースまたはテーブルを複製する場合。

注記

また、レプリケーションフィルターを使用して、インバウンドのレプリケーショントポロジでレプリカとして設定されているプライマリ MySQL DB インスタンスでレプリケートするデータベースとテーブルを指定することもできます。この設定の詳細については、「外部のソースインスタンスを使用したバイナリログファイル位置のレプリケーションの設定」を参照してください。

RDS for MySQL のレプリケーションフィルターパラメータの設定

レプリケーションフィルターを構成するには、リードレプリカに次のレプリケーションフィルターのパラメータを設定します。

  • replicate-do-db - 指定したデータベースに変更を複製します。リードレプリカに対してこのパラメータを設定すると、パラメータで指定されたデータベースのみが複製されます。

  • replicate-ignore-db - 指定したデータベースに変更を複製しないでください。リードレプリカに replicate-do-db パラメータが設定されている場合、このパラメータは評価されません。

  • replicate-do-table -指定されたテーブルに変更を複製します。このパラメータをリードレプリカに設定した場合、パラメータで指定したテーブルのみが複製されます。また、replicate-do-db または replicate-ignore-db パラメータが設定されている場合は、指定されたテーブルを含むデータベースを、必ずリードレプリカのレプリケーションに含めます。

  • replicate-ignore-table - 指定したテーブルに変更を複製しないでください。リードレプリカに replicate-do-table パラメータが設定されている場合、このパラメータは評価されません。

  • replicate-wild-do-table - 指定したデータベースおよびテーブル名のパターンに基づいてテーブルを複製します。% および _ ワイルドカードの文字がサポート対象となります。replicate-do-db または replicate-ignore-db パラメータが設定されている場合は、リードレプリカを使用して、指定したテーブルを含むデータベースをレプリケーションに含めるようにしてください。

  • replicate-wild-ignore-table - 指定したデータベースおよびテーブル名のパターンに基づいてテーブルを複製しないでください。% および _ ワイルドカードの文字がサポート対象となります。リードレプリカに replicate-do-table または replicate-wild-do-table パラメータが設定されている場合、このパラメータは評価されません。

パラメータは、記載されている順序に沿って評価されます。これらのパラメータの詳細な仕組みについては、MySQL のドキュメントを参照してください。

デフォルトでは、これらの各パラメータの値は空です。各リードレプリカで、これらのパラメータを使用してレプリケーションフィルターを設定、変更、削除することができます。これらのパラメータの 1 つを設定する場合は、各フィルターを他のフィルターとコンマで区切ります。

% および _ パラメータで replicate-wild-do-table および replicate-wild-ignore-table ワイルドカードの文字を使用できます。% ワイルドカードは任意の文字数と一致し、_ ワイルドカードは 1 文字のみと一致します。

ソース DB インスタンスのバイナリログ形式は、データ変更のレコードを決定するため、レプリケーションでは重要です。binlog_format パラメータの設定により、レプリケーションが行ベースかステートメントベースかが決まります。詳細については、「 MySQL バイナリログの設定」を参照してください。

注記

ソース DB インスタンスの binlog_format 設定に関係なく、すべてのデータ定義言語 (DDL) ステートメントはステートメントとして複製されます。

RDS for MySQL のレプリケーションフィルターの制限

RDS for MySQL のレプリケーションフィルターには、次の制限が適用されます。

  • 各レプリケーションフィルターのパラメータには、2,000 文字といった制限があります。

  • レプリケーションフィルターでは、カンマはサポートされていません。

  • MySQL --binlog-do-db とバイナリログフィルターの --binlog-ignore-db オプションはサポートされていません。

  • レプリケーションフィルタリングは、XA トランザクションをサポートしていません。

    詳細については、MySQL ドキュメントの「XA トランザクションの制限」を参照してください。

RDS for MySQL のレプリケーションフィルターの例

リードレプリカのレプリケーションフィルタリングを構成するには、リードレプリカに関連付けられているパラメータグループのレプリケーションフィルタリングパラメータを変更します。

注記

デフォルトのパラメータグループを変更することはできません。リードレプリカがデフォルトのパラメータグループを使用している場合は、新しいパラメータグループを作成してリードレプリカに関連付けます。DB パラメータグループの詳細については、「パラメータグループを使用する」を参照してください。

AWS Management Console、AWS CLI、または RDS API を使用して、パラメータグループのパラメータを設定できます。パラメータの設定の詳細については、「DB パラメータグループのパラメータの変更」を参照してください。パラメータグループにパラメータを設定すると、そのパラメータグループに関連付けられているすべての DB インスタンスでパラメータ設定を使用します。パラメータグループにレプリケーションフィルターのパラメータを設定する場合は、パラメータグループがリードレプリカにのみ関連付けられていることを確認してください。ソース DB インスタンスのレプリケーションフィルターのパラメータは空のままにします。

次の例では、AWS CLI を使用してパラメータを設定します。これらの例では、CLI コマンドが完了した直後にパラメータの変更が行われるように ApplyMethod を immediate に設定しています。リードレプリカの再起動後に保留中の変更を適用する場合は、ApplyMethod を pending-reboot に設定します。

以下の例では、レプリケーションフィルターを設定します。

例 レプリケーションにデータベースを含める

次の例では、レプリケーションに mydb1 データベースと mydb2 データベースが含まれています。

Linux、macOS、Unix の場合:

aws rds modify-db-parameter-group \
  --db-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"

Windows の場合:

aws rds modify-db-parameter-group ^
  --db-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"
例 レプリケーションにテーブルを含める

次の例には、レプリケーションのデータベース table1 の table2 テーブルと mydb1 テーブルが含まれています。

Linux、macOS、Unix の場合:

aws rds modify-db-parameter-group \
  --db-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"

Windows の場合:

aws rds modify-db-parameter-group ^
  --db-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"
例 ワイルドカードの文字を使用してレプリケーションにテーブルを含める

次の例には、レプリケーションのデータベース order の return および mydb で始まる名前のテーブルが含まれています。

Linux、macOS、Unix の場合:

aws rds modify-db-parameter-group \
  --db-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"

Windows の場合:

aws rds modify-db-parameter-group ^
  --db-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"
例 レプリケーションからデータベースを除外する

次の例では、mydb5 データベースと mydb6 データベースをレプリケーションから除外しています。

Linux、macOS、Unix の場合:

aws rds modify-db-parameter-group \
  --db-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate"

Windows の場合:

aws rds modify-db-parameter-group ^
  --db-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate"
例 レプリケーションからテーブルを除外する

次の例では、データベース mydb5 のテーブル table1 とデータベース mydb6 の table2 をレプリケーションから除外しています。

Linux、macOS、Unix の場合:

aws rds modify-db-parameter-group \
  --db-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"

Windows の場合:

aws rds modify-db-parameter-group ^
  --db-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"
例 ワイルドカードの文字を使用したレプリケーションからテーブルを除外する

次の例では、データベース order の return および mydb7 で始まる名前のテーブルをレプリケーションから除外しています。

Linux、macOS、Unix の場合:

aws rds modify-db-parameter-group \
  --db-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"

Windows の場合:

aws rds modify-db-parameter-group ^
  --db-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"

リードレプリカのレプリケーションフィルターを表示する

リードレプリカのレプリケーションフィルターは、次の方法で表示できます。

  • リードレプリカに関連付けられているパラメータグループのレプリケーションフィルタリングパラメータの設定を確認してください。

    手順については、「DB パラメータグループのパラメータ値を表示する」を参照してください。

  • MySQL クライアントで、リードレプリカに接続し、SHOW REPLICA STATUS ステートメントを実行します。

    出力の次のフィールドには、リードレプリカのレプリケーションフィルターが表示されます。

    • Replicate_Do_DB

    • Replicate_Ignore_DB

    • Replicate_Do_Table

    • Replicate_Ignore_Table

    • Replicate_Wild_Do_Table

    • Replicate_Wild_Ignore_Table

    これらのフィールドの詳細については、MySQL のドキュメントの Checking Replication Status を参照してください。

    注記

    MySQL の旧バージョンは、SHOW SLAVE STATUS ではなく SHOW REPLICA STATUS を使用していました。8.0.23 より前の MySQL バージョンを使用している場合は、SHOW SLAVE STATUS を使用します。

MySQL での遅延レプリケーションの設定

遅延レプリケーションは、災害対策用の戦略として使用できます。遅延レプリケーションでは、ソースからリードレプリカへのレプリケーションを遅延させる最小時間を秒数で指定します。障害発生時 (意図しないテーブルの削除など) には、以下のステップを実行して障害から早急に復旧します。

  • 障害を起こした変更がリードレプリカに送られる前に、リードレプリカへのレプリケーションを停止します。

    レプリケーションを停止するには、mysql.rds_stop_replication ストアドプロシージャを使用します。

  • レプリケーションをスタートし、レプリケーションがログファイルの場所で自動的に停止するように指定します。

    障害発生の直前の場所を指定するには、mysql.rds_start_replication_until ストアドプロシージャを使用します。

  • 「リードレプリカをスタンドアロン DB インスタンスに昇格させる」の手順を使用してリードレプリカを新しい出典の DB インスタンスに昇格させます。

注記

  • RDS for MySQL 8.0 の場合、遅延レプリケーションは MySQL 8.0.28 以降でサポートされています。RDS for MySQL 5.7 の場合、遅延レプリケーションは MySQL 5.7.37 以降でサポートされています。

  • 遅延レプリケーションを設定するには、ストアドプロシージャを使用します。遅延レプリケーションを AWS Management Console、AWS CLI、または Amazon RDS API で設定することはできません。

  • RDS for MySQL 5.7.37 以降の MySQL 5.7 バージョンおよび RDS for MySQL 8.0.28 以降の 8.0 バージョンでは、遅延レプリケーション構成でグローバルトランザクション識別子 (GTID) に基づくレプリケーションを使用できます。GTID ベースのレプリケーションを使用する場合は、mysql.rds_start_replication_until_gtid ストアドプロシージャの代わりに、mysql.rds_start_replication_until ストアドプロシージャを実行します。GTID ベースのレプリケーションの詳細については、「Amazon RDS for MySQL の GTID ベースレプリケーションを使用する」を参照してください。

リードレプリカ作成時の遅延レプリケーションの設定

DB インスタンスから今後作成するリードレプリカの遅延レプリケーションを設定するには、mysql.rds_set_configuration パラメータを指定して target delay ストアドプロシージャを実行します。

リードレプリカの作成時に遅延レプリケーションを設定するには

  1. MySQL クライアントを使用し、マスターユーザーとして、リードレプリカのソースとなる MySQL DB インスタンスに接続します。

  2. mysql.rds_set_configuration パラメータを指定して target delay ストアドプロシージャを実行します。

    例えば、現在の DB インスタンスから作成されるリードレプリカへのレプリケーションを少なくとも 1 時間 (3600 秒) 遅延させるように指定するには、次のストアドプロシージャを実行します。

    call mysql.rds_set_configuration('target delay', 3600);
    注記

    このストアドプロシージャを実行すると、AWS CLI または Amazon RDS API を使用して作成したリードレプリカには、指定した秒数で遅延するレプリケーションが設定されます。

既存のリードレプリカの遅延レプリケーションの変更

既存のリードレプリカの遅延レプリケーションを変更するには、mysql.rds_set_source_delay ストアドプロシージャを実行します。

既存のリードレプリカの遅延レプリケーションを変更するには

  1. MySQL クライアントを使用して、マスターユーザーとしてリードレプリカに接続します。

  2. レプリケーションを停止するには、mysql.rds_stop_replication ストアドプロシージャを使用します。

  3. mysql.rds_set_source_delay ストアドプロシージャを実行します。

    例えば、リードレプリカへのレプリケーションを少なくとも 1 時間 (3600 秒) 遅延させるように指定するには、次のストアドプロシージャを実行します。

    call mysql.rds_set_source_delay(3600);

  4. mysql.rds_start_replication ストアドプロシージャを使用してレプリケーションをスタートします。

リードレプリカへのレプリケーションを停止する場所の設定

リードレプリカへのレプリケーションが停止したら、mysql.rds_start_replication_until ストアドプロシージャを使用してレプリケーションをスタートしてバイナリログファイルの指定した位置で停止できます。

リードレプリカへのレプリケーションをスタートして指定の位置でレプリケーションを停止するには

  1. MySQL クライアントを使用して、マスターユーザーとしてソース MySQL DB インスタンスに接続します。

  2. mysql.rds_start_replication_until ストアドプロシージャを実行します。

    次の例では、レプリケーションをスタートし、120 バイナリログファイルの場所 mysql-bin-changelog.000777 に達するまで変更をレプリケートします。災害対策シナリオでは、場所 120 は災害発生直前の時点として想定されます。

    call mysql.rds_start_replication_until(
  'mysql-bin-changelog.000777',
  120);

停止ポイントに達すると、レプリケーションは自動的に停止します。RDS イベントとして、Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure が生成されます。

リードレプリカの昇格

レプリケーションが停止したら、災害対策シナリオでリードレプリカを新しいソース DB インスタンスに昇格させます。リードレプリカの昇格については、「リードレプリカをスタンドアロン DB インスタンスに昇格させる」を参照してください。

MySQL でのリードレプリカの更新

リードレプリカは読み取りクエリをサポートするように設計されていますが、ときどき更新が必要になることがあります。例えば、インデックスを追加して、レプリカにアクセスする特定のタイプのクエリを最適化する必要が生じることがあります。更新を有効にするには、リードレプリカの DB パラメータグループで read_only パラメータを 0 に設定します。リードレプリカとソースの DB インスタンスの互換性がなくなると問題が発生する可能性があるため、リードレプリカで読み取り専用を無効にする場合は注意してください。read_only パラメータの値を可能な限り早く、1 に戻します。

MySQL でのマルチ AZ リードレプリカのデプロイの使用

リードレプリカは、シングル AZ DB インスタンス配置からもマルチ AZ DB インスタンス配置からも作成できます。重要なデータの耐久性の高いと可用性を高めるにはマルチ AZ 配置を使用しますが、読み取り専用クエリを処理するためにマルチ AZ セカンダリを使用することはできません。代わりに、トラフィックの多いマルチ AZ DB インスタンスのリードレプリカを作成して、読み取り専用クエリをオフロードできます。マルチ AZ 配置のソースのインスタンスがセカンダリにフェイルオーバーすると、関連付けられているすべてのリードレプリカが (プライマリから) セカンダリをレプリケーションのソースとして使用するように自動的に切り替わります。詳細については、「マルチ AZ 配置の設定と管理」を参照してください。

リードレプリカは、マルチ AZ DB インスタンスとして作成できます。Amazon RDS では、レプリカのフェイルオーバーをサポートするため、別のアベイラビリティーゾーンにレプリカのスタンバイを作成します。リードレプリカは、ソースのデータベースがマルチ AZ DB インスタンスであるかどうかに関係なく、マルチ AZ DB インスタンスとして作成できます。

RDS for MySQL でのカスケードリードレプリカの使用

RDS for MySQL では、リードレプリカのカスケードをサポートしています。カスケードリードレプリカにより、ソースの RDS for MySQL DB インスタンスにオーバーヘッドを追加せずに読み取りをスケーリングできます。

カスケードリードレプリカを使用すると、RDS for MySQL DB インスタンスは、チェーン内の最初のリードレプリカにデータを送信します。その後、そのリードレプリカは、チェーン内の 2 番目のレプリカにデータを送信し、その動作が順に続いていきます。その結果、チェーン内のすべてのリードレプリカに RDS for MySQL DB インスタンスの更新が送信されますが、ソース DB インスタンスでのオーバーヘッドは発生しません。

ソースの RDS for MySQL DB インスタンスから、チェーン内にリードレプリカを 3 層まで作成できます。例えば、RDS for MySQL DB インスタンス、mysql-main があるとします。以下の操作を行うことができます。

  • mysql-main で開始し、チェーン内に最初のリードレプリカ、read-replica-1 を作成します。

  • 次に、read-replica-1 で、チェーン内に次のリードレプリカ、read-replica-2 を作成します。

  • 最後に、read-replica-2 で、チェーン内に 3 番目のリードレプリカ、read-replica-3 を作成します。

mysql-main の層では、この 3 番目のカスケードリードレプリカに続く、別のリードレプリカを作成することはできません。一連の完全なインスタンス (RDS for MySQL のソース DB インスタンスから、この層の最後のカスケードリードレプリカまで) は、最大 4 つの DB インスタンスで構成できます。

リードレプリカのカスケードを設定するには、RDS for MySQL DB インスタンスで自動バックアップを有効にします。リードレプリカで自動バックアップを有効にするには、まずリードレプリカを作成し、次に自動バックアップを有効にするようにリードレプリカを変更します。詳細については、「リードレプリカの作成」を参照してください。

他のリードレプリカと同様に、カスケードの一部となっているリードレプリカを昇格できます。リードレプリカのチェーン内でリードレプリカを昇格させると、そのレプリカはチェーンから削除されます。例えば、mysql-main DB インスタンスのワークロードの一部を、経理部のみが使用する新しいインスタンスに移動するとします。この例では、3 つのリードレプリカから成るチェーンがある仮定し、read-replica-2 を昇格させることにします。チェーンは以下のような影響を受けます。

  • 昇格する read-replica-2 は、レプリケーションチェーンから削除されます。

    • このリードレプリカは、完全な読み取り/書き込み DB インスタンスになります。

    • 昇格前と同じように、read-replica-3 へのレプリケーションを継続します。

  • mysql-main は、read-replica-1 へのレプリケーションを継続します。

リードレプリカの昇格についての詳細は、「リードレプリカをスタンドアロン DB インスタンスに昇格させる」を参照してください。

MySQL リードレプリカのモニタリング

MySQL のリードレプリカでは、Amazon CloudWatch で Amazon RDS の ReplicaLag メトリクスを確認することでレプリケーションの遅延をモニタリングできます。ReplicaLag メトリクスには、Seconds_Behind_Master コマンドの SHOW REPLICA STATUS フィールドの値が報告されます。

注記

MySQL の旧バージョンは、SHOW SLAVE STATUS ではなく SHOW REPLICA STATUS を使用していました。8.0.23 より前の MySQL バージョンを使用している場合は、SHOW SLAVE STATUS を使用します。

MySQL のレプリケーション遅延の一般的な原因は以下のとおりです。

  • ネットワークが停止している。

  • リードレプリカとインデックスが異なるテーブルに書き込んでいる。リードレプリカで、read_only パラメータが 0 に設定されている場合、リードレプリカとソースの DB インスタンスの互換性がなくなると、レプリケーションが中断する可能性があります。リードレプリカのメンテナンスタスクを実行したら、read_only パラメータは 1 に戻すことをお勧めします。

  • MyISAM などの非トランザクションストレージエンジンを使用している。レプリケーションは、MySQL 上の InnoDB ストレージエンジンでのみサポートされます。

ReplicaLag メトリックが 0 に達すると、レプリカがソース DB インスタンスに追いついています。ReplicaLag メトリックにより -1 が返された場合、レプリケーションは現在アクティブではありません。ReplicaLag​ = -1 は Seconds_Behind_Master = NULL と同等です。

MySQL リードレプリカでのレプリケーションのスタートと停止

システムのストアドプロシージャ mysql.rds_stop_replication および mysql.rds_start_replication を呼び出すことにより、Amazon RDS DB インスタンスでレプリケーションプロセスを停止して再スタートすることができます。これは、大きいインデックスの作成など、長時間実行されている操作の 2 つの Amazon RDS インスタンス間でレプリケーションするときに実行できます。レプリケーションは、データベースをインポートまたはエクスポートするときに停止してスタートする必要もあります。詳細については、「ダウンタイムを短縮して Amazon RDS MariaDB または MySQL データベースにデータをインポートする」および「レプリケーションを使用した MySQL DB インスタンスからのデータのエクスポート」を参照してください。

レプリケーションを手動で停止するかレプリケーションエラーで停止してから連続して 30 日を超えると、Amazon RDS はソースの DB インスタンスとすべてのリードレプリカの間のレプリケーションを終了します。これは、ソース DB インスタンスでの所要ストレージの増大と長期間のフェイルオーバーを防ぐためです。リードレプリカの DB インスタンスは引き続き使用できます。ただし、レプリケーションが終了されるとリードレプリカに必要なバイナリログがソースの DB インスタンスから削除されるため、レプリケーションを再開することはできません。レプリケーションを再度行うには、ソースの DB インスタンスの新しいリードレプリカを作成します。

MySQL リードレプリカに関する問題のトラブルシューティング

MySQL DB インスタンスでは、リードレプリカとソース DB インスタンスの間のレプリケーションエラーやデータの不整合 (またはその両方) がリードレプリカで発生する場合があります。この問題は、リードレプリカまたはソースの DB インスタンスの障害時に、一部のバイナリログ (binlog) イベントまたは InnoDB redo ログがフラッシュされない場合に発生します。その場合、リードレプリカを手動で削除して作成し直します。次のパラメータ値 (sync_binlog=1、innodb_flush_log_at_trx_commit=1) を設定することで、これが発生する可能性を減らすことができます。これらの設定によりパフォーマンスが低下することがあるため、本稼働環境で変更を実装する前に影響をテストしてください。

警告

ソース DB インスタンスに関連付けられたパラメータグループでは、パラメータ値 sync_binlog=1 および innodb_flush_log_at_trx_commit=1 を保持することをお勧めします。これらのパラメータは動的です。これらの設定を使用しない場合、ソース DB インスタンスで再起動する可能性のある操作を実行する前に、これらの値を一時的に設定することをお勧めします。該当する操作には、再起動、フェイルオーバーによる再起動、データベースバージョンのアップグレード、DB インスタンスクラスまたはそのストレージの変更が含まれますが、これらに限定されません。同じ推奨事項が、ソース DB インスタンスの新しいリードレプリカを作成する場合にも適用されます。

このガイダンスに従わない場合、リードレプリカとソースの DB インスタンス間のレプリケーションエラーやデータの不整合 (またはその両方) がリードレプリカで発生するリスクが高くなります。

MySQL のレプリケーションテクノロジーは非同期です。非同期であるため、ソースの DB インスタンスの BinLogDiskUsage やリードレプリカの ReplicaLag が増加する場合があります。例えば、ソース DB インスタンスへの大量の書き込みオペレーションは並行して実行できます。一方、リードレプリカへの書き込みオペレーションは単一の I/O スレッドでシリアルで行われるため、ソースのインスタンスとリードレプリカの間で遅延が発生する場合があります。読み取り専用レプリカの詳細については、MySQL ドキュメントの「レプリケーション実装の詳細」を参照してください。

ソースの DB インスタンスに対する更新とそれに続くリードレプリカに対する更新の間の遅延を低減するには、次のいくつかの方法があります。

  • ストレージサイズと DB インスタンスクラスがソース DB インスタンスと同程度となるようにリードレプリカのサイズを決定します。

  • ソース DB インスタンスとリードレプリカにより使用される DB パラメータグループのパラメータ設定に互換性を確保します。詳細と例については、このセクションの後方にある max_allowed_packet パラメータの説明を参照してください。

Amazon RDS は、リードレプリカのレプリケーションの状態をモニタリングし、何らかの理由でレプリケーションが停止した場合はリードレプリカのインスタンスの Replication State フィールドを Error に更新します。これには、リードレプリカで実行された DML クエリがソースの DB インスタンスで行われた更新と競合した場合などがあります。

Replication Errorフィールドを参照することで、MySQL エンジンによりスローされた関連するエラーの詳細を確認できます。リードレプリカのステータスを示すイベントが生成されます (RDS-EVENT-0045、RDS-EVENT-0046、RDS-EVENT-0047 など)。イベントについてとイベントへのサブスクライブの詳細については、「Amazon RDS イベント通知の操作」を参照してください。MySQL のエラーメッセージが返された場合は、MySQL のエラーメッセージのドキュメントでエラー番号を確認してください。

レプリケーションエラーを引き起こす一般的な問題は、リードレプリカの max_allowed_packet パラメータの値がソース DB インスタンスの max_allowed_packet パラメータより小さいことです。max_allowed_packet パラメータは、DB パラメータグループで設定できるカスタムパラメータです。max_allowed_packet は、データベースで実行できる DML コードの最大サイズを指定するために使用します。場合によっては、リードレプリカに関連付けらている DB パラメータグループの max_allowed_packet の値が、ソース DB インスタンスに関連付けられている DB パラメータグループの max_allowed_packet の値より小さいことがあります。このような場合、レプリケーションプロセスは Packet bigger than 'max_allowed_packet' bytes エラーをスローし、レプリケーションを停止する可能性があります。このエラーを修正するには、ソース DB インスタンスとリードレプリカの DB パラメータグループで max_allowed_packet パラメータに同じ値を使用します。

レプリケーションエラーを引き起こす可能性があります他の一般的な状況は次のとおりです。

  • リードレプリカのテーブルに書き込んでいる。場合によっては、リードレプリカにソースの DB インスタンスのインデックスとは異なるインデックスを作成することがあります。その場合は、read_only パラメータを 0 に設定してインデックスを作成してください。リードレプリカのテーブルに書き込む場合、リードレプリカとソースの DB インスタンスの互換性がなくなると、レプリケーションが中断する可能性があります。リードレプリカのメンテナンスタスクを実行したら、read_only パラメータは 1 に戻すことをお勧めします。

  • MyISAM などの非トランザクションストレージエンジンを使用している。リードレプリカにはトランザクションストレージエンジンが必要です。レプリケーションは、MySQL 上の InnoDB ストレージエンジンでのみサポートされます。

  • SYSDATE() など、安全でない非決定的クエリを使用している。詳細については、「バイナリロギングでの安全および安全でないステートメントの判断」を参照してください。

エラーを安全にスキップできると判断した場合、「現在のレプリケーションエラーのスキップ」セクションで説明されているステップに従うことができます。そうでない場合は、まずリードレプリカを削除します。その上で、同じ DB インスタンス識別子を使用してインスタンスを作成することで、エンドポイントを前のリードレプリカと同じままにすることができます。レプリケーションエラーが解決すると、[Replication State] は [Replicating] に変化します。