# Aurora MySQL ストアドプロシージャリファレンス
Aurora MySQL DB クラスターを管理するには、組み込みストアドプロシージャを呼び出します。
**Topics**
+ [グローバルステータス履歴の収集と維持](mysql-stored-proc-gsh.md)
+ [バイナリログレプリケーションの設定、開始、停止](mysql-stored-proc-replicating.md)
+ [セッションやクエリの終了](mysql-stored-proc-ending.md)
+ [GTID を使用したトランザクションのレプリケーション](mysql-stored-proc-gtid.md)
+ [クエリログのローテーション](mysql-stored-proc-logging.md)
+ [バイナリログ構成の設定と表示](mysql-stored-proc-configuring.md)
# グローバルステータス履歴の収集と維持
Amazon RDS は、ステータス変数の値のスナップショットを掲示的に取得し、前回のスナップショット後の変化とともにテーブルに書き込む一連のプロシージャを提供します。このインフラストラクチャは Global Status History (GoSH) と呼ばれます。詳細については、「[Managing the Global Status History](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH)」(Global Status History の管理) を参照してください。
以下のストアドプロシージャは、Global Status History (GoSH) の収集方法と保守方法を管理します。
**Topics**
+ [mysql.rds\$1collect\$1global\$1status\$1history](#mysql_rds_collect_global_status_history)
+ [mysql.rds\$1disable\$1gsh\$1collector](#mysql_rds_disable_gsh_collector)
+ [mysql.rds\$1disable\$1gsh\$1rotation](#mysql_rds_disable_gsh_rotation)
+ [mysql.rds\$1enable\$1gsh\$1collector](#mysql_rds_enable_gsh_collector)
+ [mysql.rds\$1enable\$1gsh\$1rotation](#mysql_rds_enable_gsh_rotation)
+ [mysql.rds\$1rotate\$1global\$1status\$1history](#mysql_rds_rotate_global_status_history)
+ [mysql.rds\$1set\$1gsh\$1collector](#mysql_rds_set_gsh_collector)
+ [mysql.rds\$1set\$1gsh\$1rotation](#mysql_rds_set_gsh_rotation)
## mysql.rds\$1collect\$1global\$1status\$1history
Global Status History (GoSH) のスナップショットをオンデマンドで作成します。
### 構文
```
CALL mysql.rds_collect_global_status_history;
```
## mysql.rds\$1disable\$1gsh\$1collector
Global Status History (GoSH) によって作成されたスナップショットを無効にします。
### 構文
```
CALL mysql.rds_disable_gsh_collector;
```
## mysql.rds\$1disable\$1gsh\$1rotation
`mysql.global_status_history` テーブルのローテーションをオフにします。
### 構文
```
CALL mysql.rds_disable_gsh_rotation;
```
## mysql.rds\$1enable\$1gsh\$1collector
Global Status History (GoSH) をオンにして、`rds_set_gsh_collector` で指定された間隔でデフォルトのスナップショットを作成します。
### 構文
```
CALL mysql.rds_enable_gsh_collector;
```
## mysql.rds\$1enable\$1gsh\$1rotation
`rds_set_gsh_rotation` で指定された間隔での `mysql.global_status_history` テーブルのコンテンツの `mysql.global_status_history_old` へのローテーションをオンにします。
### 構文
```
CALL mysql.rds_enable_gsh_rotation;
```
## mysql.rds\$1rotate\$1global\$1status\$1history
`mysql.global_status_history` テーブルのコンテンツを `mysql.global_status_history_old` にオンデマンドでローテーションします。
### 構文
```
CALL mysql.rds_rotate_global_status_history;
```
## mysql.rds\$1set\$1gsh\$1collector
Global Status History (GoSH) によって作成されたスナップショットの間隔を分単位で指定します。
### 構文
```
CALL mysql.rds_set_gsh_collector(intervalPeriod);
```
### パラメータ
*intervalPeriod*
スナップショット作成の間隔 (分単位)。デフォルト値は `5` です。
## mysql.rds\$1set\$1gsh\$1rotation
`mysql.global_status_history` テーブルのローテーション間隔を日単位で指定します。
### 構文
```
CALL mysql.rds_set_gsh_rotation(intervalPeriod);
```
### パラメータ
*intervalPeriod*
テーブルのローテーション間隔 (日単位)。デフォルト値は `7` です。
# バイナリログレプリケーションの設定、開始、停止
Aurora MySQL クラスターのプライマリインスタンスに接続している間に、次のストアドプロシージャを呼び出すことができます。これらのプロシージャでは、トランザクションが外部データベースから Aurora MySQL、または Aurora MySQL から外部データベースに複製される方法を管理します。
**Topics**
+ [mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL バージョン 2)](#mysql_rds_disable_session_binlog)
+ [mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL バージョン 2)](#mysql_rds_enable_session_binlog)
+ [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material)
+ [mysql.rds\$1next\$1master\$1log (Aurora MySQL バージョン 2)](#mysql_rds_next_master_log)
+ [mysql.rds\$1next\$1source\$1log (Aurora MySQL バージョン 3)](#mysql_rds_next_source_log)
+ [mysql.rds\$1remove\$1binlog\$1ssl\$1material](#mysql_rds_remove_binlog_ssl_material)
+ [mysql.rds\$1reset\$1external\$1master (Aurora MySQL バージョン 2)](#mysql_rds_reset_external_master)
+ [mysql.rds\$1reset\$1external\$1source (Aurora MySQL バージョン 3)](#mysql_rds_reset_external_source)
+ [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL バージョン 3)](#mysql_rds_set_binlog_source_ssl)
+ [mysql.rds\$1set\$1external\$1master (Aurora MySQL バージョン 2)](#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1source (Aurora MySQL バージョン 3)](#mysql_rds_set_external_source)
+ [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL バージョン 2)](#mysql_rds_set_external_master_with_auto_position)
+ [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL バージョン 3)](#mysql_rds_set_external_source_with_auto_position)
+ [mysql.rds\$1set\$1master\$1auto\$1position (Aurora MySQL バージョン 2)](#mysql_rds_set_master_auto_position)
+ [mysql.rds\$1set\$1read\$1only (Aurora MySQL バージョン 3)](#mysql_rds_set_read_only)
+ [mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL バージョン 2)](#mysql_rds_set_session_binlog_format)
+ [mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL バージョン 3)](#mysql_rds_set_source_auto_position)
+ [mysql.rds\$1skip\$1repl\$1error](#mysql_rds_skip_repl_error)
+ [mysql.rds\$1start\$1replication](#mysql_rds_start_replication)
+ [mysql.rds\$1start\$1replication\$1until(Aurora MySQL バージョン 3)](#mysql_rds_start_replication_until)
+ [mysql.rds\$1stop\$1replication](#mysql_rds_stop_replication)
## mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL バージョン 2)
`sql_log_bin` 変数を `OFF` に設定することにより、現在のセッションのバイナリログをオフにします。
### 構文
```
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\$1enable\$1session\$1binlog (Aurora MySQL バージョン 2)
`sql_log_bin` 変数を `ON` に設定することにより、現在のセッションのバイナリログをオンにします。
### 構文
```
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\$1import\$1binlog\$1ssl\$1material
認証局証明書、クライアント証明書、およびクライアントキーを Aurora MySQL DB クラスターにインポートします。この情報は SSL 通信および暗号化レプリケーションに必要です。
**注記**
現在、この手順は、Aurora MySQL バージョン 2 (2.09.2、2.10.0、2.10.1、2.11.0) とバージョン 3 (3.01.1 以降) でサポートされています。
### 構文
```
CALL mysql.rds_import_binlog_ssl_material (
ssl_material
);
```
### パラメータ
*ssl\$1material*
MySQL クライアント用の以下の .pem 形式のコンテンツを含む JSON ペイロード。
+ "ssl\$1ca":"*認証局証明書*"
+ "ssl\$1cert":"*クライアント証明書*"
+ "ssl\$1key":"*クライアントキー*"
### 使用に関する注意事項
この手順を実行する前に、暗号化レプリケーションを準備します。
+ 外部の MySQL 出典データベースインスタンスで有効になった SSL がなく、またクライアントキーおよびクライアント証明書が準備されていない場合、MySQL データベースサーバーで SSL を有効にし、必要なクライアントキーおよびクライアントの証明書を生成します。
+ SSL が外部出典データベースインスタンスで有効になっている場合は、Aurora MySQL DB クラスターにクライアントキーおよび証明書を提供します。これらがない場合は、Aurora MySQL DB クラスター用に新しいキーと証明書を生成します。クライアント証明書に署名するには、外部の MySQL 出典データベースインスタンスで SSL の設定に使用した認証局キーが必要です。
詳細については、MySQL ドキュメントの「[Creating SSL Certificates and Keys Using openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html)」を参照してください。
**重要**
暗号化レプリケーションをじゅんびしたら、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\$1next\$1master\$1log (Aurora MySQL バージョン 2)
出典データベースインスタンスのログの位置を、出典データベースインスタンスの次のバイナリログの先頭に変更します。このプロシージャは、リードレプリカでレプリケーション I/O エラー 1236 が発生した場合にのみ使用してください。
### 構文
```
CALL mysql.rds_next_master_log(
curr_master_log
);
```
### パラメータ
*curr\$1master\$1log*
現在のマスターログファイルのインデックス。例えば、現在のファイルが `mysql-bin-changelog.012345` という名前の場合は、インデックスは 12345 になります。現在のマスターログファイルの名前を調べるには、`SHOW REPLICA STATUS` コマンドを実行し、`Master_Log_File` フィールドを確認します。
### 使用に関する注意事項
マスターユーザーが `mysql.rds_next_master_log` を実行する必要があります。
**警告**
`mysql.rds_next_master_log` は、レプリケーション出典であるマルチ AZ DB インスタンスのフェイルオーバーの後でレプリケーションが失敗し、`Last_IO_Errno` の `SHOW 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.rds\$1next\$1source\$1log (Aurora MySQL バージョン 3)
出典データベースインスタンスのログの位置を、出典データベースインスタンスの次のバイナリログの先頭に変更します。このプロシージャは、リードレプリカでレプリケーション I/O エラー 1236 が発生した場合にのみ使用してください。
### 構文
```
CALL mysql.rds_next_source_log(
curr_source_log
);
```
### パラメータ
*curr\$1source\$1log*
現在のソースログファイルのインデックス。例えば、現在のファイルが `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_Errno` の `SHOW REPLICA STATUS` フィールドが I/O エラー 1236 を示している場合にのみ呼び出してください。
`mysql.rds_next_source_log` を呼び出すと、フェイルオーバーイベントが発生する前にソースインスタンスのトランザクションがディスク上のバイナリログに書き込まれなかった場合、リードレプリカのデータが失われる可能性があります。ソースインスタンスのパラメータ `sync_binlog` および `innodb_support_xa` を `1` に設定することで、このような問題が発生する可能性を軽減できますが、パフォーマンスが低下する恐れがあります。詳細については、
### 例
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\$1remove\$1binlog\$1ssl\$1material
SSL 通信と暗号化レプリケーション用の認証局証明書、クライアント証明書およびクライアントキーを削除します。[mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) を使用してこの情報をインポートします。
### 構文
```
CALL mysql.rds_remove_binlog_ssl_material;
```
## mysql.rds\$1reset\$1external\$1master (Aurora MySQL バージョン 2)
Aurora MySQL DB インスタンスを、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして使用しないように再設定します。
**重要**
この手順を実行するには、`autocommit` を有効にする必要があります。これを有効にするには、`autocommit` パラメータを `1` に設定します。パラメータの変更については、「[Amazon Aurora の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
### 構文
```
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 レプリカの使用](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas)」を参照してください。
レプリケーションを使用して、Aurora MySQL の外部で実行している MySQL インスタンスからデータをインポートする方法の詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。
## mysql.rds\$1reset\$1external\$1source (Aurora MySQL バージョン 3)
Aurora MySQL DB インスタンスを、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして使用しないように再設定します。
**重要**
この手順を実行するには、`autocommit` を有効にする必要があります。これを有効にするには、`autocommit` パラメータを `1` に設定します。パラメータの変更については、「[Amazon Aurora の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
### 構文
```
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 レプリカの使用](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas)」を参照してください。
## mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL バージョン 3)
バイナリログレプリケーションの `SOURCE_SSL` 暗号化を有効にします。詳細については、MySQL ドキュメントの「[CHANGE REPLICATION SOURCE TO ステートメント](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html)」を参照してください。
### 構文
```
CALL mysql.rds_set_binlog_source_ssl(mode);
```
### パラメータ
*モード*
`SOURCE_SSL` 暗号化が有効になっているかを示す次の値:
+ `0` – `SOURCE_SSL` 暗号化は無効になっています。デフォルトは `0` です。
+ `1` – `SOURCE_SSL` 暗号化は有効にされています。SSL または TLS を使用して暗号化を設定できます。
### 使用に関する注意事項
このプロシージャは、Aurora MySQL バージョン 3.06 以降でサポートされています。
## mysql.rds\$1set\$1external\$1master (Aurora MySQL バージョン 2)
Aurora MySQL DB インスタンスを、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして使用するように設定します。
`mysql.rds_set_external_master` プロシージャは廃止されており、将来のリリースでは削除されます。代わりに `mysql.rds\$1set\$1external\$1source` を使用します。
**重要**
この手順を実行するには、`autocommit` を有効にする必要があります。これを有効にするには、`autocommit` パラメータを `1` に設定します。パラメータの変更については、「[Amazon Aurora の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
### 構文
```
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\$1name*
出典データベースインスタンスとなる、Amazon RDS の外部で動作する MySQL インスタンスのホスト名または IP アドレス。
*host\$1port*
Amazon RDS の外部で動作する MySQL インスタンス (出典データベースインスタンス) で使用されるポート。ポート番号を変換する Secure Shell (SSH) ポートのレプリケーションがネットワーク設定に含まれる場合、SSH によって発行されるポート番号を指定します。
*replication\$1user\$1name*
Amazon RDS の外部で実行される MySQL インスタンスの `REPLICATION CLIENT` および `REPLICATION SLAVE` のアクセス許可を持つユーザーの ID。外部インスタンスのレプリケーション専用のアカウントを使用することをお勧めします。
*replication\$1user\$1password*
`replication_user_name` で指定されたユーザー ID のパスワード。
*mysql\$1binary\$1log\$1file\$1name*
レプリケーション情報を含む出典データベースインスタンス上のバイナリログの名前。
*mysql\$1binary\$1log\$1file\$1location*
`mysql_binary_log_file_name` バイナリログ内の場所。レプリケーションでは、この場所からレプリケーション情報の読み取りをスタートします。
binlog ファイルの名前と場所は、`SHOW MASTER STATUS`出典データベースインスタンス上で実行することによって決定できます。
*ssl\$1encryption*
レプリケーション接続で 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';
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
1. MySQL の外部インスタンスで、`REPLICATION CLIENT` と `REPLICATION SLAVE` の権限をレプリケーションユーザーに付与します。次の例では、ドメインの 「repl\$1user」ユーザーに、すべてのデータベースの `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\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) 手順を使用して、DB インスタンスあるいは DB クラスターに認証局証明書、クライアント証明書およびクライアントキーをインポートします。
**注記**
これらのストアドプロシージャは、主に Amazon RDS 外部で実行されている MySQL インスタンスのレプリケーションの有効化のために提供されています。可能な場合は、Aurora MySQL DB クラスター内のレプリケーションを管理するために、Aurora レプリカを使用することをお勧めします。Aurora MySQL DB クラスターでのレプリカの管理については、「[Aurora レプリカの使用](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas)」を参照してください。
`mysql.rds_set_external_master` を呼び出して Amazon RDS DB インスタンスをリードレプリカとして設定した後で、このリードレプリカで [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) を呼び出してレプリケーションプロセスをスタートできます。[mysql.rds\$1reset\$1external\$1master (Aurora MySQL バージョン 2)](#mysql_rds_reset_external_master) を呼び出して、リードレプリカの設定を削除することもできます。
`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,
1);
```
## mysql.rds\$1set\$1external\$1source (Aurora MySQL バージョン 3)
Aurora MySQL DB インスタンスを、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして使用するように設定します。
**重要**
この手順を実行するには、`autocommit` を有効にする必要があります。これを有効にするには、`autocommit` パラメータを `1` に設定します。パラメータの変更については、「[Amazon Aurora の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
### 構文
```
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\$1name*
出典データベースインスタンスとなる、Amazon RDS の外部で動作する MySQL インスタンスのホスト名または IP アドレス。
*host\$1port*
Amazon RDS の外部で動作する MySQL インスタンス (出典データベースインスタンス) で使用されるポート。ポート番号を変換する Secure Shell (SSH) ポートのレプリケーションがネットワーク設定に含まれる場合、SSH によって発行されるポート番号を指定します。
*replication\$1user\$1name*
Amazon RDS の外部で実行される MySQL インスタンスの `REPLICATION CLIENT` および `REPLICATION SLAVE` のアクセス許可を持つユーザーの ID。外部インスタンスのレプリケーション専用のアカウントを使用することをお勧めします。
*replication\$1user\$1password*
`replication_user_name` で指定されたユーザー ID のパスワード。
*mysql\$1binary\$1log\$1file\$1name*
レプリケーション情報を含む出典データベースインスタンス上のバイナリログの名前。
*mysql\$1binary\$1log\$1file\$1location*
`mysql_binary_log_file_name` バイナリログ内の場所。レプリケーションでは、この場所からレプリケーション情報の読み取りをスタートします。
binlog ファイルの名前と場所は、`SHOW MASTER STATUS`出典データベースインスタンス上で実行することによって決定できます。
*ssl\$1encryption*
レプリケーション接続で Secure Socket Layer (SSL) 暗号化を使用するかどうかを指定する値。1 は SSL 暗号化を使用することを指定し、0 は暗号化を使用しないことを指定します。デフォルトは 0 です。
このオプションを有効にするには、[mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) を使用してカスタム SSL 証明書をインポートしておく必要があります。カスタム SSL 証明書をインポートしていない場合は、このパラメータを 0 に設定し、[mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL バージョン 3)](#mysql_rds_set_binlog_source_ssl) を使用してバイナリログレプリケーション用の SSL を有効にします。
`SOURCE_SSL_VERIFY_SERVER_CERT` オプションはサポートされていません。このオプションは 0 に設定されます。つまり、接続は暗号化されますが、証明書は検証されません。
### 使用に関する注意事項
管理ユーザーは、`mysql.rds_set_external_source`プロシージャを実行すべきです。このプロシージャは、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして設定される Aurora 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 の外部インスタンスに接続し、レプリケーションに使用されるユーザーアカウントを作成します。以下に例を示します。
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
1. MySQL の外部インスタンスで、`REPLICATION CLIENT` と `REPLICATION SLAVE` の権限をレプリケーションユーザーに付与します。次の例では、ドメインの 「repl\$1user」ユーザーに、すべてのデータベースの `REPLICATION CLIENT` および `REPLICATION SLAVE` 特権を付与します。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
暗号化されたレプリケーションを使用するには、SSL 接続を使用するように出典データベースインスタンスを設定します。また、[mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html) プロシージャを使用して、DB インスタンスまたは DB クラスターに認証局証明書、クライアント証明書、およびクライアントキーをインポートします。
**注記**
これらのストアドプロシージャは、主に Amazon RDS 外部で実行されている MySQL インスタンスのレプリケーションの有効化のために提供されています。可能な場合は、Aurora MySQL DB クラスター内のレプリケーションを管理するために、Aurora レプリカを使用することをお勧めします。Aurora MySQL DB クラスターでのレプリカの管理については、「[Aurora レプリカの使用](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas)」を参照してください。
`mysql.rds_set_external_source` を呼び出して Aurora MySQL DB インスタンスをリードレプリカとして設定したら、このリードレプリカで [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) を呼び出してレプリケーションプロセスを開始できます。[mysql.rds\$1reset\$1external\$1source (Aurora MySQL バージョン 3)](#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,
1);
```
## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL バージョン 2)
外部の MySQL インスタンスからの受信レプリケーションを受け入れるように Aurora MySQL プライマリインスタンスを設定します。このプロシージャでも、グローバルトランザクション識別子 (GTIDs) に基づき、レプリケーションが設定されます。
Aurora MySQL は遅延レプリケーションをサポートしていないため、この手順では遅延レプリケーションは設定されません。
### 構文
```
CALL mysql.rds_set_external_master_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### パラメータ
*host\$1name*
レプリケーションソースとなる、Aurora の外部で動作する MySQL インスタンスのホスト名または IP アドレス。
*host\$1port*
Aurora の外部で動作する MySQL インスタンス (レプリケーションソース) で使用されるポート。ポート番号を変換する Secure Shell (SSH) ポートのレプリケーションがネットワーク設定に含まれる場合、SSH によって発行されるポート番号を指定します。
*replication\$1user\$1name*
Aurora の外部で実行される MySQL インスタンスの `REPLICATION CLIENT` および `REPLICATION SLAVE` のアクセス許可を持つユーザーの ID。外部インスタンスのレプリケーション専用のアカウントを使用することをお勧めします。
*replication\$1user\$1password*
`replication_user_name` で指定されたユーザー ID のパスワード。
*ssl\$1encryption*
このオプションは、現在実装されていません。デフォルトは 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\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL バージョン 3)](#mysql_rds_set_external_source_with_auto_position)代わりにプロシージャを使用します。
`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'
```
1. 外部の MySQL インスタンスで、`REPLICATION CLIENT` と `REPLICATION 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\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL バージョン 2 および 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) ストアドプロシージャを使用します。GTID ベースのレプリケーションの使用に関する詳細については、「[GTID ベースレプリケーションを使用する](mysql-replication-gtid.md)」を参照してください。
### 例
Aurora プライマリインスタンス上で実行すると、以下の例では、Aurora の外部で動作する MySQL のインスタンスのリードレプリカとして動作するように Aurora クラスターを設定します。
```
call mysql.rds_set_external_master_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
```
## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL バージョン 3)
外部の MySQL インスタンスからの受信レプリケーションを受け入れるように Aurora MySQL プライマリインスタンスを設定します。このプロシージャでも、グローバルトランザクション識別子 (GTIDs) に基づき、レプリケーションが設定されます。
### 構文
```
CALL mysql.rds_set_external_source_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### パラメータ
*host\$1name*
レプリケーションソースとなる、Aurora の外部で動作する MySQL インスタンスのホスト名または IP アドレス。
*host\$1port*
Aurora の外部で動作する MySQL インスタンス (レプリケーションソース) で使用されるポート。ポート番号を変換する Secure Shell (SSH) ポートのレプリケーションがネットワーク設定に含まれる場合、SSH によって発行されるポート番号を指定します。
*replication\$1user\$1name*
Aurora の外部で実行される MySQL インスタンスの `REPLICATION CLIENT` および `REPLICATION SLAVE` のアクセス許可を持つユーザーの ID。外部インスタンスのレプリケーション専用のアカウントを使用することをお勧めします。
*replication\$1user\$1password*
`replication_user_name` で指定されたユーザー ID のパスワード。
*ssl\$1encryption*
このオプションは、現在実装されていません。デフォルトは 0 です。
[mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL バージョン 3)](#mysql_rds_set_binlog_source_ssl) を使用して、バイナリログレプリケーション用の 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'
```
1. 外部の MySQL インスタンスで、`REPLICATION CLIENT` と `REPLICATION 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\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL バージョン 2 および 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) ストアドプロシージャを使用します。GTID ベースのレプリケーションの使用に関する詳細については、「[GTID ベースレプリケーションを使用する](mysql-replication-gtid.md)」を参照してください。
### 例
Aurora プライマリインスタンス上で実行すると、以下の例では、Aurora の外部で動作する MySQL のインスタンスのリードレプリカとして動作するように Aurora クラスターを設定します。
```
call mysql.rds_set_external_source_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
```
## mysql.rds\$1set\$1master\$1auto\$1position (Aurora MySQL バージョン 2)
バイナリログファイルの位置、または、グローバルトランザクション識別子 (GTID) ベースのレプリケーションモードを設定します。
### 構文
```
CALL mysql.rds_set_master_auto_position (
auto_position_mode
);
```
### パラメータ
*auto\$1position\$1mode*
ファイルの位置に基づくレプリケーション、または GTID ベースのレプリケーションかどうかを示す値:
+ `0` - バイナリログファイルの位置に基づくレプリケーション方法を使用します。デフォルトは `0` です。
+ `1` - GTID ベースのレプリケーション方法を使用します。
### 使用に関する注意事項
マスターユーザーが `mysql.rds_set_master_auto_position` を実行する必要があります。
この手順は Aurora MySQL バージョン 2 でサポートされています。
## mysql.rds\$1set\$1read\$1only (Aurora MySQL バージョン 3)
DB インスタンスの `read_only` モードをグローバルにオンまたはオフにします。
### 構文
```
CALL mysql.rds_set_read_only(mode);
```
### パラメータ
*モード*
DB インスタンスの `read_only` モードがグローバルにオンまたはオフになっているかを示す値。
+ `0` – `OFF`。デフォルトは `0` です。
+ `1` – `ON`
### 使用に関する注意事項
`mysql.rds_set_read_only` ストアドプロシージャは `read_only` パラメータのみを変更します。`innodb_read_only` パラメータはリーダー DB インスタンスでは変更できません。
`read_only` パラメータの変更は再起動しても持続しません。`read_only` に永続的な変更を加えるには、`read_only` DB クラスターパラメータを使用する必要があります。
このプロシージャは、Aurora MySQL バージョン 3.06 以降でサポートされています。
## mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL バージョン 2)
現在のセッションのバイナリログ形式を設定します。
### 構文
```
CALL mysql.rds_set_session_binlog_format(format);
```
### パラメータ
*format*
現在のセッションのバイナリログ形式を示す値:
+ `STATEMENT` — レプリケーションソースは、SQL ステートメントに基づいてバイナリログにイベントを書き込みます。
+ `ROW` — レプリケーションソースは、個々のテーブル行の変更を示すイベントをバイナリログに書き込みます。
+ `MIXED` — ロギングは通常、SQL ステートメントに基づきますが、特定の条件下では行に切り替わります。詳細については、MySQL ドキュメントの「[混合バイナリログ形式](https://dev.mysql.com/doc/refman/8.0/en/binary-log-mixed.html)」を参照してください。
### 使用に関する注意事項
Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。
このストアドプロシージャを使用するには、現在のセッションに対してバイナリログが設定されている必要があります。
Aurora では、このプロシージャは Aurora MySQL バージョン 2.12 以降の MySQL 5.7 互換バージョンでサポートされています。
## mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL バージョン 3)
バイナリログファイルの位置、または、グローバルトランザクション識別子 (GTIDs) ベースのレプリケーションモードを設定します。
### 構文
```
CALL mysql.rds_set_source_auto_position (auto_position_mode);
```
### パラメータ
*auto\$1position\$1mode*
ファイルの位置に基づくレプリケーション、または GTID ベースのレプリケーションかどうかを示す値:
+ `0` - バイナリログファイルの位置に基づくレプリケーション方法を使用します。デフォルトは `0` です。
+ `1` - GTID ベースのレプリケーション方法を使用します。
### 使用に関する注意事項
Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。
管理ユーザーは、`mysql.rds_set_source_auto_position`プロシージャを実行すべきです。
## mysql.rds\$1skip\$1repl\$1error
MySQL DB リードレプリカのレプリケーションエラーをスキップして、削除します。
### 構文
```
CALL mysql.rds_skip_repl_error;
```
### 使用に関する注意事項
マスターユーザーはリードレプリカに対して `mysql.rds_skip_repl_error` プロシージャを実行する必要があります。この手順の詳細については、「[Skipping the current replication error](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.SkipError)」(現在のレプリケーションエラーをスキップする) を参照してください。
MySQL の `SHOW REPLICA STATUS\G` コマンドを実行して、エラーがあるかどうかを判断します。レプリケーションエラーが重要ではない場合、`mysql.rds_skip_repl_error` を実行して、エラーをスキップすることができます。複数のエラーがある場合、`mysql.rds_skip_repl_error` では、初期のエラーを削除してから、他のエラーが存在することを警告します。その後で `SHOW REPLICA STATUS\G` を使用して、次のエラーに対処するための適切な対応方法を判断することができます。戻り値の詳細については、MySQL ドキュメントの「[SHOW REPLICA STATUS statement](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html)」を参照してください。
Aurora MySQL でのレプリケーションエラーの対処方法の詳細については、「[MySQL のリードレプリケーションのエラーの診断と解決](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.RR)」を参照してください。
#### レプリケーション停止エラー
`mysql.rds_skip_repl_error` プロシージャを呼び出すと、レプリカがダウンしているか無効であることを示すエラーメッセージが表示されることがあります。
このエラーメッセージは、リードレプリカではなくプライマリインスタンスでプロシージャを実行した場合に表示されます。このプロシージャを機能させるには、リードレプリカに対してこのプロシージャを実行する必要があります。
このエラーメッセージは、リードレプリカに対してプロシージャを実行したが、レプリケーションを正常に再開できない場合にも表示されることがあります。
多数のエラーをスキップする必要がある場合は、レプリケーションの遅延により、バイナリログ (binlog) ファイルがデフォルトの保持期間を超えて増大する場合があります。この場合、binlog ファイルがリードレプリカで再生される前に破棄されるため、致命的なエラーが発生することがあります。この破棄によりレプリケーションが停止し、`mysql.rds_skip_repl_error` コマンドを呼び出してレプリケーションエラーをスキップすることができなくなります。
この問題は、出典データベースインスタンスでバイナリログファイルの保持時間を増加させることで軽減できます。バイナリログ保持時間を長くすると、レプリケーションを再開し、必要に応じて `mysql.rds_skip_repl_error` コマンドを使用できるようになります。
バイナリログの保持期間を設定するには、「[mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration)」の手順を使用して、DB クラスターのバイナリログファイルの保持期間に合わせて、`'binlog retention hours'` の設定パラメータを指定します。以下の例では、バイナリログファイルの保持期間を 48 時間に設定しています。
```
CALL mysql.rds_set_configuration('binlog retention hours', 48);
```
## mysql.rds\$1start\$1replication
Aurora MySQL DB クラスターからのレプリケーションを開始します。
**注記**
[mysql.rds\$1start\$1replication\$1until(Aurora MySQL バージョン 3)](#mysql_rds_start_replication_until) または [mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL バージョン 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) ストアドプロシージャを使用して、Aurora MySQL DB インスタンスからのレプリケーションを開始し、指定したバイナリログファイルの場所でレプリケーションを停止できます。
### 構文
```
CALL mysql.rds_start_replication;
```
### 使用に関する注意事項
マスターユーザーが `mysql.rds_start_replication` を実行する必要があります。
Amazon RDS の外部の MySQL インスタンスからデータをインポートするには、[mysql.rds\$1set\$1external\$1master (Aurora MySQL バージョン 2)](#mysql_rds_set_external_master) または [mysql.rds\$1set\$1external\$1source (Aurora MySQL バージョン 3)](#mysql_rds_set_external_source) を呼び出してレプリケーション設定を構築した後、リードレプリカに対して `mysql.rds_start_replication` を呼び出して、レプリケーションプロセスを開始します。詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。
Amazon RDS の外部の MySQL インスタンスにデータをエクスポートするには、リードレプリカに対して `mysql.rds_start_replication` と `mysql.rds_stop_replication` を呼び出して、バイナリログの消去などのレプリケーションアクションを制御します。詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。
リードレプリカで `mysql.rds_start_replication` を呼び出すことで、`mysql.rds_stop_replication` の呼び出しによって前に停止したレプリケーションプロセスを再開することもできます。詳細については、「[レプリケーション停止エラー](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicationStopped)」を参照してください。
## mysql.rds\$1start\$1replication\$1until(Aurora MySQL バージョン 3)
Aurora MySQL DB クラスターからレプリケーションを開始し、指定したバイナリログファイルの場所でレプリケーションを停止します。
### 構文
```
CALL mysql.rds_start_replication_until (
replication_log_file
, replication_stop_point
);
```
### パラメータ
*replication\$1log\$1file*
レプリケーション情報を含む出典データベースインスタンス上のバイナリログの名前。
*replication\$1stop\$1point *
`replication_log_file` バイナリログ内でレプリケーションが停止する場所。
### 使用に関する注意事項
マスターユーザーが `mysql.rds_start_replication_until` を実行する必要があります。
この手順は Aurora MySQL バージョン 3.04 以降でサポートされています。
`mysql.rds_start_replication_until` ストアドプロシージャは、以下を含むマネージドレプリケーションではサポートされていません。
+ [AWS リージョン 間での Amazon Aurora MySQL DB クラスターのレプリケーション](AuroraMySQL.Replication.CrossRegion.md)
+ [Aurora リードレプリカを使用した、RDS for MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
`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\$1stop\$1replication
MySQL DB インスタンスからのレプリケーションを停止します。
### 構文
```
CALL mysql.rds_stop_replication;
```
### 使用に関する注意事項
マスターユーザーが `mysql.rds_stop_replication` を実行する必要があります。
Amazon RDS の外部で動作する MySQL インスタンスからデータをインポートするようにレプリケーションを設定している場合は、リードレプリカで `mysql.rds_stop_replication` を呼び出して、インポートが完了した後でレプリケーションプロセスを停止することができます。詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。
Amazon RDS の外部にある MySQL インスタンスにデータをエクスポートするようにレプリケーションを設定している場合は、リードレプリカで `mysql.rds_start_replication` と `mysql.rds_stop_replication` を呼び出して、バイナリログの消去などのレプリケーションアクションを制御できます。詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。
`mysql.rds_stop_replication` ストアドプロシージャは、以下を含むマネージドレプリケーションではサポートされていません。
+ [AWS リージョン 間での Amazon Aurora MySQL DB クラスターのレプリケーション](AuroraMySQL.Replication.CrossRegion.md)
+ [Aurora リードレプリカを使用した、RDS for MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
# セッションやクエリの終了
次のストアドプロシージャは、セッションまたはクエリを終了します。
**Topics**
+ [mysql.rds\$1kill](#mysql_rds_kill)
+ [mysql.rds\$1kill\$1query](#mysql_rds_kill_query)
## mysql.rds\$1kill
MySQL サーバーへの接続を終了します。
### 構文
```
CALL mysql.rds_kill(processID);
```
### パラメータ
*processID*
終了する接続スレッドの識別子。
### 使用に関する注意事項
MySQL サーバーへの個々の接続は別々のスレッドで実行されます。接続を終了するには、`mysql.rds_kill` プロシージャを使用して、その接続のスレッド ID を渡します。スレッド ID を取得するには、MySQL の [PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) コマンドを使用します。
### 例
次の例では、4243 のスレッド ID を持つ接続を終了します。
```
CALL mysql.rds_kill(4243);
```
## mysql.rds\$1kill\$1query
MySQL サーバーに対して実行中のクエリを終了します。
### 構文
```
CALL mysql.rds_kill_query(processID);
```
### パラメータ
*processID*
終了するクエリを実行しているプロセスまたはスレッドの ID。
### 使用に関する注意事項
MySQL サーバーに対して実行しているクエリを終了するには、`mysql_rds_kill_query` プロシージャを使用して、クエリを実行しているスレッドの接続 ID を渡します。これにより、プロシージャは接続を終了します。
ID を取得するには、MySQL [INFORMATION\$1SCHEMA PROCESSLIST テーブル](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html)または MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) コマンドを使用します。`SHOW PROCESSLIST` または `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` の ID 列の値は *processID* です。
### 例
次の例では、クエリスレッド ID が 230040 のクエリを停止します。
```
CALL mysql.rds_kill_query(230040);
```
# GTID を使用したトランザクションのレプリケーション
以下のストアドプロシージャは、Aurora MySQL でグローバルトランザクション識別子 (GTID) を使用してトランザクションをレプリケートする方法を制御します。Aurora MySQL を使用して、GTID に基づきレプリケーションを使用する方法については、「[GTID ベースレプリケーションを使用する](mysql-replication-gtid.md)」を参照してください。
**Topics**
+ [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL バージョン 3)](#mysql_assign_gtids_to_anonymous_transactions)
+ [mysql.rds\$1gtid\$1purged (Aurora MySQL バージョン 3)](#mysql_rds_gtid_purged)
+ [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL バージョン 2 および 3)](#mysql_rds_skip_transaction_with_gtid)
+ [mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL バージョン 3)](#mysql_rds_start_replication_until_gtid)
## mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL バージョン 3)
を設定します。`ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS`のオプション`CHANGE REPLICATION SOURCE TO`表示されます。これにより、レプリケーションチャネルが GTID を持たないレプリケートされたトランザクションに割り当てられます。このように、GTID ベースのレプリケーションを使用しないソースから、使用するレプリカに対してバイナリログレプリケーションを実行できます。詳細については、「[CHANGE REPLICATION SOURCE TO Statement」を参照してください。](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html)そして[GTIDs のないソースから GTIDs を使用したレプリカへのレプリケーション](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-assign-anon.html)の*MySQL リファレンスマニュアル*を参照してください。
### 構文
```
CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option);
```
### パラメータ
*gtid\$1option*
文字列値。指定できる値は次のとおりです。`OFF`,`LOCAL`、または指定された UUID。
### 使用に関する注意事項
このプロシージャは、コミュニティMySQLでステートメントの発行と同じ効果があります`CHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = gtid_option`。
GTID を`ON`に変える必要があります*にとってgtid\$1option*または設定される`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\$1gtid\$1purged (Aurora MySQL バージョン 3)
システム変数 `gtid_purged` のグローバル値を特定のグローバルトランザクション識別子 (GTID) セットに設定します。`gtid_purged` システム変数は、サーバー上でコミットされたが、サーバー上のどのバイナリログファイルにも存在しないすべてのトランザクションの GTID で構成される GTID セットです。
MySQL 8.0 との互換性を保つため、`gtid_purged` の値を設定する方法が 2 つあります。
+ `gtid_purged` の値を、指定した GTID セットに置き換えます。
+ 指定した GTID セットを `gtid_purged` が既に含んでいる GTID セットに追加します。
### 構文
`gtid_purged` の値を、指定した GTID セットに置き換えるには
```
CALL mysql.rds_gtid_purged (gtid_set);
```
`gtid_purged` の値を、指定した GTID セットに追加するには
```
CALL mysql.rds_gtid_purged (+gtid_set);
```
### パラメータ
*gtid\$1set*
*gtid\$1set* の値は、`gtid_purged` の現在値のスーパーセットでなければならず、`gtid_subtract(gtid_executed,gtid_purged)` と交差することはできません。つまり、新しい GTID セットには、`gtid_purged` に既に存在していた GTID がすべて含まれている必要がありますが、まだパージされていなかった `gtid_executed` 内の GTID を含むことはできません。また、*gtid\$1set* パラメータは、グローバル `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\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL バージョン 2 および 3)
Aurora プライマリインスタンスで、指定されたグローバルトランザクション識別子 (GTID) のあるトランザクションのレプリケーションをスキップします。
特定の GTID トランザクションが問題の原因となることが知られている場合、障害復旧のためにこのプロシージャを使用できます。このストアドプロシージャを使用して、問題となるトランザクションをスキップします。問題のあるトランザクションの例には、レプリケーションを無効にしたり、重要なデータを削除したり、DB インスタンスを利用不可にするトランザクションが含まれます。
### 構文
```
CALL mysql.rds_skip_transaction_with_gtid (
gtid_to_skip
);
```
### パラメータ
*gtid\$1to\$1skip*
スキップするレプリケーショントランザクションの 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\$1start\$1replication\$1until\$1gtid(Aurora MySQL バージョン 3)
Aurora MySQL DB クラスターからのレプリケーションを開始し、指定したグローバルトランザクション識別子 (GTID) の後でレプリケーションを停止します。
### 構文
```
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` ストアドプロシージャは、以下を含むマネージドレプリケーションではサポートされていません。
+ [AWS リージョン 間での Amazon Aurora MySQL DB クラスターのレプリケーション](AuroraMySQL.Replication.CrossRegion.md)
+ [Aurora リードレプリカを使用した、RDS for MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
`gtid`パラメータで指定したトランザクションがレプリカによって既に実行されている場合、レプリケーションは即座に停止します。
### 例
次の例では、レプリケーションをスタートし、GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` に達するまで変更をレプリケートします。
```
call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
# クエリログのローテーション
以下のストアドプロシージャは、MySQL ログをバックアップテーブルにローテーションします。詳細については、「[Aurora MySQL データベースのログファイル](USER_LogAccess.Concepts.MySQL.md)」を参照してください。
**Topics**
+ [mysql.rds\$1rotate\$1general\$1log](#mysql_rds_rotate_general_log)
+ [mysql.rds\$1rotate\$1slow\$1log](#mysql_rds_rotate_slow_log)
## mysql.rds\$1rotate\$1general\$1log
`mysql.general_log` テーブルをバックアップテーブルとしてローテーションさせます。
### 構文
```
CALL mysql.rds_rotate_general_log;
```
### 使用に関する注意事項
`mysql.general_log` テーブルのバックアップテーブルとしてのローテーションは、`mysql.rds_rotate_general_log` プロシージャを呼び出すことで実行できます。ログテーブルのローテーションが実行されると、現在のログテーブルがバックアップのログテーブルにコピーされ、現在のログテーブル内にあるエントリは削除されます。バックアップのログテーブルがすでに存在する場合は、現在のログテーブルをバックアップにコピーする前に、削除されます。バックアップのログテーブルは、必要に応じて照会することができます。`mysql.general_log` テーブルに対するバックアップのログテーブルは、`mysql.general_log_backup` という名前になります。
`log_output` パラメータが `TABLE` に設定されている場合にのみ、このプロシージャを実行できます。
## mysql.rds\$1rotate\$1slow\$1log
`mysql.slow_log` テーブルをバックアップテーブルとしてローテーションさせます。
### 構文
```
CALL mysql.rds_rotate_slow_log;
```
### 使用に関する注意事項
`mysql.slow_log` テーブルのバックアップテーブルとしてのローテーションは、`mysql.rds_rotate_slow_log` プロシージャを呼び出すことで実行できます。ログテーブルのローテーションが実行されると、現在のログテーブルがバックアップのログテーブルにコピーされ、現在のログテーブル内にあるエントリは削除されます。バックアップのログテーブルがすでに存在する場合は、現在のログテーブルをバックアップにコピーする前に、削除されます。
バックアップのログテーブルは、必要に応じて照会することができます。`mysql.slow_log` テーブルに対するバックアップのログテーブルは、`mysql.slow_log_backup` という名前になります。
# バイナリログ構成の設定と表示
次のストアドプロシージャは、バイナリログファイルの保存などの設定パラメータを設定および表示します。
**Topics**
+ [mysql.rds\$1set\$1configuration](#mysql_rds_set_configuration)
+ [mysql.rds\$1show\$1configuration](#mysql_rds_show_configuration)
## mysql.rds\$1set\$1configuration
バイナリログを保持する時間数またはレプリケーションを遅延させる秒数を指定します。
### 構文
```
CALL mysql.rds_set_configuration(name,value);
```
### パラメータ
*.name*
設定する設定パラメータの名前。
*値*
設定パラメータの値。
### 使用に関する注意事項
`mysql.rds_set_configuration` プロシージャは、以下の設定パラメータをサポートしています。
+ [バイナリログの保持時間](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours)
設定パラメータは永続的に保存され、DB インスタンスの再起動やフェイルオーバー後も存続します。
#### バイナリログの保持時間
`binlog retention hours` パラメータは、バイナリログファイルを保持する時間数を指定するために使用されます。Amazon Aurora では、通常、バイナリログは可能な限りすみやかに消去されますが、Aurora の外部にある MySQL データベースでのレプリケーションのためにバイナリログが必要になる場合があります。
`binlog retention hours` の初期値は `NULL` です。Aurora MySQL の場合、`NULL` はバイナリログが遅延してクリーンアップされることを意味します。Aurora MySQL バイナリログは、一定期間 (通常は 1 日以内)、システムに残ることがあります。
DB クラスターのバイナリログを保持する時間数を指定するには、`mysql.rds_set_configuration` ストアドプロシージャを使用して、次の例のように、レプリケーションを実行するのに十分な期間を指定します。
`call mysql.rds_set_configuration('binlog retention hours', 24);`
**注記**
`binlog retention hours` には、値 `0` は使用できません。
Aurora MySQL バージョン 2.11.0 以降、およびバージョン 3 DB クラスターの場合、最大 `binlog retention hours` 値は 2160 (90 日) です。
保持期間を設定したら、DB インスタンスのストレージ使用状況をモニタリングして、保持されたバイナリログに必要以上の容量が使用されないようにします。
## mysql.rds\$1show\$1configuration
バイナリログを保持する時間数。
### 構文
```
CALL mysql.rds_show_configuration;
```
### 使用に関する注意事項
Amazon RDS がバイナリログを保持する時間数を確認するには、`mysql.rds_show_configuration` ストアドプロシージャを使用します。
### 例
以下の例では、保持期間を表示しています。
```
call mysql.rds_show_configuration;
name value description
binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted.
```