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 クラスターを使用してレプリケートできます。

注記

特定の種類の Aurora クラスター間では、バイナリログレプリケーションを使用できません。特に、バイナリログレプリケーションは、Aurora Serverless v1 およびマルチマスタークラスターでは使用できません。SHOW MASTER STATUS と SHOW SLAVE STATUS (Aurora MySQL バージョン 1 と 2)、 または SHOW REPLICA STATUS (Aurora MySQL バージョン 3) ステートメントが出力を返さない場合、使用しているクラスターがバイナリログレプリケーションをサポートしていることを確認してください。

Aurora MySQL バージョン 3 では、バイナリログレプリケーションを使用して mysql システムデータベースに複製することはできません。そのため、CREATE USER、GRANT、REVOKE などのデータ制御言語 (DCL) ステートメントは、Aurora MySQL バージョン 3 では複製されません。

また、別の AWS リージョン で、RDS for MySQL DB インスタンスまたは Aurora MySQL DB クラスターに、レプリケートすることもできます。AWS リージョン 間のレプリケーションを実行する場合は、DB クラスターと DB インスタンスがパブリックにアクセス可能であることを確認してください。Aurora MySQL DB クラスターが VPC のプライベートサブネットにある場合は、AWS リージョン 間で VPC ピアリングを使用します。詳細については、「VPC 内の DB クラスターに別の VPC 内の EC2 インスタンスからアクセスする」を参照してください。

Aurora MySQL DB クラスターと別の AWS リージョン の 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 ステータスと互換性がある設定が含まれていることを確認してください。これを行う方法については、「Amazon Aurora MySQL の GTID ベースレプリケーションを使用する」を参照してください。Aurora MySQL バージョン 3.01 以降では、GTID を使用しない出典からレプリケートされたトランザクションに GTID を割り当てる方法を選択できます。その設定を制御するストアドプロシージャの詳細については、mysql.rds_assign_gtids_to_anonymous_transactions (Aurora MySQL バージョン 3) を参照してください。

警告

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

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

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

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

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

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

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

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

5. レプリケーションソースでレプリケーションユーザーを作成する

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

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

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

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

データベースエンジン 手順

Aurora MySQL

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

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

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

RDS for MySQL

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

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

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

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

MySQL (外部)

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

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

現在、外部の MySQL データベースからの暗号化されたレプリケーションは Aurora MySQL バージョン 1 およびバージョン 2, 2.04.2 以上でサポートされています。

注記

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

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

  • 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 ドキュメントの「Creating SSL Certificates and Keys Using openssl」を参照してください。

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

  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 オプションは、出典とレプリカの関係のサーバーに一意の識別子を提供します。

    暗号化レプリケーションが求められない場合、バイナリログが有効で、SSL は無効な状態で外部 MySQL データベースがスタートされるようにします。

    非暗号化データ用の /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 source configuration を参照してください。

  3. mysql サービスをスタートします。

    sudo service mysqld start

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

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

次のステップに従って、データベースエンジンのバイナリログを保持します。

データベースエンジン 手順

Aurora MySQL

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' の設定パラメータを指定します。Aurora MySQL バージョン 1 の最大値は 2160 (90 日) です。Aurora MySQL バージョン 2 および 3 の最大値は 168 (7 日) です。

以下の例では、バイナリログファイルの保持期間を 6 日に設定しています。

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

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

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

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

RDS for MySQL

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

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

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

MySQL (外部)

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

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

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

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

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

次のステップに従って、データベースエンジンのレプリケーションソースのスナップショットまたはダンプを作成します。

データベースエンジン 手順

Aurora MySQL

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 エラーログで、MySQL バイナリログファイルの最後の場所を調べることでも確認できます。

  4. レプリカターゲットが別の AWS アカウント、外部 MySQL データベース、または RDS for MySQL DB インスタンスによって所有される Aurora DB クラスターである場合、Amazon Aurora DB クラスターのスナップショットからデータをロードすることはできません。代わりに、MySQL クライアントを使用して DB クラスターに接続し、mysqldump コマンドを発行することで、Aurora DB クラスターのダンプを作成します。作成した 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 インスタンスのスナップショットを作成するには

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

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

  2. リードレプリカが停止してる間に、リードレプリカに Connect して SHOW SLAVE STATUS (Aurora MySQL バージョン 1 と 2) または SHOW REPLICA STATUS (Aurora MySQL バージョン 3) コマンドを実行します。Relay_Master_Log_File フィールドから現在のバイナリログファイルの名前を、Exec_Master_Log_Pos フィールドからそのログファイルの場所を取得します。レプリケーションをスタートするときのために、これらの値を保存します。

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

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

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 へのデータのコピーに関連するネットワークコストを削減できます。また、ダンプファイルを暗号化して、ネットワーク経由で転送されるデータを保護することもできます。

次のステップに従って、レプリケーションソースのスナップショットまたはダンプをデータベースエンジンのレプリカターゲットにロードします。

データベースエンジン 手順

Aurora MySQL

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

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

  • レプリケーション出典のスナップショットが DB スナップショットである場合は、DB スナップショットから新しい Aurora MySQL DB クラスターにデータを移行できます。詳細については、「Amazon Aurora MySQL 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. レプリケーションソースでレプリケーションユーザーを作成する

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

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

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

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

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

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

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

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

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

次のステップに従って、データベースエンジンでレプリケーションを有効にします。

データベースエンジン 手順

Aurora MySQL

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

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

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

  2. DB クラスターに接続し、前の手順からのバイナリログファイルの名前と場所を使用して次のプロシージャを呼び出し、レプリケーションソースとのレプリケーションを開始します。

    次の例は、Aurora MySQL バージョン 3 の場合です。

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

SSL 暗号化を使用するには、最終値を 0 ではなく 1 に設定します。

RDS for MySQL

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

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

  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;

SSL 暗号化を使用するには、最終値を 0 ではなく 1 に設定します。

MySQL (外部)

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

  1. レプリケーションにまず必要になるバイナリログファイルの名前と場所を取得します。これらの値は、レプリケーション出典のスナップショットを作成した際、SHOW SLAVE STATUS (Aurora MySQL バージョン 1 と 2) または SHOW REPLICA STATUS (Aurora MySQL バージョン 3) コマンドから取得します。外部の 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 (Aurora MySQL バージョン 1 と 2) または START REPLICA (Aurora MySQL バージョン 3) を発行し、前のステップで確認したバイナリログファイル名と場所を使用してレプリケーション出典とのレプリケーションをスタートします。次に例を示します。

    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;
-- And one of these statements depending on your engine version:
START SLAVE; -- Aurora MySQL version 1 and 2
START REPLICA; -- Aurora MySQL version 3

レプリケーションが失敗した場合、レプリカにおいて意図しないI/Oが大幅に増加することで、パフォーマンスが低下する可能性があります。失敗した、または不要になったレプリケーションについては、レプリケーション設定を削除するためのストアドプロシージャ mysql.rds_reset_external_master を実行します。

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

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

また、レプリカターゲットがどれほどレプリケーション出典に遅れをとっているかをモニタリングするには、レプリカターゲットに接続して SHOW SLAVE STATUS (Aurora MySQL バージョン 1 と 2) および SHOW REPLICA STATUS (Aurora MySQL バージョン 3) コマンドを実行します。このコマンドの出力の Seconds Behind Master フィールドに、マスターからレプリカターゲットへのコピーの進行状況が示されます。

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

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

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

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

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

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

データベースエンジン 手順

Aurora MySQL

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

レプリカターゲットである Aurora DB クラスターに接続し、mysql.rds_stop_replication プロシージャを呼び出します。

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. レプリケーション出典のバイナリログ記録を無効にする

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

データベースエンジン 手順

Aurora MySQL

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 source 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_source と 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 オプションと入力するパスワードの間にスペースがないことを確認します。

    --host コマンドで、--user (-u)、--port、-p、mysql オプションを使用して、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 source or replica 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_source プロシージャを使用して、出典 MySQL データベースをレプリケーションマスターとして指定します。ステップ 2 で特定したマスターログファイル名とマスターログの場所を使用します。次に例を示します。

    For Aurora MySQL version 1 and 2:
CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306,
    'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);

For Aurora MySQL version 3 and higher:
CALL mysql.rds_set_external_source ('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 バージョン 3 以降)

マルチスレッドのバイナリログレプリケーションでは、SQL スレッドはリレーログからイベントを読み取り、SQL ワーカースレッドが適用されるようにキューに入れます。SQL ワーカースレッドは、コーディネータスレッドによって管理されます。バイナリログイベントは、可能な場合はパラレルに適用されます。

Aurora MySQL インスタンスがバイナリログレプリケーションを使用するように構成されている場合、レプリカインスタンスはデフォルトでシングルスレッドレプリケーションを使用します。マルチスレッドレプリケーションを有効にするには、カスタムパラメータグループの replica_parallel_workers パラメータを 0 より大きい値に設定します。

以下の構成オプションを使用して、マルチスレッドレプリケーションを微調整することができます。使用量に関する情報については、MySQL リファレンスマニュアルのレプリケーションとバイナリログのオプションと可変を参照してください。

最適な構成は、いくつかの要因によって異なります。例えば、バイナリログレプリケーションのパフォーマンスは、データベースワークロードの特性と、レプリカが実行されている DB インスタンスクラスの影響を受けます。したがって、新しいパラメータ設定を本番インスタンスに適用する前に、これらの構成パラメータに対するすべての変更を徹底的にテストすることをお勧めします。

  • replica_parallel_workers

  • replica_parallel_type

  • replica_preserve_commit_order

  • binlog_transaction_dependency_tracking

  • binlog_transaction_dependency_history_size

  • binlog_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

バイナリログレプリケーションの最適化 (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 以降のバイナリログ最適化パラメータ
Parameter デフォルト 有効な値 Description
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 以降のバイナリログ最適化パラメータ
Parameter デフォルト 有効な値 説明
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 クラスターに関連付けます。そのためには、「パラメータグループを使用する」の手順に従います。

  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 に設定されていることを確認します。パラメータグループを使用して設定パラメータの設定の詳細については、「パラメータグループを使用する」を参照してください。

  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 に設定されていることを確認します。パラメータグループを使用して設定パラメータの設定の詳細については、「パラメータグループを使用する」を参照してください。

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

    SELECT @@ aurora_binlog_use_large_read_buffer;

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

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

レプリケーション出典とレプリケーションターゲット間でのパスワードの同期

SQL ステートメントを使用してレプリケーション出典のユーザーアカウントとパスワードを変更すると、それらの変更はレプリケーションターゲットに自動的にレプリケートされます。

AWS Management Console、AWS CLI、または RDS API を使用してレプリケーション出典のマスターパスワードを変更した場合、それらの変更はレプリケーションターゲットに自動的にレプリケートされません。出典システムとターゲットシステム間でマスターユーザーとマスターパスワードを同期する場合は、レプリケーションターゲットに対して同様の変更を自分で行う必要があります。