レプリケーション - Amazon Aurora

レプリケーション

Aurora MySQL クラスターのプライマリインスタンスに接続している間に、次のストアドプロシージャを呼び出すことができます。これらのプロシージャでは、トランザクションが外部データベースから Aurora MySQL、または Aurora MySQL から外部データベースに複製される方法を管理します。Aurora MySQL を使用して、グローバルトランザクション ID (GTIDs) に基づきレプリケーションを使用する方法については、「Amazon Aurora MySQL の GTID ベースレプリケーションを使用する」を参照してください。

mysql.rds_assign_gtids_to_anonymous_transactions (Aurora MySQL バージョン 3)

を設定します。ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONSのオプションCHANGE REPLICATION SOURCE TO表示されます。これにより、レプリケーションチャネルが GTID を持たないレプリケートされたトランザクションに割り当てられます。このように、GTID ベースのレプリケーションを使用しないソースから、使用するレプリカに対してバイナリログレプリケーションを実行できます。詳細については、「CHANGE REPLICATION SOURCE TO Statement」を参照してください。そしてGTIDs のないソースから GTIDs を使用したレプリカへのレプリケーションMySQL リファレンスマニュアルを参照してください。

Syntax

CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option);

パラメータ

gtid_option

文字列値。指定できる値は次のとおりです。OFF,LOCAL、または指定された UUID。

使用に関する注意事項

このプロシージャは、コミュニティMySQLでステートメントの発行と同じ効果がありますCHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = gtid_option

GTID をONに変える必要がありますにとってgtid_optionまたは設定されるLOCALまたは特定の UUIDに設定されます。

デフォルトは OFF であり、この機能が使用されないことを意味します。

LOCALレプリカ独自の UUID を含む GTID を割り当てます (server_uuid設定)。

UUID であるパラメータを渡すと、指定された UUID を含む GTID が割り当てられます。server_uuidレプリケーションソースサーバーの設定。

この特徴をオフにするには、次の手順を実行します:

mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('OFF'); +-------------------------------------------------------------+ | Message | +-------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: OFF | +-------------------------------------------------------------+ 1 row in set (0.07 sec)

レプリカ独自の UUID を使用するには、次の手順を実行します:

mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('LOCAL'); +---------------------------------------------------------------+ | Message | +---------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: LOCAL | +---------------------------------------------------------------+ 1 row in set (0.07 sec)

指定した UUID を使用するには、次の手順を実行します:

mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('317a4760-f3dd-3b74-8e45-0615ed29de0e'); +----------------------------------------------------------------------------------------------+ | Message | +----------------------------------------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: 317a4760-f3dd-3b74-8e45-0615ed29de0e | +----------------------------------------------------------------------------------------------+ 1 row in set (0.07 sec)

mysql.rds_disable_session_binlog (Aurora MySQL バージョン 2)

sql_log_bin 変数を OFF に設定することにより、現在のセッションのバイナリログをオフにします。

Syntax

CALL mysql.rds_disable_session_binlog;

パラメータ

なし

使用に関する注意事項

Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。

Aurora では、このプロシージャは Aurora MySQL バージョン 2.12 以降の MySQL 5.7 互換バージョンでサポートされています。

注記

Aurora MySQL バージョン 3 では、SESSION_VARIABLES_ADMIN 権限を持っている場合、次のコマンドを使用して現在のセッションのバイナリログ記録を無効にできます。

SET SESSION sql_log_bin = OFF;

mysql.rds_enable_session_binlog (Aurora MySQL バージョン 2)

sql_log_bin 変数を ON に設定することにより、現在のセッションのバイナリログをオンにします。

Syntax

CALL mysql.rds_enable_session_binlog;

パラメータ

なし

使用に関する注意事項

Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。

Aurora では、このプロシージャは Aurora MySQL バージョン 2.12 以降の MySQL 5.7 互換バージョンでサポートされています。

注記

Aurora MySQL バージョン 3 では、SESSION_VARIABLES_ADMIN 権限を持っている場合、次のコマンドを使用して現在のセッションのバイナリログ記録を有効にできます。

SET SESSION sql_log_bin = ON;

mysql.rds_gtid_purged (Aurora MySQL バージョン 3)

システム変数 gtid_purged のグローバル値を特定のグローバルトランザクション識別子 (GTID) セットに設定します。gtid_purged システム変数は、サーバー上でコミットされたが、サーバー上のどのバイナリログファイルにも存在しないすべてのトランザクションの GTID で構成される GTID セットです。

MySQL 8.0 との互換性を保つため、gtid_purged の値を設定する方法が 2 つあります。

  • gtid_purged の値を、指定した GTID セットに置き換えます。

  • 指定した GTID セットを gtid_purged が既に含んでいる GTID セットに追加します。

Syntax

gtid_purged の値を、指定した GTID セットに置き換えるには

CALL mysql.rds_gtid_purged (gtid_set);

gtid_purged の値を、指定した GTID セットに追加するには

CALL mysql.rds_gtid_purged (+gtid_set);

パラメータ

gtid_set

gtid_set の値は、gtid_purged の現在値のスーパーセットでなければならず、gtid_subtract(gtid_executed,gtid_purged) と交差することはできません。つまり、新しい GTID セットには、gtid_purged に既に存在していた GTID がすべて含まれている必要がありますが、まだパージされていなかった gtid_executed 内の GTID を含むことはできません。また、gtid_set パラメータは、グローバル gtid_owned セットにある GTID、サーバー上で現在処理中のトランザクションの GTID を含むことはできません。

使用に関する注意事項

マスターユーザーが mysql.rds_gtid_purged を実行する必要があります。

この手順は Aurora MySQL バージョン 3.04 以降でサポートされています。

次の例では、GTID 3E11FA47-71CA-11E1-9E33-C80AA9429562:23 を gtid_purged グローバル変数に代入します。

CALL mysql.rds_gtid_purged('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');

mysql.rds_import_binlog_ssl_material

認証局証明書、クライアント証明書、およびクライアントキーを Aurora MySQL DB クラスターにインポートします。この情報は SSL 通信および暗号化レプリケーションに必要です。

注記

現在、この手順は、Aurora MySQL バージョン 2 (2.09.2、2.10.0、2.10.1、2.11.0) とバージョン 3 (3.01.1 以降) でサポートされています。

Syntax

CALL mysql.rds_import_binlog_ssl_material ( ssl_material );

パラメータ

ssl_material

MySQL クライアント用の以下の .pem 形式のコンテンツを含む JSON ペイロード。

  • "ssl_ca":"認証局証明書"

  • "ssl_cert":"クライアント証明書"

  • "ssl_key":"クライアントキー"

使用に関する注意事項

この手順を実行する前に、暗号化レプリケーションを準備します。

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

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

詳細については、MySQL ドキュメントの「Creating SSL Certificates and Keys Using openssl」を参照してください。

重要

暗号化レプリケーションをじゅんびしたら、SSL 接続を使用してこの手順を実行します。クライアントのキーは、安全ではない接続で転送するべきではありません。

この手順では、外部の MySQL データベースから SSL 情報を Aurora MySQL DB クラスターにインポートします。SSL 情報は、Aurora MySQL DB クラスター用の SSL 情報が含まれる .pem 形式のファイルにあります。暗号化のレプリケーション中、Aurora MySQL DB クラスターはクライアントとして MySQL データベースサーバーに動作します。Aurora MySQL 用の証明書およびキーは、.pem 形式のファイルにあります。

上記のファイルからこの情報を正しい JSON ペイロードで ssl_material パラメータにコピーできます。暗号化レプリケーションをサポートするために、この SSL 情報を Aurora MySQL DB クラスターにインポートします。

JSON ペイロードは、次のようになります。

'{"ssl_ca":"-----BEGIN CERTIFICATE----- ssl_ca_pem_body_code -----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE----- ssl_cert_pem_body_code -----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY----- ssl_key_pem_body_code -----END RSA PRIVATE KEY-----\n"}'

次の例では、SSL 情報を Aurora MySQL にインポートします。.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_next_master_log (Aurora MySQL バージョン 2)

出典データベースインスタンスのログの位置を、出典データベースインスタンスの次のバイナリログの先頭に変更します。このプロシージャは、リードレプリカでレプリケーション I/O エラー 1236 が発生した場合にのみ使用してください。

Syntax

CALL mysql.rds_next_master_log( curr_master_log );

パラメータ

curr_master_log

現在のマスターログファイルのインデックス。例えば、現在のファイルが mysql-bin-changelog.012345 という名前の場合は、インデックスは 12345 になります。現在のマスターログファイルの名前を調べるには、SHOW REPLICA STATUS コマンドを実行し、Master_Log_File フィールドを確認します。

注記

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

使用に関する注意事項

マスターユーザーが mysql.rds_next_master_log を実行する必要があります。

警告

mysql.rds_next_master_log は、レプリケーション出典であるマルチ AZ DB インスタンスのフェイルオーバーの後でレプリケーションが失敗し、Last_IO_ErrnoSHOW REPLICA STATUS フィールドが I/O エラー 1236 を示している場合にのみ呼び出してください。

mysql.rds_next_master_log を呼び出すと、フェイルオーバーイベントが発生する前にソースインスタンスのトランザクションがディスク上のバイナリログに書き込まれなかった場合、リードレプリカのデータが失われる可能性があります。

Aurora MySQL リードレプリカでレプリケーションが失敗すると仮定します。リードレプリカで SHOW REPLICA STATUS\G を実行すると、次の結果が返されます。

*************************** 1. row *************************** Replica_IO_State: Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: MasterUser Source_Port: 3306 Connect_Retry: 10 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: relaylog.012340 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Source_Log_Pos: 30223232 Relay_Log_Space: 5248928866 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Source_SSL_Allowed: No Source_SSL_CA_File: Source_SSL_CA_Path: Source_SSL_Cert: Source_SSL_Cipher: Source_SSL_Key: Seconds_Behind_Master: NULL Source_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Source_Server_Id: 67285976

Last_IO_Errno フィールドはインスタンスが I/O エラー 1236 を受け取ったことを示します。Master_Log_File フィールドは、ファイル名が mysql-bin-changelog.012345 であることを示しています。これは、ログファイルのインデックスが 12345 であることを表しています。エラーを解決するには、次のパラメータを使用して mysql.rds_next_master_log を呼び出すことができます。

CALL mysql.rds_next_master_log(12345);
注記

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

mysql.rds_next_source_log (Aurora MySQL バージョン 3)

出典データベースインスタンスのログの位置を、出典データベースインスタンスの次のバイナリログの先頭に変更します。このプロシージャは、リードレプリカでレプリケーション I/O エラー 1236 が発生した場合にのみ使用してください。

Syntax

CALL mysql.rds_next_source_log( curr_source_log );

パラメータ

curr_source_log

現在のソースログファイルのインデックス。例えば、現在のファイルが mysql-bin-changelog.012345 という名前の場合は、インデックスは 12345 になります。現在のソースログファイルの名前を調べるには、SHOW REPLICA STATUS コマンドを実行し、Source_Log_File フィールドを確認します。

使用に関する注意事項

マスターユーザーが mysql.rds_next_source_log を実行する必要があります。

警告

mysql.rds_next_source_log は、レプリケーション出典であるマルチ AZ DB インスタンスのフェイルオーバーの後でレプリケーションが失敗し、Last_IO_ErrnoSHOW REPLICA STATUS フィールドが I/O エラー 1236 を示している場合にのみ呼び出してください。

mysql.rds_next_source_log を呼び出すと、フェイルオーバーイベントが発生する前にソースインスタンスのトランザクションがディスク上のバイナリログに書き込まれなかった場合、リードレプリカのデータが失われる可能性があります。

Aurora MySQL リードレプリカでレプリケーションが失敗すると仮定します。リードレプリカで SHOW REPLICA STATUS\G を実行すると、次の結果が返されます。

*************************** 1. row *************************** Replica_IO_State: Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: MasterUser Source_Port: 3306 Connect_Retry: 10 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: relaylog.012340 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Source_Log_Pos: 30223232 Relay_Log_Space: 5248928866 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Source_SSL_Allowed: No Source_SSL_CA_File: Source_SSL_CA_Path: Source_SSL_Cert: Source_SSL_Cipher: Source_SSL_Key: Seconds_Behind_Source: NULL Source_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Source_Server_Id: 67285976

Last_IO_Errno フィールドはインスタンスが I/O エラー 1236 を受け取ったことを示します。Source_Log_File フィールドは、ファイル名が mysql-bin-changelog.012345 であることを示しています。これは、ログファイルのインデックスが 12345 であることを表しています。エラーを解決するには、次のパラメータを使用して mysql.rds_next_source_log を呼び出すことができます。

CALL mysql.rds_next_source_log(12345);

mysql.rds_remove_binlog_ssl_material

SSL 通信と暗号化レプリケーション用の認証局証明書、クライアント証明書およびクライアントキーを削除します。mysql.rds_import_binlog_ssl_material を使用してこの情報をインポートします。

Syntax

CALL mysql.rds_remove_binlog_ssl_material;

mysql.rds_reset_external_master (Aurora MySQL バージョン 2)

Aurora MySQL DB インスタンスを、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして使用しないように再設定します。

重要

この手順を実行するには、autocommit を有効にする必要があります。これを有効にするには、autocommit パラメータを 1 に設定します。パラメータの変更については、「DB パラメータグループのパラメータの変更」を参照してください。

Syntax

CALL mysql.rds_reset_external_master;

使用に関する注意事項

マスターユーザーが mysql.rds_reset_external_master を実行する必要があります。このプロシージャは、Amazon RDS の外部で動作する MySQL インスタンスのリードレプリカとしての設定が解除される MySQL DB インスタンス上で実行する必要があります。

注記

これらのストアドプロシージャは、主に Amazon RDS 外部で実行されている MySQL インスタンスのレプリケーションの有効化のために提供されています。可能な場合は、Aurora MySQL DB クラスター内のレプリケーションを管理するために、Aurora レプリカを使用することをお勧めします。Aurora MySQL DB クラスターでのレプリカの管理については、「Aurora レプリカの使用」を参照してください。

レプリケーションを使用して、Aurora MySQL の外部で実行している MySQL インスタンスからデータをインポートする方法の詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。

mysql.rds_reset_external_source (Aurora MySQL バージョン 3)

Aurora MySQL DB インスタンスを、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして使用しないように再設定します。

重要

この手順を実行するには、autocommit を有効にする必要があります。これを有効にするには、autocommit パラメータを 1 に設定します。パラメータの変更については、「DB パラメータグループのパラメータの変更」を参照してください。

Syntax

CALL mysql.rds_reset_external_source;

使用に関する注意事項

マスターユーザーが mysql.rds_reset_external_source を実行する必要があります。このプロシージャは、Amazon RDS の外部で動作する MySQL インスタンスのリードレプリカとしての設定が解除される MySQL DB インスタンス上で実行する必要があります。

注記

これらのストアドプロシージャは、主に Amazon RDS 外部で実行されている MySQL インスタンスのレプリケーションの有効化のために提供されています。可能な場合は、Aurora MySQL DB クラスター内のレプリケーションを管理するために、Aurora レプリカを使用することをお勧めします。Aurora MySQL DB クラスターでのレプリカの管理については、「Aurora レプリカの使用」を参照してください。

mysql.rds_set_binlog_source_ssl (Aurora MySQL バージョン 3)

バイナリログレプリケーションの SOURCE_SSL 暗号化を有効にします。詳細については、MySQL ドキュメントの「ステートメントに対してレプリケーションソースを変更する」を参照してください。

Syntax

CALL mysql.rds_set_binlog_source_ssl(mode);

パラメータ

モード

SOURCE_SSL 暗号化が有効になっているかを示す次の値:

  • 0SOURCE_SSL 暗号化は無効です。デフォルト: 0

  • 1SOURCE_SSL 暗号化は有効です。SSL または TLS を使用して暗号化を設定できます。

使用に関する注意事項

この手順は Aurora MySQL バージョン 3.06 以降でサポートされています。

mysql.rds_set_external_master (Aurora MySQL バージョン 2)

Aurora MySQL DB インスタンスを、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして使用するように設定します。

mysql.rds_set_external_master プロシージャは廃止されており、将来のリリースでは削除されます。代わりに mysql.rds_set_external_source を使用します。

重要

この手順を実行するには、autocommit を有効にする必要があります。これを有効にするには、autocommit パラメータを 1 に設定します。パラメータの変更については、「DB パラメータグループのパラメータの変更」を参照してください。

Syntax

CALL mysql.rds_set_external_master ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption );

パラメータ

host_name

出典データベースインスタンスとなる、Amazon RDS の外部で動作する MySQL インスタンスのホスト名または IP アドレス。

host_port

Amazon RDS の外部で動作する MySQL インスタンス (出典データベースインスタンス) で使用されるポート。ポート番号を変換する Secure Shell (SSH) ポートのレプリケーションがネットワーク設定に含まれる場合、SSH によって発行されるポート番号を指定します。

replication_user_name

Amazon RDS の外部で実行される MySQL インスタンスの REPLICATION CLIENT および REPLICATION SLAVE のアクセス許可を持つユーザーの ID。外部インスタンスのレプリケーション専用のアカウントを使用することをお勧めします。

replication_user_password

replication_user_name で指定されたユーザー ID のパスワード。

mysql_binary_log_file_name

レプリケーション情報を含む出典データベースインスタンス上のバイナリログの名前。

mysql_binary_log_file_location

mysql_binary_log_file_name バイナリログ内の場所。レプリケーションでは、この場所からレプリケーション情報の読み取りをスタートします。

binlog ファイルの名前と場所は、SHOW MASTER STATUS出典データベースインスタンス上で実行することによって決定できます。

ssl_encryption

レプリケーション接続で Secure Socket Layer (SSL) 暗号化を使用するかどうかを指定する値。1 は SSL 暗号化を使用することを指定し、0 は暗号化を使用しないことを指定します。デフォルトは 0 です。

注記

MASTER_SSL_VERIFY_SERVER_CERT オプションはサポートされていません。このオプションは 0 に設定されます。つまり、接続は暗号化されますが、証明書は検証されません。

使用に関する注意事項

マスターユーザーが mysql.rds_set_external_master を実行する必要があります。このプロシージャは、Amazon RDS の外部で動作する MySQL インスタンスのリードレプリカとして設定される MySQL DB インスタンス上で実行する必要があります。

mysql.rds_set_external_master を実行する前に、Amazon RDS の外部で動作する MySQL インスタンスを出典データベースインスタンスとして必ず設定してください。Amazon RDS の外部で動作する MySQL インスタンスに接続するには、MySQL の外部インスタンスの replication_user_name および replication_user_password アクセス権限を持つレプリケーションユーザーを示す REPLICATION CLIENT および REPLICATION SLAVE の値を指定する必要があります。

MySQL の外部インスタンスを出典データベースインスタンスとして設定するには
  1. 選択した MySQL クライアントを使用して、MySQL の外部インスタンスに接続し、レプリケーションに使用されるユーザーアカウントを作成します。次に例を示します。

    MySQL 5.7

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

    MySQL 8.0

    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password';
    注記

    セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。

  2. MySQL の外部インスタンスで、REPLICATION CLIENTREPLICATION SLAVE の権限をレプリケーションユーザーに付与します。次の例では、ドメインの 「repl_user」ユーザーに、すべてのデータベースの REPLICATION CLIENT および REPLICATION SLAVE 権限を付与します。

    MySQL 5.7

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

    MySQL 8.0

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';

暗号化されたレプリケーションを使用するには、SSL 接続を使用するようにソースデータベースインスタンスを設定します。また、mysql.rds_import_binlog_ssl_material 手順を使用して、認証局証明書、クライアント証明書、クライアントキーを DB インスタンスまたは DB クラスターにインポートします。

注記

これらのストアドプロシージャは、主に Amazon RDS 外部で実行されている MySQL インスタンスのレプリケーションの有効化のために提供されています。可能な場合は、Aurora MySQL DB クラスター内のレプリケーションを管理するために、Aurora レプリカを使用することをお勧めします。Aurora MySQL DB クラスターでのレプリカの管理については、「Aurora レプリカの使用」を参照してください。

mysql.rds_set_external_master を呼び出して Amazon RDS DB インスタンスをリードレプリカとして設定した後で、このリードレプリカで mysql.rds_start_replication を呼び出してレプリケーションプロセスをスタートできます。mysql.rds_reset_external_master (Aurora MySQL バージョン 2) を呼び出して、リードレプリカの設定を削除することもできます。

mysql.rds_set_external_master が呼び出されると、Amazon RDS では、時刻、ユーザー、set master アクションが mysql.rds_history テーブルと mysql.rds_replication_status テーブルに記録されます。

MySQL DB インスタンス上で実行すると、DB インスタンスが Amazon RDS の外部で動作する MySQL インスタンスのリードレプリカとして設定されます。次に例を示します。

call mysql.rds_set_external_master( 'Externaldb.some.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 0);

mysql.rds_set_external_master_with_auto_position (Aurora MySQL バージョン 2)

外部の MySQL インスタンスからの受信レプリケーションを受け入れるように Aurora MySQL プライマリインスタンスを設定します。このプロシージャでも、グローバルトランザクション識別子 (GTIDs) に基づき、レプリケーションが設定されます。

Aurora MySQL は遅延レプリケーションをサポートしていないため、この手順では遅延レプリケーションは設定されません。

Syntax

CALL mysql.rds_set_external_master_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption );

パラメータ

host_name

レプリケーションマスターとなる、Aurora の外部で動作する MySQL インスタンスのホスト名または IP アドレス。

host_port

Aurora の外部で動作する MySQL インスタンス (レプリケーションマスター) で使用されるポート。ポート番号を変換する Secure Shell (SSH) ポートのレプリケーションがネットワーク設定に含まれる場合、SSH によって発行されるポート番号を指定します。

replication_user_name

Aurora の外部で実行される MySQL インスタンスの REPLICATION CLIENT および REPLICATION SLAVE のアクセス許可を持つユーザーの ID。外部インスタンスのレプリケーション専用のアカウントを使用することをお勧めします。

replication_user_password

replication_user_name で指定されたユーザー ID のパスワード。

ssl_encryption

このオプションは、現在実装されていません。デフォルトは 0 です。

使用に関する注意事項

Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。

マスターユーザーが mysql.rds_set_external_master_with_auto_position を実行する必要があります。マスターユーザーは、レプリケーションターゲットとして機能する Aurora MySQL DB クラスターのプライマリインスタンスでこのプロシージャを実行します。例えば、外部の MySQL DB インスタンスまたは Aurora MySQL DB クラスターのレプリケーションターゲットになります。

この手順は Aurora MySQL バージョン 2 でサポートされています。Aurora MySQL バージョン 3 の場合は、mysql.rds_set_external_source_with_auto_position (Aurora MySQL バージョン 3)代わりにプロシージャを使用します。

mysql.rds_set_external_master_with_auto_position を実行する前に、外部の MySQL DB インスタンスがレプリケーションマスターになるように設定します。外部の MySQL インスタンスに接続するには、replication_user_name および replication_user_password の値を指定します。これらの値を使用して、MySQL の外部インスタンスで REPLICATION CLIENT および REPLICATION SLAVE アクセス許可を持つレプリケーションユーザーを示す必要があります。

外部の MySQL インスタンスをレプリケーションマスターとして設定するには
  1. 選択した MySQL クライアントを使用して、外部の MySQL インスタンスに接続し、レプリケーションに使用されるユーザーアカウントを作成します。次に例を示します。

    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
  2. 外部の MySQL インスタンスで、REPLICATION CLIENTREPLICATION SLAVE の特権をレプリケーションユーザーに付与します。次の例では、ドメインの REPLICATION CLIENT ユーザーに、すべてのデータベースの REPLICATION SLAVE および 'repl_user' 権限を付与します。

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'

mysql.rds_set_external_master_with_auto_position を呼び出すと、Amazon RDS によって特定の情報が記録されます。この情報には、時刻、ユーザー、"set master"mysql.rds_history テーブルの mysql.rds_replication_status のアクションがあります。

問題の原因となることがわかっている特定の GTID ベースのトランザクションをスキップするには、mysql.rds_skip_transaction_with_gtid ストアドプロシージャを使用します。GTID ベースのレプリケーションの使用に関する詳細については、「Amazon Aurora MySQL の GTID ベースレプリケーションを使用する」を参照してください。

Aurora プライマリインスタンス上で実行すると、以下の例では、Aurora の外部で動作する MySQL のインスタンスのリードレプリカとして動作するように Aurora クラスターを設定します。

call mysql.rds_set_external_master_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'SomePassW0rd');

mysql.rds_set_external_source (Aurora MySQL バージョン 3)

MySQL DB インスタンスを、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして設定します。

重要

この手順を実行するには、autocommit を有効にする必要があります。これを有効にするには、autocommit パラメータを 1 に設定します。パラメータの変更については、「DB パラメータグループのパラメータの変更」を参照してください。

Syntax

CALL mysql.rds_set_external_source ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption );

パラメータ

host_name

出典データベースインスタンスとなる、Amazon RDS の外部で動作する MySQL インスタンスのホスト名または IP アドレス。

host_port

Amazon RDS の外部で動作する MySQL インスタンス (出典データベースインスタンス) で使用されるポート。ポート番号を変換する Secure Shell (SSH) ポートのレプリケーションがネットワーク設定に含まれる場合、SSH によって発行されるポート番号を指定します。

replication_user_name

Amazon RDS の外部で実行される MySQL インスタンスの REPLICATION CLIENT および REPLICATION SLAVE のアクセス許可を持つユーザーの ID。外部インスタンスのレプリケーション専用のアカウントを使用することをお勧めします。

replication_user_password

replication_user_name で指定されたユーザー ID のパスワード。

mysql_binary_log_file_name

レプリケーション情報を含む出典データベースインスタンス上のバイナリログの名前。

mysql_binary_log_file_location

mysql_binary_log_file_name バイナリログ内の場所。レプリケーションでは、この場所からレプリケーション情報の読み取りをスタートします。

binlog ファイルの名前と場所は、SHOW MASTER STATUS出典データベースインスタンス上で実行することによって決定できます。

ssl_encryption

レプリケーション接続で Secure Socket Layer (SSL) 暗号化を使用するかどうかを指定する値。1 は SSL 暗号化を使用することを指定し、0 は暗号化を使用しないことを指定します。デフォルトは 0 です。

注記

このオプションを有効にするには、mysql.rds_import_binlog_ssl_material を使用してカスタム SSL 証明書をインポートしておく必要があります。カスタム SSL 証明書をインポートしていない場合は、このパラメータを 0 に設定し、mysql.rds_set_binlog_source_ssl (Aurora MySQL バージョン 3) を使用してバイナリログのレプリケーション用の SSL を有効にします。

MASTER_SSL_VERIFY_SERVER_CERT オプションはサポートされていません。このオプションは 0 に設定されます。つまり、接続は暗号化されますが、証明書は検証されません。

使用に関する注意事項

マスターユーザーが mysql.rds_set_external_source を実行する必要があります。このプロシージャは、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして設定される MySQL DB インスタンス上で実行する必要があります。

mysql.rds_set_external_source を実行する前に、Amazon RDS の外部で動作する MySQL インスタンスを出典データベースインスタンスとして必ず設定してください。Amazon RDS の外部で動作する MySQL インスタンスに接続するには、MySQL の外部インスタンスの replication_user_name および replication_user_password アクセス権限を持つレプリケーションユーザーを示す REPLICATION CLIENT および REPLICATION SLAVE の値を指定する必要があります。

MySQL の外部インスタンスを出典データベースインスタンスとして設定するには
  1. 選択した MySQL クライアントを使用して、MySQL の外部インスタンスに接続し、レプリケーションに使用されるユーザーアカウントを作成します。次に例を示します。

    MySQL 5.7

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

    MySQL 8.0

    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password';
    注記

    セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。

  2. MySQL の外部インスタンスで、REPLICATION CLIENTREPLICATION SLAVE の権限をレプリケーションユーザーに付与します。次の例では、ドメインの 「repl_user」ユーザーに、すべてのデータベースの REPLICATION CLIENT および REPLICATION SLAVE 権限を付与します。

    MySQL 5.7

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

    MySQL 8.0

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';

暗号化されたレプリケーションを使用するには、SSL 接続を使用するようにソースデータベースインスタンスを設定します。また、mysql.rds_import_binlog_ssl_material プロシージャを使用して、DB インスタンスまたは DB クラスターに認証局証明書、クライアント証明書、およびクライアントキーをインポートします。

注記

これらのストアドプロシージャは、主に Amazon RDS 外部で実行されている MySQL インスタンスのレプリケーションの有効化のために提供されています。可能な場合は、Aurora MySQL DB クラスター内のレプリケーションを管理するために、Aurora レプリカを使用することをお勧めします。Aurora MySQL DB クラスターでのレプリカの管理については、「Aurora レプリカの使用」を参照してください。

mysql.rds_set_external_source を呼び出して、Aurora MySQL DB インスタンスをリードレプリカとして設定した後、このリードレプリカに対して mysql.rds_start_replication を呼び出して、レプリケーションプロセスを開始できます。mysql.rds_reset_external_source を呼び出して、リードレプリカ設定を削除できます。

mysql.rds_set_external_source が呼び出されると、Amazon RDS では、時刻、ユーザー、set master アクションが mysql.rds_history テーブルと mysql.rds_replication_status テーブルに記録されます。

Aurora MySQL DB インスタンスに対して実行すると、次の例の示されているように、DB インスタンスが Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして設定されます。

call mysql.rds_set_external_source( 'Externaldb.some.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 0);

mysql.rds_set_external_source_with_auto_position (Aurora MySQL バージョン 3)

外部の MySQL インスタンスからの受信レプリケーションを受け入れるように Aurora MySQL プライマリインスタンスを設定します。このプロシージャでも、グローバルトランザクション識別子 (GTIDs) に基づき、レプリケーションが設定されます。

Syntax

CALL mysql.rds_set_external_source_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption );

パラメータ

host_name

レプリケーションソースとなる、Aurora の外部で動作する MySQL インスタンスのホスト名または IP アドレス。

host_port

Aurora の外部で動作する MySQL インスタンス (レプリケーションソース) で使用されるポート。ポート番号を変換する Secure Shell (SSH) ポートのレプリケーションがネットワーク設定に含まれる場合、SSH によって発行されるポート番号を指定します。

replication_user_name

Aurora の外部で実行される MySQL インスタンスの REPLICATION CLIENT および REPLICATION SLAVE のアクセス許可を持つユーザーの ID。外部インスタンスのレプリケーション専用のアカウントを使用することをお勧めします。

replication_user_password

replication_user_name で指定されたユーザー ID のパスワード。

ssl_encryption

このオプションは、現在実装されていません。デフォルトは 0 です。

注記

mysql.rds_set_binlog_source_ssl (Aurora MySQL バージョン 3) を使用して、バイナリログレプリケーション用に SSL を有効にします。

使用に関する注意事項

Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。

管理ユーザーは、mysql.rds_set_external_source_with_auto_positionプロシージャを実行しなければなりません。管理ユーザーは、レプリケーションターゲットとして機能する Aurora MySQL DB クラスターのプライマリインスタンスでこのプロシージャを実行します。例えば、外部の MySQL DB インスタンスまたは Aurora MySQL DB クラスターのレプリケーションターゲットになります。

このプロシージャは Aurora MySQL バージョン 3 でサポートされています。Aurora MySQL は遅延レプリケーションをサポートしていないため、この手順では遅延レプリケーションは設定されません。

mysql.rds_set_external_source_with_auto_position を実行する前に、外部の MySQL DB インスタンスがレプリケーションソースになるように設定します。外部の MySQL インスタンスに接続するには、replication_user_name および replication_user_password の値を指定します。これらの値を使用して、MySQL の外部インスタンスで REPLICATION CLIENT および REPLICATION SLAVE アクセス許可を持つレプリケーションユーザーを示す必要があります。

外部の MySQL インスタンスをレプリケーションソースとして設定するには
  1. 選択した MySQL クライアントを使用して、外部の MySQL インスタンスに接続し、レプリケーションに使用されるユーザーアカウントを作成します。次に例を示します。

    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
  2. 外部の MySQL インスタンスで、REPLICATION CLIENTREPLICATION SLAVE の特権をレプリケーションユーザーに付与します。次の例では、ドメインの REPLICATION CLIENT ユーザーに、すべてのデータベースの REPLICATION SLAVE および 'repl_user' 権限を付与します。

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'

mysql.rds_set_external_source_with_auto_position を呼び出すと、Amazon RDS によって特定の情報が記録されます。この情報には、時刻、ユーザー、"set master"mysql.rds_history テーブルの mysql.rds_replication_status のアクションがあります。

問題の原因となることがわかっている特定の GTID ベースのトランザクションをスキップするには、mysql.rds_skip_transaction_with_gtid/> ストアドプロシージャを使用します。GTID ベースのレプリケーションの使用に関する詳細については、「Amazon Aurora MySQL の GTID ベースレプリケーションを使用する」を参照してください。

Aurora プライマリインスタンス上で実行すると、以下の例では、Aurora の外部で動作する MySQL のインスタンスのリードレプリカとして動作するように Aurora クラスターを設定します。

call mysql.rds_set_external_source_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'SomePassW0rd');

mysql.rds_set_master_auto_position (Aurora MySQL バージョン 2)

バイナリログファイルの位置、または、グローバルトランザクション識別子 (GTID) ベースのレプリケーションモードを設定します。

Syntax

CALL mysql.rds_set_master_auto_position ( auto_position_mode );

パラメータ

auto_position_mode

ファイルの位置に基づくレプリケーション、または GTID ベースのレプリケーションかどうかを示す値:

  • 0 - バイナリログファイルの位置に基づくレプリケーション方法を使用します。デフォルト: 0

  • 1 - GTID ベースのレプリケーション方法を使用します。

使用に関する注意事項

マスターユーザーが mysql.rds_set_master_auto_position を実行する必要があります。

この手順は Aurora MySQL バージョン 2 でサポートされています。

mysql.rds_set_read_only (Aurora MySQL バージョン 3)

DB インスタンスの read_only モードをグローバルにオンまたはオフにします。

Syntax

CALL mysql.rds_set_read_only(mode);

パラメータ

モード

DB インスタンスの read_only モードがグローバルにオンまたはオフになっているかを示す値。

  • 0OFF。デフォルト値は 0 です。

  • 1ON

使用に関する注意事項

mysql.rds_set_read_only ストアドプロシージャは read_only パラメータのみを変更します。innodb_read_only パラメータはリーダー DB インスタンスでは変更できません。

read_only パラメータの変更は再起動しても持続しません。read_only に永続的な変更を加えるには、read_only DB クラスターパラメータを使用する必要があります。

この手順は Aurora MySQL バージョン 3.06 以降でサポートされています。

mysql.rds_set_session_binlog_format (Aurora MySQL バージョン 2)

現在のセッションのバイナリログ形式を設定します。

Syntax

CALL mysql.rds_set_session_binlog_format(format);

パラメータ

format

現在のセッションのバイナリログ形式を示す値:

  • STATEMENT — レプリケーションソースは、SQL ステートメントに基づいてバイナリログにイベントを書き込みます。

  • ROW — レプリケーションソースは、個々のテーブル行の変更を示すイベントをバイナリログに書き込みます。

  • MIXED — ロギングは通常、SQL ステートメントに基づきますが、特定の条件下では行に切り替わります。詳細については、MySQL ドキュメントの「混合バイナリログ形式」を参照してください。

使用に関する注意事項

Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。

このストアドプロシージャを使用するには、現在のセッションに対してバイナリログが設定されている必要があります。

Aurora では、このプロシージャは Aurora MySQL バージョン 2.12 以降の MySQL 5.7 互換バージョンでサポートされています。

mysql.rds_set_source_auto_position (Aurora MySQL バージョン 3)

バイナリログファイルの位置、または、グローバルトランザクション識別子 (GTID) ベースのレプリケーションモードを設定します。

構文

CALL mysql.rds_set_source_auto_position (auto_position_mode);

パラメータ

auto_position_mode

ファイルの位置に基づくレプリケーション、または GTID ベースのレプリケーションかどうかを示す値:

  • 0 - バイナリログファイルの位置に基づくレプリケーション方法を使用します。デフォルト: 0

  • 1 - GTID ベースのレプリケーション方法を使用します。

使用に関する注意事項

Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。

管理ユーザーは、mysql.rds_set_source_auto_positionプロシージャを実行すべきです。

mysql.rds_skip_transaction_with_gtid (Aurora MySQL バージョン 2 および 3)

Aurora プライマリインスタンスで、指定されたグローバルトランザクション識別子 (GTID) のあるトランザクションのレプリケーションをスキップします。

特定の GTID トランザクションが問題の原因となることが知られている場合、障害復旧のためにこのプロシージャを使用できます。このストアドプロシージャを使用して、問題となるトランザクションをスキップします。問題のあるトランザクションの例には、レプリケーションを無効にしたり、重要なデータを削除したり、DB インスタンスを利用不可にするトランザクションが含まれます。

Syntax

CALL mysql.rds_skip_transaction_with_gtid ( gtid_to_skip );

パラメータ

gtid_to_skip

スキップするレプリケーショントランザクションの GTID。

使用に関する注意事項

マスターユーザーが mysql.rds_skip_transaction_with_gtid を実行する必要があります。

この手順は Aurora MySQL バージョン 2 および 3 でサポートされています。

次の例では、GTID 3E11FA47-71CA-11E1-9E33-C80AA9429562:23 を使用したトランザクションのレプリケーションをスキップします。

CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');

mysql.rds_skip_repl_error

MySQL DB リードレプリカのレプリケーションエラーをスキップして、削除します。

Syntax

CALL mysql.rds_skip_repl_error;

使用に関する注意事項

マスターユーザーはリードレプリカに対して mysql.rds_skip_repl_error プロシージャを実行する必要があります。この手順の詳細については、Skipping the current replication error(現在のレプリケーションエラーをスキップする) を参照してください。

MySQL の SHOW REPLICA STATUS\G コマンドを実行して、エラーがあるかどうかを判断します。レプリケーションエラーが重要ではない場合、mysql.rds_skip_repl_error を実行して、エラーをスキップすることができます。複数のエラーがある場合、mysql.rds_skip_repl_error では、初期のエラーを削除してから、他のエラーが存在することを警告します。その後で SHOW REPLICA STATUS\G を使用して、次のエラーに対処するための適切な対応方法を判断することができます。戻り値の詳細については、MySQL ドキュメントの「SHOW REPLICA STATUS statement」(SHOW REPLICA STATUS ステートメント) を参照してください。

注記

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

Aurora MySQL でのレプリケーションエラーの対処方法の詳細については、「MySQL のリードレプリケーションのエラーの診断と解決」を参照してください。

レプリケーション停止エラー

mysql.rds_skip_repl_error プロシージャを呼び出すと、レプリカがダウンしているか無効であることを示すエラーメッセージが表示されることがあります。

このエラーメッセージは、リードレプリカではなくプライマリインスタンスでプロシージャを実行した場合に表示されます。このプロシージャを機能させるには、リードレプリカに対してこのプロシージャを実行する必要があります。

このエラーメッセージは、リードレプリカに対してプロシージャを実行したが、レプリケーションを正常に再開できない場合にも表示されることがあります。

多数のエラーをスキップする必要がある場合は、レプリケーションの遅延により、バイナリログ (binlog) ファイルがデフォルトの保持期間を超えて増大する場合があります。この場合、バイナリログファイルがリードレプリカで再生される前に破棄されるため、致命的なエラーが発生することがあります。この破棄によりレプリケーションが停止し、mysql.rds_skip_repl_error コマンドを呼び出してレプリケーションエラーをスキップすることができなくなります。

この問題は、出典データベースインスタンスでバイナリログファイルの保持時間を増加させることで軽減できます。バイナリログ保持時間を長くすると、レプリケーションを再開し、必要に応じて mysql.rds_skip_repl_error コマンドを使用できるようになります。

バイナリログの保持期間を設定するには、「mysql.rds_set_configuration」の手順を使用して、DB クラスターのバイナリログファイルの保持期間に合わせて、'binlog retention hours' の設定パラメータを指定します。以下の例では、バイナリログファイルの保持期間を 48 時間に設定しています。

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

mysql.rds_start_replication

Aurora MySQL DB クラスターからのレプリケーションを開始します。

注記

mysql.rds_start_replication_until (Aurora MySQL バージョン 3) または mysql.rds_start_replication_until_gtid (Aurora MySQL バージョン 3) ストアドプロシージャを使用して、Aurora MySQL DB インスタンスからのレプリケーションを開始し、指定したバイナリログファイルの場所でレプリケーションを停止できます。

Syntax

CALL mysql.rds_start_replication;

使用に関する注意事項

マスターユーザーが mysql.rds_start_replication を実行する必要があります。

Amazon RDS の外部の MySQL インスタンスからデータをインポートするには、mysql.rds_set_external_master または mysql.rds_set_external_source を呼び出してレプリケーション設定を構築した後、リードレプリカに対して mysql.rds_start_replication を呼び出して、レプリケーションプロセスを開始します。詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。

Amazon RDS の外部の MySQL インスタンスにデータをエクスポートするには、リードレプリカに対して mysql.rds_start_replicationmysql.rds_stop_replication を呼び出して、バイナリログの消去などのレプリケーションアクションを制御します。詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。

リードレプリカで mysql.rds_start_replication を呼び出すことで、mysql.rds_stop_replication の呼び出しによって前に停止したレプリケーションプロセスを再開することもできます。詳細については、「レプリケーション停止エラー」を参照してください。

mysql.rds_start_replication_until (Aurora MySQL バージョン 3)

Aurora MySQL DB クラスターからレプリケーションを開始し、指定したバイナリログファイルの場所でレプリケーションを停止します。

Syntax

CALL mysql.rds_start_replication_until ( replication_log_file , replication_stop_point );

パラメータ

replication_log_file

レプリケーション情報を含む出典データベースインスタンス上のバイナリログの名前。

replication_stop_point

replication_log_file バイナリログ内でレプリケーションが停止する場所。

使用に関する注意事項

マスターユーザーが mysql.rds_start_replication_until を実行する必要があります。

この手順は Aurora MySQL バージョン 3.04 以降でサポートされています。

mysql.rds_start_replication_until ストアドプロシージャは、以下を含むマネージドレプリケーションではサポートされていません。

replication_log_file パラメータに指定するファイル名は、出典データベースインスタンスの binlog ファイル名と一致する必要があります。

replication_stop_pointパラメータで指定した停止場所が過去の時点である場合、レプリケーションは即座に停止します。

次の例では、レプリケーションをスタートし、120 バイナリログファイルの場所 mysql-bin-changelog.000777 に達するまで変更をレプリケートします。

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

mysql.rds_start_replication_until_gtid (Aurora MySQL バージョン 3)

Aurora MySQL DB クラスターからのレプリケーションを開始し、指定したグローバルトランザクション識別子 (GTID) の後でレプリケーションを停止します。

Syntax

CALL mysql.rds_start_replication_until_gtid(gtid);

パラメータ

gtid

レプリケーションがその後で停止する GTID。

使用に関する注意事項

マスターユーザーが mysql.rds_start_replication_until_gtid を実行する必要があります。

この手順は Aurora MySQL バージョン 3.04 以降でサポートされています。

mysql.rds_start_replication_until_gtid ストアドプロシージャは、以下を含むマネージドレプリケーションではサポートされていません。

gtidパラメータで指定したトランザクションがレプリカによって既に実行されている場合、レプリケーションは即座に停止します。

次の例では、レプリケーションをスタートし、GTID 3E11FA47-71CA-11E1-9E33-C80AA9429562:23 に達するまで変更をレプリケートします。

call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');

mysql.rds_stop_replication

MySQL DB インスタンスからのレプリケーションを停止します。

Syntax

CALL mysql.rds_stop_replication;

使用に関する注意事項

マスターユーザーが mysql.rds_stop_replication を実行する必要があります。

Amazon RDS の外部で動作する MySQL インスタンスからデータをインポートするようにレプリケーションを設定している場合は、リードレプリカで mysql.rds_stop_replication を呼び出して、インポートが完了した後でレプリケーションプロセスを停止することができます。詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。

Amazon RDS の外部にある MySQL インスタンスにデータをエクスポートするようにレプリケーションを設定している場合は、リードレプリカで mysql.rds_start_replicationmysql.rds_stop_replication を呼び出して、バイナリログの消去などのレプリケーションアクションを制御できます。詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。

mysql.rds_stop_replication ストアドプロシージャは、以下を含むマネージドレプリケーションではサポートされていません。