Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション) - Amazon Aurora
MySQL または別の Aurora DB クラスターとのレプリケーションの設定Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーションの停止Amazon Aurora を使用した MySQL データベースの読み取りスケーリングバイナリログのレプリケーションの最適化

Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)

Amazon Aurora MySQL は MySQL と互換性があるため、MySQL データベースと Amazon Aurora MySQL DB クラスターとの間のレプリケーションを設定できます。このタイプのレプリケーションでは、MySQL バイナリログレプリケーションが使用され、バイナリログレプリケーションとも呼ばれます。Aurora でバイナリログレプリケーションを使用する場合は、MySQL データベースで MySQL バージョン 5.5 以降を実行することをお勧めします。Aurora MySQL DB クラスターがレプリケーションソースまたはレプリカである場合は、レプリケーションを設定できます。Amazon RDS MySQL DB インスタンス、Amazon RDS の外部の MySQL データベース、または別の Aurora MySQL DB クラスターを使用してレプリケートできます。

また、別の AWS リージョンで RDS for MySQL DB インスタンス、または Aurora MySQL DB クラスターにレプリケートすることもできます。AWS リージョン間のレプリケーションを実行するときは、DB クラスターと DB インスタンスがパブリックにアクセス可能であることを確認してください。Aurora MySQL DB クラスターは、VPC のパブリックサブネットの一部である必要があります。

Aurora MySQL DB クラスターと Aurora MySQL DB クラスター間のレプリケーションを別のリージョンに設定する場合、Aurora MySQL DB クラスターをソース DB クラスターとは異なる AWS リージョン内のリードレプリカとして作成できます。詳細については、「AWS リージョン間での Amazon Aurora MySQL DB クラスターのレプリケーション」を参照してください。

Aurora MySQL 2.04 以上では、レプリケーションにグローバルトランザクション識別子 (GTID) を使用するソースまたはターゲットと Aurora MySQL との間でレプリケートできます。Aurora MySQL DB クラスターの GTID 関連のパラメータ内に、外部データベースの GTID ステータスと互換性がある設定が含まれていることを確認してください。これを行う方法については、「Aurora MySQL の GTID ベースレプリケーションを使用する」を参照してください。

警告

Aurora MySQL と MySQL との間でレプリケートする場合は、必ず InnoDB テーブルのみを使用します。MyISAM テーブルをレプリケートする場合は、これらのテーブルを以下のコマンドを使用して InnoDB に変換してから、レプリケーションを設定できます。 

alter table <schema>.<table_name> engine=innodb, algorithm=copy;

Aurora MySQL と MySQL との間でレプリケーションを設定するには、次のステップを使用します。各ステップについて以下に詳しく説明します。

1.レプリケーションソースのバイナリログ記録を有効にする

2.レプリケーションソースのバイナリログを不要になるまで保持する

3.レプリケーションソースのスナップショットを作成する

4.レプリカターゲットにスナップショットをロードする

5.レプリカターゲットでレプリケーションを有効にする

6.レプリカをモニタリングする

MySQL または別の Aurora DB クラスターとのレプリケーションの設定

MySQL を使用して Aurora レプリケーションをセットアップするには、次のステップに従います。

1.レプリケーションソースのバイナリログ記録を有効にする

以下のデータベースエンジンのバイナリログ記録をレプリケーションソースで有効にする手順を確認します。

データベースエンジン Instructions

Aurora

Aurora MySQL DB クラスターのバイナリログ記録を有効にするには

binlog_format パラメータを ROW、STATEMENT、または MIXED に設定します。特定のバイナリログ形式の必要性がない限り MIXED をお勧めします。binlog_format パラメータはクラスターレベルのパラメータであり、デフォルトクラスターパラメータグループにあります。log_bin パラメータを OFF から別の値に変更した場合、変更を有効にするために Aurora DB クラスターを再起動する必要があります。

詳細については、「Amazon Aurora の DB クラスターパラメータと DB インスタンスパラメータ」および「DB パラメータグループおよび DB クラスターパラメータグループを使用する」を参照してください。

RDS for MySQL

Amazon RDS DB インスタンスのバイナリログ記録を有効にするには

Amazon RDS DB インスタンスのバイナリログ記録を直接有効にすることはできませんが、以下のいずれかの操作により有効にすることができます。

  • DB インスタンスの自動バックアップを有効にする。自動バックアップの有効化は、DB インスタンスを作成するときに行うか、既存の DB インスタンスを変更することで行うことができます。詳細については、Amazon RDS ユーザーガイドの「DB インスタンスの作成」を参照してください。

  • DB インスタンスのリードレプリカを作成します。詳細については、Amazon RDS ユーザーガイドの「リードレプリカの使用」を参照してください。

MySQL (外部)

暗号化レプリケーションを設定するには

Aurora MySQL バージョン 5.6 を使用してデータを安全に複製するには、暗号化されたレプリケーションを使用できます。

現在、外部の MySQL データベースからの暗号化されたレプリケーションは Aurora MySQL バージョン 5.6 でのみサポートされています。

注記

暗号化レプリケーションを使う必要がない場合、このステップをスキップできます。

暗号化レプリケーションを使用するための前提条件は次のとおりです。

  • Secure Sockets Layer (SSL) は、外部の MySQL マスターデータベースで有効になっている必要があります。

  • クライアントのキーとクライアントの証明書が Aurora MySQL DB クラスター用に準備されている必要があります。

暗号化のレプリケーション中、Aurora MySQL DB クラスターはクライアントとして MySQL データベースサーバーに動作します。Aurora MySQL 用の証明書およびキーは、.pem 形式のファイルにあります。

  1. 暗号化レプリケーションのための準備があることを確認してください。

    • 外部の MySQL マスターデータベースで有効になった SSL がなく、またクライアントキーおよびクライアント証明書が準備されていない場合、MySQL データベースサーバーで SSL を有効にし、必要なクライアントキーおよびクライアントの証明書を生成します。

    • SSL が外部マスターで有効になっている場合は、Aurora MySQL DB クラスターにクライアントキーおよび証明書を提供します。これらがない場合は、Aurora MySQL DB クラスター用に新しいキーと証明書を生成します。クライアント証明書に署名するには、外部の MySQL ソースデータベースで SSL の設定に使用した認証機関キーが必要です。

    詳細については、MySQL ドキュメントの「openssl を使用した SSL 証明書およびキーの作成」を参照してください。

    認証機関証明書、クライアントキーおよびクライアント証明書が必要となります。

  2. SSL を使用して、マスターユーザーとして Aurora MySQL DB クラスターに接続します。

    SSL で Aurora MySQL DB クラスターに接続する詳細については、「Aurora MySQL DB クラスターでの SSL/TLS の使用」を参照してください。

  3. mysql.rds_import_binlog_ssl_material ストアドプロシージャを実行して、Aurora MySQL DB クラスターに SSL 情報をインポートします。

    ssl_material_value パラメータには、正しい JSON ペイロードで Aurora MySQL DB クラスター用の .pem 形式から情報を挿入します。

    次の例では、SSL 情報を Aurora MySQL DB クラスターにインポートします。.pem 形式ファイルでは、通常の場合、コード本文に例に示されるコード本文より長くなっています。 

    call mysql.rds_import_binlog_ssl_material( '{"ssl_ca":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END RSA PRIVATE KEY-----\n"}');

    インポートされたキーマテリアルの詳細については、「 mysql_rds_import_binlog_ssl_material」および「Aurora MySQL DB クラスターでの SSL/TLS の使用」を参照してください。

    注記

    手順を実行したあと、シークレットはファイルに保存されます。ファイルを削除するには、mysql_rds_remove_binlog_ssl_material ストアドプロシージャを実行できます。

外部 MySQL データベースのバイナリログ記録を有効にするには

  1. コマンドラインシェルから、mysql サービスを停止します。 

    sudo service mysqld stop

  2. my.cnf ファイルを編集します (このファイルは通常 /etc にあります)。 

    sudo vi /etc/my.cnf

    log_bin オプションと server_id オプションを [mysqld] に追加します。log_bin オプションは、バイナリログファイルのファイル名識別子を提供します。server_id オプションは、ソースとレプリカの関係のサーバーに一意の識別子を提供します。

    暗号化レプリケーションが求められない場合、外部 MySQL データベースでバイナリログが有効化され、SSL が無効化された状態で開始することを確認します。

    非暗号化データ用の /etc/my.cnf ファイルの関連するエントリを以下に示します。 

    log-bin=mysql-bin server-id=2133421 innodb_flush_log_at_trx_commit=1 sync_binlog=1

    暗号化レプリケーションが求められる場合、外部 MySQL データベースが SSL およびバイナリログ有効化された状態で開始することを確認します。

    /etc/my.cnf ファイルのエントリには、MySQL データベースサーバーの .pem ファイルの場所が含まれます。 

    log-bin=mysql-bin server-id=2133421 innodb_flush_log_at_trx_commit=1 sync_binlog=1 # Setup SSL. ssl-ca=/home/sslcerts/ca.pem ssl-cert=/home/sslcerts/server-cert.pem ssl-key=/home/sslcerts/server-key.pem

    また、MySQL DB インスタンスの sql_mode オプションを 0 に設定するか、my.cnf ファイルから除外する必要があります。

    外部の MySQL データベースに接続するときに、外部の MySQL データベースのバイナリログの場所を記録します。 

    mysql> SHOW MASTER STATUS;

    出力は次のようになります。 

    +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000031 | 107 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)

    詳細については、MySQL ドキュメントの Setting the replication master configuration を参照してください。

  3. mysql サービスを開始します。 

    sudo service mysqld start

2.レプリケーションソースのバイナリログを不要になるまで保持する

MySQL バイナリログのレプリケーションを使用する場合、Amazon RDS はレプリケーションプロセスを管理しません。したがって、レプリケーションソースのバイナリログファイルは、変更がレプリカに適用されるまで保持する必要があります。バイナリログが保持されていれば、障害発生時にソースデータベースを復元できます。

以下のデータベースエンジンのバイナリログを維持する手順を確認します。

データベースエンジン Instructions

Aurora

Aurora MySQL DB クラスターのバイナリログを保持するには

Aurora MySQL DB クラスターのバイナリログファイルにはアクセスできません。そのため、確実に変更がレプリカに適用されてから、レプリケーションソースのバイナリログファイルが Amazon RDS によって削除されるように、バイナリログファイルの保持期間は十分に長く設定する必要があります。Aurora MySQL DB クラスターのバイナリログファイルは最大 90 日間、保持できます。

MySQL データベースまたは RDS for MySQL DB インスタンスをレプリカとしてレプリケーションを設定する場合、レプリカを作成するデータベースが巨大であれば、レプリカへのデータベースの最初のコピーが完了し、レプリカラグが 0 に達するまで、バイナリログファイルが保持されるように、その保持期間は長く設定してください。

バイナリログの保持タイムフレームを設定するには、mysql_rds_set_configuration プロシージャを使用して、DB クラスターのバイナリログファイルの保持期間に合わせて、'binlog retention hours' の設定パラメータを指定します。最大値は 2,160 (90 日) です。以下の例では、バイナリログファイルの保持期間を 6 日に設定しています。 

CALL mysql.rds_set_configuration('binlog retention hours', 144);

レプリケーションが開始された後、レプリカに対して SHOW SLAVE STATUS コマンドを実行し、Seconds behind master フィールドを調べることで、変更がレプリカに適用されていることを確認できます。Seconds behind master フィールドが 0 の場合、レプリカラグはありません。レプリカラグがないときは、binlog retention hours 設定パラメータをより短い期間に設定することで、バイナリログファイルの保持期間を短くします。

この設定を指定しない場合、Aurora MySQL のデフォルト値は 24 (1 日) です。

'binlog retention hours' に 2,160 より大きい値を指定すると、Aurora MySQL は 2,160 という値を使用します。

RDS for MySQL

Amazon RDS DB インスタンスのバイナリログを保持するには

前のセクションで説明したように、Amazon RDS DB インスタンスのバイナリログファイルを保持するには、保持期間を Aurora MySQL DB クラスターと同様に設定します。

DB インスタンスのリードレプリカを作成しても、Amazon RDS DB インスタンスのバイナリログファイルを保持できます。このリードレプリカはバイナリログファイルの保持専用に一時的に作成されます。作成されたリードレプリカに対して mysql_rds_stop_replication プロシージャを呼び出します (mysql.rds_stop_replication プロシージャは MySQL バージョン 5.5、5.6 以降、および 5.7 以降でのみ使用可能)。レプリケーションの停止中に Amazon RDS がレプリケーションソースのバイナリログファイルを削除することはありません。永続レプリカとのレプリケーションを設定した後、レプリケーションソースと永続レプリカ間のレプリカラグ (Seconds behind master フィールド) が 0 に達したときに、リードレプリカを削除できます。

MySQL (外部)

外部 MySQL データベースのバイナリログを有効にするには

外部 MySQL データベースのバイナリログファイルは Amazon RDS によって管理されていないため、手動で削除されるまでは保持されます。

レプリケーションが開始された後、レプリカに対して SHOW SLAVE STATUS コマンドを実行し、Seconds behind master フィールドを調べることで、変更がレプリカに適用されていることを確認できます。Seconds behind master フィールドが 0 の場合、レプリカラグはありません。レプリカラグがないときは、古いバイナリログファイルを削除できます。

3.レプリケーションソースのスナップショットを作成する

レプリケーションソースのスナップショットは、レプリカにデータのベースラインコピーをロードし、その時点からレプリケーションを開始するために使用します。

以下のデータベースエンジンのレプリケーションソースのスナップショットを作成する手順を確認します。

データベースエンジン Instructions

Aurora

Aurora MySQL DB クラスターのスナップショットを作成するには

  1. Amazon Aurora DB クラスターのスナップショットを作成します。詳細については、「DB クラスタースナップショットの作成」を参照してください。

  2. 先ほど作成した DB クラスターのスナップショットから復元することで、新しい Aurora DB クラスターを作成します。復元された DB クラスターの DB パラメータグループは、元の DB クラスターと同一のものを維持してください。これを実行することで、DB クラスターのコピーでも確実にバイナリログ作成が有効になります。詳細については、「DB クラスターのスナップショットからの復元」を参照してください。

  3. コンソールで、[データベース] を選択し、復元された Aurora DB クラスターのプライマリインスタンス (書き込み) を選択してその詳細を表示します。[最近のイベント] までスクロールします。binlog ファイル名と場所を含むイベントメッセージが表示されます。イベントメッセージの形式は以下のとおりです。 

    Binlog position from crash recovery is binlog-file-name binlog-position

    レプリケーションを開始したときの binlog ファイルの名前と場所の値を保存します。

    AWS CLI から describe-events コマンドを呼び出して、binlog ファイルの名前と場所を取得することもできます。次に describe-events コマンドの例とサンプル出力を示します。 

    PROMPT> aws rds describe-events
    { "Events": [ { "EventCategories": [], "SourceType": "db-instance", "SourceArn": "arn:aws:rds:us-west-2:123456789012:db:sample-restored-instance", "Date": "2016-10-28T19:43:46.862Z", "Message": "Binlog position from crash recovery is mysql-bin-changelog.000003 4278", "SourceIdentifier": "sample-restored-instance" } ] }

    binlog ファイルの名前と位置は、MySQL バイナリログファイルの最後の場所、または DB_CRASH_RECOVERY_BINLOG_POSITION エントリの MySQL エラーログを調べることでも確認できます。

  4. レプリカターゲットが別の AWS アカウントが所有する Aurora DB クラスター、外部 MySQL データベース、または RDS for MySQL DB インスタンスである場合、Amazon Aurora DB クラスターのスナップショットからデータをロードすることはできません。代わりに、MySQL クライアントを使用して DB クラスターに接続し、mysqldump コマンドを発行することで、Amazon Aurora DB クラスターのダンプを作成します。作成した Amazon Aurora DB クラスターのコピーに対して必ず mysqldump コマンドを実行してください。以下はその例です。 

    PROMPT> mysqldump --databases <database_name> --single-transaction --order-by-primary -r backup.sql -u <local_user> -p

  5. 新しく作成した Aurora DB クラスターからデータのダンプを作成し終わったら、その DB クラスターはもう不要なため削除します。

RDS for MySQL

Amazon RDS DB インスタンスのスナップショットを作成するには

  1. Amazon RDS DB インスタンスのリードレプリカを作成します。詳細については、Amazon Relational Database Service ユーザーガイドの「リードレプリカの作成」を参照してください。

  2. リードレプリカに接続し、 mysql_rds_stop_replication プロシージャを実行することでレプリケーションを停止します。

  3. リードレプリカが [Stopped] の状態で、リードレプリカに接続し、SHOW SLAVE STATUS コマンドを実行します。Relay_Master_Log_File フィールドから現在のバイナリログファイルの名前を、Exec_Master_Log_Pos フィールドからそのログファイルの場所を取得します。レプリケーションを開始するときのために、これらの値を保存します。

  4. リードレプリカが [Stopped] の状態のままで、リードレプリカの DB スナップショットを作成します。詳細については、Amazon Relational Database Service ユーザーガイドの「DB スナップショットの作成」を参照してください。

  5. リードレプリカを削除します。

MySQL (外部)

外部 MySQL データベースのスナップショットを作成するには

  1. スナップショットを作成する前に、スナップショットのバイナリログの場所がソースインスタンスのデータで更新されている必要があります。そのためには、まず以下のコマンドを使用して、インスタンスへの書き込みオペレーションを停止する必要があります。 

    mysql> FLUSH TABLES WITH READ LOCK;

  2. 以下の mysqldump コマンドを使用して、MySQL データベースのダンプを作成します。 

    PROMPT> sudo mysqldump --databases <database_name> --master-data=2 --single-transaction \ --order-by-primary -r backup.sql -u <local_user> -p

  3. スナップショットを作成した後、以下のコマンドを実行して、MySQL データベースのテーブルのロックを解除します。 

    mysql> UNLOCK TABLES;

4.レプリカターゲットにスナップショットをロードする

Amazon RDS の外部 MySQL データベースのダンプからデータをロードする場合、ダンプファイルのコピー先となる EC2 インスタンスを作成してから、その EC2 インスタンスから DB クラスターまたは DB インスタンスにデータをロードします。この方法では、ダンプファイルを EC2 インスタンスにコピーする前に圧縮して、Amazon RDS へのデータのコピーに関連するネットワークコストを削減できます。また、ダンプファイルを暗号化して、ネットワーク経由で転送されるデータを保護することもできます。

以下のデータベースエンジンのレプリカターゲットにレプリケーションソースのスナップショットをロードする手順を確認します。

データベースエンジン Instructions

Aurora

Aurora MySQL DB クラスターにスナップショットをロードするには

  • レプリケーションソースのスナップショットが DB クラスターのスナップショットである場合は、DB クラスターのスナップショットから復元することで、レプリカターゲットとして新しい Aurora MySQL DB クラスターを作成できます。詳細については、「DB クラスターのスナップショットからの復元」を参照してください。

  • レプリケーションソースのスナップショットが DB スナップショットである場合は、DB スナップショットから新しい Aurora MySQL DB クラスターにデータを移行できます。詳細については、「Amazon Aurora DB クラスターへのデータの移行」を参照してください。

  • レプリケーションソースのスナップショットが mysqldump コマンドの出力である場合は、以下の手順を実行します。

    1. mysqldump コマンドの出力をレプリケーションソースから、Aurora MySQL DB クラスターにも接続できる場所にコピーします。

    2. mysql コマンドを使用して Aurora MySQL DB クラスターに接続します。次に例を示します。 

      PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p

    3. mysql プロンプトで、データベースダンプファイルの名前を渡して source コマンドを実行することで、Aurora MySQL DB クラスターにデータをロードします。たとえば、以下のようになります。 

      mysql> source backup.sql;

RDS for MySQL

Amazon RDS DB インスタンスにスナップショットをロードするには

  1. mysqldump コマンドの出力をレプリケーションソースから、MySQL DB インスタンスにも接続できる場所にコピーします。

  2. mysql コマンドを使用して MySQL DB インスタンスに接続します。次に例を示します。 

    PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p

  3. mysql プロンプトで、データベースダンプファイルの名前を渡して source コマンドを実行することで、MySQL DB インスタンスにデータをロードします。たとえば、以下のようになります。 

    mysql> source backup.sql;

MySQL (外部)

外部 MySQL データベースにスナップショットをロードするには

外部 MySQL データベースに DB スナップショットまたは DB クラスターのスナップショットをロードすることはできません。代わりに、mysqldump コマンドの出力を使用する必要があります。

  1. mysqldump コマンドの出力をレプリケーションソースから、MySQL データベースにも接続できる場所にコピーします。

  2. mysql コマンドを使用して MySQL データベースに接続します。次に例を示します。 

    PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p

  3. mysql プロンプトで、データベースダンプファイルの名前を渡して source コマンドを実行することで、MySQL データベースにデータをロードします。次に例を示します。 

    mysql> source backup.sql;

5.レプリカターゲットでレプリケーションを有効にする

レプリケーションを有効化する前に、Aurora MySQL DB クラスターまたは RDS for MySQL DB インスタンスレプリカターゲットのスナップショットを手動で作成することをお勧めします。問題が発生し、DB クラスターまたは DB インスタンスレプリカターゲットとのレプリケーションを再開する必要がある場合は、このスナップショットから DB クラスターまたは DB インスタンスを復元できます。そのために、再びレプリカターゲットにデータをインポートする必要はありません。

また、レプリケーション専用のユーザー ID を作成します。次に例を示します。 

mysql> CREATE USER 'repl_user'@'<domain_name>' IDENTIFIED BY '<password>';

ユーザーには REPLICATION CLIENT および REPLICATION SLAVE 権限が必要です。ユーザーのこれらの権限を付与します。 

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'<domain_name>';

暗号化レプリケーションを使用する必要がある場合は、レプリケーションのユーザーに対して SSL 接続を要求します。たとえば、以下のいずれかのステートメントを使用して、ユーザーアカウント repl_user に SSL 接続を要求できます。 

GRANT USAGE ON *.* TO 'repl_user'@'<domain_name>' REQUIRE SSL;
注記

REQUIRE SSL が含まれていない場合には、レプリケーション接続がメッセージの表示なしで非暗号化接続に戻る場合があります。

以下のデータベースエンジンの以下のレプリケーションを有効にする手順を確認します。

データベースエンジン Instructions

Aurora

Aurora MySQL DB クラスターからのレプリケーションを有効にするには

  1. DB クラスターレプリカターゲットが DB クラスターのスナップショットから作成された場合は、その DB クラスターレプリカターゲットに接続し、SHOW MASTER STATUS コマンドを発行します。File フィールドから現在のバイナリログファイルの名前を、Position フィールドからそのログファイルの場所を取得します。

    DB クラスターレプリカターゲットが DB スナップショットから作成された場合は、レプリケーションにはまずバイナリログファイルの名前と場所が必要になります。レプリケーションソースのスナップショットを作成したとき、SHOW SLAVE STATUS コマンドからこれらの値を取得しました。

  2. DB クラスターに接続し、前の手順からのバイナリログファイルの名前と場所を使用して mysql_rds_set_external_master および mysql_rds_start_replication プロシージャを発行することで、レプリケーションソースとのレプリケーションを開始します。以下はその例です。 

    CALL mysql.rds_set_external_master ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0); CALL mysql.rds_start_replication;

RDS for MySQL

Amazon RDS DB インスタンスからのレプリケーションを有効にするには

  1. DB インスタンスレプリカターゲットが DB スナップショットから作成された場合は、レプリケーションにはまずバイナリログファイルの名前と場所が必要になります。レプリケーションソースのスナップショットを作成したとき、SHOW SLAVE STATUS コマンドからこれらの値を取得しました。

  2. DB インスタンスに接続し、前の手順からのバイナリログファイルの名前と場所を使用して mysql_rds_set_external_master および mysql_rds_start_replication プロシージャを発行することで、レプリケーションソースとのレプリケーションを開始します。以下はその例です。 

    CALL mysql.rds_set_external_master ('mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0); CALL mysql.rds_start_replication;

MySQL (外部)

外部 MySQL データベースからのレプリケーションを有効にするには

  1. レプリケーションにまず必要になるバイナリログファイルの名前と場所を取得します。レプリケーションソースのスナップショットを作成したとき、SHOW SLAVE STATUS コマンドからこれらの値を取得しました。外部の MySQL レプリカターゲットへのデータロードに mysqldump オプションを指定して実行した --master-data=2 コマンドの出力を使用した場合は、その出力にバイナリログファイルの名前と場所が含まれています。次に例を示します。 

    -- -- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;

  2. 外部の MySQL レプリカターゲットに接続し、前の手順からのバイナリログファイルの名前と場所を使用して CHANGE MASTER TO および START SLAVE を発行することで、レプリケーションソースとのレプリケーションを開始します。以下に例を示します。 

    CHANGE MASTER TO MASTER_HOST = 'mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', MASTER_PORT = 3306, MASTER_USER = 'repl_user', MASTER_PASSWORD = '<password>', MASTER_LOG_FILE = 'mysql-bin-changelog.000031', MASTER_LOG_POS = 107; START SLAVE;

6.レプリカをモニタリングする

Aurora MySQL DB クラスターと MySQL との間のレプリケーションを設定する場合、Aurora MySQL DB クラスターがレプリカターゲットであれば、そのクラスターのフェイルオーバーイベントをモニタリングする必要があります。フェイルオーバーが発生すると、レプリカターゲットである DB クラスターが、新しいホスト上に別のネットワークアドレスで再作成されます。フェイルオーバーイベントをモニタリングする方法については、「Amazon RDS イベント通知の使用」を参照してください。

また、レプリカターゲットに接続し、SHOW SLAVE STATUS コマンドを実行することで、レプリケーションソースからレプリカターゲットへのコピーの進行状況をモニタリングできます。このコマンドの出力の Seconds Behind Master フィールドに、マスターからレプリカターゲットへのコピーの進行状況が示されます。

Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーションの停止

MySQL DB インスタンス、外部 MySQL データベース、または別の Aurora DB クラスターでのバイナリログのレプリケーションを停止するには、このトピックの後で詳しく説明するステップに従ってください。

1.レプリカターゲットでバイナリログのレプリケーションを停止する

2.レプリケーションソースのバイナリログ記録を無効にする

1.レプリカターゲットでバイナリログのレプリケーションを停止する

データベースエンジンのバイナリログレプリケーションを停止する方法については、以下の説明を参照してください。

データベースエンジン Instructions

Aurora

Aurora MySQL DB クラスターレプリカターゲットでのバイナリログのレプリケーションを停止するには

レプリカターゲットである Aurora DB クラスターに接続し、 mysql_rds_stop_replication 手順を呼び出します。mysql.rds_stop_replication 手順は、MySQL のバージョン 5.5 以降、5.6 以降、および 5.7 以降のみで利用できます。

RDS for MySQL

Amazon RDS DB インスタンスのバイナリログのレプリケーションを停止するには

レプリカターゲットである RDS DB インスタンスに接続し、 mysql_rds_stop_replication 手順を呼び出します。mysql.rds_stop_replication 手順は、MySQL のバージョン 5.5 以降、5.6 以降、および 5.7 以降のみで利用できます。

MySQL (外部)

外部 MySQL データベースのバイナリログのレプリケーションを停止するには

MySQL データベースに接続して、STOP REPLICATION コマンドを呼び出します。

2.レプリケーションソースのバイナリログ記録を無効にする

以下のデータベースエンジンのバイナリログ記録をレプリケーションソースで無効にする手順を確認します。

データベースエンジン Instructions

Aurora

Amazon Aurora DB クラスターのバイナリログ記録を無効にするには

  1. レプリケーションソースである Aurora DB クラスターに接続し、バイナリログの保持期間を 0 に設定します。バイナリログの保持期間を設定するには、mysql_rds_set_configuration プロシージャを使用し、DB クラスターのバイナリログファイルの保持期間に合わせて、'binlog retention hours' の設定パラメータを指定します。この場合は、以下の例にあるように、0 です。 

    CALL mysql.rds_set_configuration('binlog retention hours', 0);

  2. レプリケーションソースで binlog_format パラメータを OFF に設定します。binlog_format パラメータはクラスターレベルのパラメータであり、デフォルトクラスターパラメータグループにあります。

    binlog_format パラメータ値を変更した後、変更を有効にするために DB クラスターを再起動します。

    詳細については、「Amazon Aurora の DB クラスターパラメータと DB インスタンスパラメータ」および「DB パラメータグループのパラメータの変更」を参照してください。

RDS for MySQL

Amazon RDS DB インスタンスのバイナリログ記録を無効にするには

Amazon RDS DB インスタンスのバイナリログ記録は、直接無効にすることはできませんが、以下のいずれかの操作により無効にできます。

  1. DB インスタンスの自動バックアップを無効にする。既存の DB インスタンスを変更して [Backup Retention Period] を 0 に設定することで、自動バックアップを無効にできます。詳細については、Amazon Relational Database Service ユーザーガイドの「Amazon RDS DB インスタンスの変更」および「バックアップの操作」を参照してください。

  2. DB インスタンスのすべてのリードレプリカを削除します。詳細については、Amazon Relational Database Service ユーザーガイドの「MariaDB、MySQL、PostgreSQL DB インスタンスのリードレプリカの使用」を参照してください。

MySQL (外部)

外部 MySQL データベースのバイナリログ記録を無効にするには

MySQL データベースに接続して、STOP REPLICATION コマンドを呼び出します。

  1. コマンドラインシェルから、mysqld サービスを停止します。 

    sudo service mysqld stop

  2. my.cnf ファイルを編集します (このファイルは通常 /etc にあります)。 

    sudo vi /etc/my.cnf

    log_bin セクションから server_id および [mysqld] オプションを削除します。

    詳細については、MySQL ドキュメントの Setting the replication master configuration を参照してください。

  3. mysql サービスを開始します。 

    sudo service mysqld start

Amazon Aurora を使用した MySQL データベースの読み取りスケーリング

MySQL DB インスタンスで Amazon Aurora を使用することで、Amazon Aurora の読み取りスケーリング機能を活用して MySQL DB インスタンスの読み取りワークロードを拡張できます。Aurora を使用して MySQL DB インスタンスの読み取りを拡張するには、Amazon Aurora MySQL DB クラスターを作成し、MySQL DB インスタンスのリードレプリカに指定します。これは、RDS for MySQL DB インスタンス、または Amazon RDS の外部で実行されている MySQL データベースに適用されます。

Amazon Aurora DB クラスターの作成については、「Amazon Aurora DB クラスターの作成」を参照してください。

MySQL DB インスタンスと Amazon Aurora DB クラスターの間でレプリケーションを設定するときは、以下のガイドラインに従ってください。

  • Amazon Aurora DB クラスターを参照するときは、Amazon Aurora MySQL DB クラスターのエンドポイントアドレスを使用します。フェイルオーバーが発生すると、Aurora MySQL DB クラスターのプライマリインスタンスに昇格された Aurora レプリカで、引き続きこの DB クラスターのエンドポイントアドレスが使用されます。

  • ライターインスタンスのバイナリログが Aurora レプリカに適用されたことを確認するまで、これらのバイナリログを保持します。このメンテナンスによって、障害発生時にライターインスタンスを復元できます。

重要

自己管理型レプリケーションを使用する場合、ユーザー自身で発生する可能性のあるすべてのレプリケーションの問題をモニタリングし、解決する必要があります。詳細については、「リードレプリカ間の遅延の診断と解決」を参照してください。

注記

Amazon Aurora MySQL DB クラスターでレプリケーションを開始するために必要なアクセス権限は限定されており、Amazon RDS マスターユーザーは使用できません。このため、Amazon Aurora MySQL DB クラスターと MySQL DB インスタンスの間でレプリケーションを設定するには、Amazon RDS mysql_rds_set_external_master と mysql_rds_start_replication の手順を使用する必要があります。

外部のソースインスタンスと Amazon RDS の MySQL DB インスタンスとの間でレプリケーションを開始する

  1. ソース MySQL DB インスタンスを読み取り専用にします。 

    mysql> FLUSH TABLES WITH READ LOCK; mysql> SET GLOBAL read_only = ON;

  2. ソース MySQL DB インスタンスで SHOW MASTER STATUS コマンドを実行して、binlog の場所を特定します。以下の例のような出力を受け取ります。 

    File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------

  3. mysqldump を使用して、外部の MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターにデータベースをコピーします。大規模なデータベースの場合、Amazon Relational Database Service ユーザーガイドの「ダウンタイムを短縮して MySQL または MariaDB DB インスタンスにデータをインポートする」の手順を使用することが必要になる場合があります。

    Linux、macOS、Unix の場合:

    mysqldump \ --databases <database_name> \ --single-transaction \ --compress \ --order-by-primary \ -u <local_user> \ -p <local_password> | mysql \ --host aurora_cluster_endpoint_address \ --port 3306 \ -u <RDS_user_name> \ -p <RDS_password>

    Windows の場合:

    mysqldump ^ --databases <database_name> ^ --single-transaction ^ --compress ^ --order-by-primary ^ -u <local_user> ^ -p <local_password> | mysql ^ --host aurora_cluster_endpoint_address ^ --port 3306 ^ -u <RDS_user_name> ^ -p <RDS_password>
    注記

    -p オプションと入力するパスワードの間にスペースがないことを確認します。

    mysql コマンドで、--host、--user (-u)、--port、-p オプションを使用して、Aurora DB クラスターに接続するためのホスト名、ユーザー名、ポート、パスワードを指定します。このホスト名は、Amazon Aurora DB クラスターのエンドポイントの DNS 名（たとえば mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com）です。エンドポイントの値は、Amazon RDS マネジメントコンソールでクラスターの詳細を確認できます。

  4. もう一度ソース MySQL DB インスタンスを書き込み可能にします。 

    mysql> SET GLOBAL read_only = OFF; mysql> UNLOCK TABLES;

    レプリケーションで使用するバックアップの作成の詳細については、MySQL ドキュメントの Backing up a master or slave by making it read only を参照してください。

  5. Amazon RDS マネジメントコンソールで、ソース MySQL データベースをホストするサーバーの IP アドレスを、Amazon Aurora DB クラスターの VPC セキュリティグループに追加します。VPC セキュリティグループの変更方法の詳細については、Amazon Virtual Private Cloud ユーザーガイドの「VPC のセキュリティグループ」を参照してください。

    ソース MySQL インスタンスと通信できるようにするために、Amazon Aurora DB クラスターの IP アドレスからの接続を許可するようにローカルネットワークを設定することも必要になる場合があります。Amazon Aurora DB クラスターの IP アドレスを確認するには、host コマンドを使用します。 

    host <aurora_endpoint_address>

    このホスト名は、Amazon Aurora DB クラスターのエンドポイントからの DNS 名です。

  6. 選択したクライアントを使用して、外部の MySQL インスタンスに接続し、レプリケーションに使用される MySQL ユーザーを作成します。このアカウントはレプリケーション専用に使用され、セキュリティを強化するためにドメインに制限する必要があります。次に例を示します。 

    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';

  7. 外部の MySQL インスタンスについて、REPLICATION CLIENT と REPLICATION SLAVE の特権をレプリケーションユーザーに付与します。たとえば、すべてのデータベースに対する REPLICATION CLIENT および REPLICATION SLAVE 権限を "repl_user" ユーザーに付与するには、以下のコマンドを実行します。 

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';

  8. レプリケーションを設定する前に、Aurora MySQL DB クラスターの手動スナップショットをリードレプリカに指定します。DB クラスターをリードレプリカとしてレプリケーションを再構築する必要がある場合は、このスナップショットから Aurora MySQL DB クラスターを復元でき、MySQL DB インスタンスから新しい Aurora MySQL DB クラスターにデータをインポートする必要はありません。

  9. Amazon Aurora DB クラスターをレプリカとして指定します。Amazon Aurora DB クラスターにマスターユーザーとして接続し、 mysql_rds_set_external_master の手順を使用して、ソース MySQL データベースをレプリケーションマスターとして指定します。ステップ 2 で特定したマスターログファイル名とマスターログの場所を使用します。次に例を示します。 

    CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);

  10. Amazon Aurora DB クラスターで、 mysql_rds_start_replication の手順を実行してレプリケーションを開始します。 

    CALL mysql.rds_start_replication;

ソース MySQL DB インスタンスと Amazon Aurora DB クラスター間のレプリケーションが確立されると、Aurora レプリカを Amazon Aurora DB クラスターに追加できます。その後で、Aurora レプリカに接続してデータの読み取りを拡張できます。Aurora レプリカの作成については、「DB クラスターに Aurora レプリカを追加する」を参照してください。

バイナリログのレプリケーションの最適化

次に、Aurora MySQL でバイナリログのレプリケーションのパフォーマンスを最適化し、関連する問題のトラブルシューティングを行う方法について説明します。

ヒント

この説明は、MySQL バイナリログのレプリケーションメカニズムとその仕組みに精通していることを前提としています。背景情報については、MySQL ドキュメントの「レプリケーション実装ガイド」を参照してください。

バイナリログレプリケーションの最適化 (Aurora MySQL 2.10 以降)

Aurora MySQL 2.10 以降では、Aurora は、バイナリログのレプリケーションにバイナリログ I/O キャッシュと呼ばれる最適化を自動的に適用します。最後にコミットされたバイナリログイベントをキャッシュすることにより、この最適化は、バイナリログソースインスタンスでのフォアグラウンドトランザクションへの影響を制限しながら、バイナリログのダンプスレッドのパフォーマンスを向上するように設計されています。

注記

この機能に使用されるこのメモリは、MySQL binlog_cache 設定とは無関係です。

この機能は、db.t2 および db.t3 インスタンスクラスを使用するAurora DB インスタンスには適用されません。

この最適化を有効にするために、設定パラメータを調整する必要はありません。特に、以前の Aurora MySQL バージョンで設定パラメータ aurora_binlog_replication_max_yield_seconds をゼロ以外の値に調整する場合は、Aurora MySQL 2.10 以降ではゼロに戻します。

ステータス変数 aurora_binlog_io_cache_reads および aurora_binlog_io_cache_read_requests は Aurora MySQL 2.10 以降で使用できます。これらのステータス変数は、バイナリログ I/O キャッシュからデータが読み込まれる頻度をモニタリングするのに役立ちます。

  • aurora_binlog_io_cache_read_requests: キャッシュからのバイナリログ I/O 読み込みリクエストの数を示します。

  • aurora_binlog_io_cache_reads: キャッシュから情報を取得するバイナリログ I/O 読み込みの数を示します。

次の SQL クエリは、キャッシュされた情報を利用するバイナリログ読み込みリクエストの割合を計算します。この場合、比率が 100 に近づくほど、より良好であることを意味します。 

mysql> SELECT (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads') / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests') * 100 as binlog_io_cache_hit_ratio; +---------------------------+ | binlog_io_cache_hit_ratio | +---------------------------+ | 99.99847949080622 | +---------------------------+

バイナリログ I/O キャッシュ機能には、バイナリログのダンプスレッドに関連する新しいメトリクスも含まれています。ダンプスレッドは、新しいバイナリログレプリカがバイナリログソースインスタンスに接続したときに作成されるスレッドです。ダンプスレッドメトリクスは、60 秒ごとにプレフィックス [Dump thread metrics] を伴ってデータベースログに出力されます。メトリクスには、Secondary_id、Secondary_uuid、バイナリログのファイル名、各レプリカが読み込んでいる位置など、各バイナリログのレプリカの情報が含まれます。メトリクスには、レプリケーションソースとレプリカの間の距離をバイト単位で表す Bytes_behind_primary も含まれます。このメトリクスは、レプリカ I/O スレッドのラグを測定します。この数値は、バイナリログのレプリカの seconds_behind_master メトリクスによって表されるレプリカ SQL 適用元スレッドのラグとは異なります。距離が減少するか増加するかを確認することで、バイナリログレプリカがソースに追いついているのか、遅れているのかを判断できます。

バイナリログレプリケーションの最適化 (Aurora MySQL 2.04.5～2.09)

Aurora MySQL のバイナリログのレプリケーションを最適化するには、以下のクラスターレベルの最適化パラメータを調整します。これらのパラメータは、バイナリログのソースインスタンスのレイテンシーとレプリケーションラグの間の適切なバランスを特定するのに役立ちます。

  • aurora_binlog_use_large_read_buffer

  • aurora_binlog_read_buffer_size

  • aurora_binlog_replication_max_yield_seconds

注記

MySQL 5.7 互換クラスターの場合、Aurora MySQL バージョン 2.04.5 から 2.09.* でこれらのパラメータを使用できます。Aurora MySQL 2.10.0 以降では、これらのパラメータはバイナリログ I/O キャッシュの最適化によって置き換えられ、それらを使用する必要はありません。

MySQL 5.6 互換クラスターの場合、Aurora MySQL バージョン 1.17.6 以降でこれらのパラメータを使用できます。

大きな読み込みバッファと最大収量の最適化の概要

クラスターが多数のトランザクションを処理している間、バイナリログのダンプスレッドが Aurora クラスターボリュームにアクセスすると、バイナリログレプリケーションのパフォーマンスが低下することがあります。パラメータ aurora_binlog_use_large_read_buffer、aurora_binlog_replication_max_yield_seconds、aurora_binlog_read_buffer_size を使用すると、このタイプの競合を最小限に抑えることができます。

aurora_binlog_replication_max_yield_seconds が 0 より大きい値に設定され、ダンプスレッドの現在のバイナリログファイルがアクティブな場合、バイナリログのダンプスレッドは、トランザクションによって現在のバイナリログファイルがいっぱいになるまで、指定された秒数待機します。この待機期間により、各バイナリログイベントを個別にレプリケートすることによって発生する可能性のある競合が回避されます。ただし、それによりバイナリログレプリカのレプリカラグが増加します。これらのレプリカは、aurora_binlog_replication_max_yield_seconds 設定と同じ秒数だけソースより遅れる可能性があります。

現在のバイナリログファイルとは、スレッドダンプがレプリケーションを実行するために現在読み込んでいるバイナリログファイルのことです。バイナリログファイルが更新中または受信トランザクションにる更新のために開かれているとき、バイナリログファイルはアクティブであると見なします。Aurora MySQL がアクティブなバイナリログファイルでいっぱいになると、MySQL が新しいバイナリログファイルを作成して切り替えます。古いバイナリログファイルは非アクティブになります。受信トランザクションによって更新されることはありません。

注記

これらのパラメータを調整する前に、トランザクションのレイテンシーとスループットを長期間測定してください。バイナリログレプリケーションのパフォーマンスは安定しており、競合が時折発生する場合でも低レイテンシーとなります。

aurora_binlog_use_large_read_buffer

このパラメータが 1 に設定されている場合、パラメータ aurora_binlog_read_buffer_size および aurora_binlog_replication_max_yield_seconds の設定に基づいて、Aurora MySQL がバイナリログのレプリケーションを最適化します。aurora_binlog_use_large_read_buffer が 0 の場合、Aurora MySQL はパラメータ aurora_binlog_read_buffer_size および aurora_binlog_replication_max_yield_seconds の値を無視します。

aurora_binlog_read_buffer_size

読み込みバッファが大きいバイナリログのスレッドダンプは、I/O ごとにより多くのイベントを読み取り、読み取り I/O オペレーションの数を最小限に抑えます。パラメータ aurora_binlog_read_buffer_size によって、読み取りバッファサイズが設定されます。読み取りバッファが大きいと、大量のバイナリログデータを生成するワークロードのバイナリログの競合を減らすことができます。

注記

このパラメータは、クラスターにも設定 aurora_binlog_use_large_read_buffer=1 がある場合にのみ有効です。

読み取りバッファサイズを拡張しても、バイナリログのレプリケーションのパフォーマンスに影響はありません。バイナリログのダンプスレッドは、読み取りバッファを満たすトランザクションの更新を待機しません。

aurora_binlog_replication_max_yield_seconds

ワークロードに必要なトランザクションのレイテンシーが低く、レプリケーションラグを許容できる場合は、aurora_binlog_replication_max_yield_seconds パラメータを増やすことができます。このパラメータにより、クラスター内のバイナリログレプリケーションの最大収率のプロパティが制御されます。

注記

このパラメータは、クラスターにも設定 aurora_binlog_use_large_read_buffer=1 がある場合にのみ有効です。

Aurora MySQL は、aurora_binlog_replication_max_yield_seconds パラメータ値への変更をただちに認識します。DB インスタンスを再起動する必要はありません。ただし、この設定を有効にすると、現在のバイナリログファイルが最大サイズの 128 MB に達し、新しいファイルにローテーションされた場合にのみ、ダンプスレッドの生成が開始されます。

関連パラメータ

次の DB クラスターのパラメーターを使用して、 のバイナリログの最適化を有効にする

Aurora MySQL バージョン 2.04.5 以降のバイナリログ最適化パラメータ
パラメータ デフォルト値 有効な値 説明
aurora_binlog_use_large_read_buffer 1 0、1 レプリケーション改善の機能を有効化するスイッチ。1 の場合、バイナリログのダンプスレッドによって、バイナリログのレプリケーションに aurora_binlog_read_buffer_size が使用されます。それ以外の場合は、デフォルトのバッファサイズ (8K) が使用されます。
aurora_binlog_read_buffer_size 5242880 8192-536870912 パラメータ aurora_binlog_use_large_read_buffer が 1 に設定されている場合に、バイナリログのダンプスレッドで使用される読み取りバッファサイズ。
aurora_binlog_replication_max_yield_seconds 0 0～36000 Aurora MySQL のバージョンが 2.04.5～2.04.8 および 2.05～2.08.* (両端を含む) の場合、許容される最大値は 45 です。2.04.9 以降のバージョン、バージョン 2.04.*、および 2.09 以降のバージョンでは、より大きい値に調整できます。このパラメータ aurora_binlog_use_large_read_buffer は、パラメータが 1 に設定されている場合にのみ機能します。
Aurora MySQL バージョン 1.17.6 以降のバイナリログ最適化パラメータ
パラメータ デフォルト値 有効な値 説明
aurora_binlog_use_large_read_buffer 0 0、1 レプリケーション改善の機能を有効化するスイッチ。1 の場合、バイナリログのダンプスレッドによって、aurora_binlog_read_buffer_size がバイナリログのレプリケーションに使用されます。それ以外の場合は、デフォルトのバッファサイズ (8 KB) が使用されます。
aurora_binlog_read_buffer_size 5242880 8192-536870912 パラメータ aurora_binlog_use_large_read_buffer が 1 に設定されている場合に、バイナリログのダンプスレッドで使用される読み取りバッファサイズ。
aurora_binlog_replication_max_yield_seconds 0 0～36000 バイナリログのダンプスレッドが、現在のバイナリログファイル (フォアグラウンドクエリで使用されるファイル) をレプリカにレプリケートするときの最大時間 (秒)。このパラメータ aurora_binlog_use_large_read_buffer は、パラメータが 1 に設定されている場合にのみ機能します。

バイナリログレプリケーションの最大収率メカニズムの有効化

次のように、バイナリログレプリケーションの最大収率の最適化を有効にすることができます。これにより、バイナリログのソースインスタンスでのトランザクションのレイテンシーが最小限に抑えられます。ただし、レプリケーションラグが大きくなる場合があります。

Aurora MySQL クラスターのバイナリログの最大収率の最適化を有効にするには

  1. DB クラスターパラメータグループを作成または編集するには、以下のパラメータ設定を使用します。

    • aurora_binlog_use_large_read_buffer: ON または 1 値で有効化します。

    • aurora_binlog_replication_max_yield_seconds: 0 より大きい値を指定します。

  2. DB クラスターのパラメータグループを、バイナリログのソースとして機能する Aurora MySQL クラスターに関連付けます。そのためには、「DB パラメータグループおよび DB クラスターパラメータグループを使用する」の手順に従います。

  3. パラメータの変更がに有効なっていることを確認します。これを行うには、バイナリログのソースインスタンスで以下のクエリを実行します。 

    SELECT @@aurora_binlog_use_large_read_buffer, @@aurora_binlog_replication_max_yield_seconds;

    出力は次のようになります。 

    +---------------------------------------+-----------------------------------------------+ | @@aurora_binlog_use_large_read_buffer | @@aurora_binlog_replication_max_yield_seconds | +---------------------------------------+-----------------------------------------------+ | 1 | 45 | +---------------------------------------+-----------------------------------------------+

バイナリログのレプリケーションを無効化する最大収率の最適化

以下のように、バイナリログのレプリケーションの最大収率の最適化を無効化することができます。これにより、レプリケーションラグが最小限に抑えられます。ただし、バイナリログのソースインスタンスでのトランザクションのレイテンシーが高くなることがあります。

Aurora MySQL クラスターの最大収率の最適化を無効化するには

  1. Aurora MySQL クラスターに関連付けられている DB クラスターのパラメータグループで、aurora_binlog_replication_max_yield_seconds が 0 に設定されていることを確認します。パラメータグループを使用して設定パラメータの設定の詳細については、「DB パラメータグループおよび DB クラスターパラメータグループを使用する」を参照してください。

  2. パラメータの変更がに有効なっていることを確認します。これを行うには、バイナリログのソースインスタンスで以下のクエリを実行します。 

    SELECT @@aurora_binlog_replication_max_yield_seconds;

    出力は次のようになります。 

    +-----------------------------------------------+ | @@aurora_binlog_replication_max_yield_seconds | +-----------------------------------------------+ | 0 | +-----------------------------------------------+

大きい読み取りバッファを無効化する

以下のように、大きい読み取りバッファの機能全体を無効化することができます。

Aurora MySQL クラスターで大きいバイナリログの読み取りバッファを無効化するには

  1. aurora_binlog_use_large_read_buffer を OFF または 0 にリセットします。

    Aurora MySQL クラスターに関連付けられている DB クラスターのパラメータグループで、aurora_binlog_use_large_read_buffer が 0 に設定されていることを確認します。パラメータグループを使用して設定パラメータの設定の詳細については、「DB パラメータグループおよび DB クラスターパラメータグループを使用する」を参照してください。

  2. バイナリログのソースインスタンスで、以下のクエリを実行します。 

    SELECT @@ aurora_binlog_use_large_read_buffer;

    出力は次のようになります。 

    +---------------------------------------+ | @@aurora_binlog_use_large_read_buffer | +---------------------------------------+ | 0 | +---------------------------------------+