# Referência de procedimentos armazenados do Aurora MySQL
Você pode gerenciar seu cluster de bancos de dados do Aurora MySQL chamando procedimentos armazenados integrados.
**Topics**
+ [
# Coletar e manter o histórico de status global
](mysql-stored-proc-gsh.md)
+ [
# Configurar, iniciar e interromper a replicação de logs binários (binlogs)
](mysql-stored-proc-replicating.md)
+ [
# Encerrar uma sessão ou consulta
](mysql-stored-proc-ending.md)
+ [
# Replicar transações com GTIDs
](mysql-stored-proc-gtid.md)
+ [
# Alternar os logs de consulta
](mysql-stored-proc-logging.md)
+ [
# Definir e mostrar a configuração de logs binários
](mysql-stored-proc-configuring.md)
# Coletar e manter o histórico de status global
O Amazon RDS fornece um conjunto de procedimentos que gera snapshots dos valores dessas variáveis de status ao longo do tempo e as grava em uma tabela, juntamente com quaisquer alterações feitas desde o último snapshot. Essa infraestrutura é chamada de histórico de status global. Para obter mais informações, consulte [Gerenciar o histórico de status global](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH).
Os procedimentos armazenados a seguir gerenciam a forma como o histórico de status global é coletado e mantido.
**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
Gera um snapshot sob demanda para o histórico de status global.
### Sintaxe
```
CALL mysql.rds_collect_global_status_history;
```
## mysql.rds\$1disable\$1gsh\$1collector
Desativa os snapshots gerados pelo histórico de status global.
### Sintaxe
```
CALL mysql.rds_disable_gsh_collector;
```
## mysql.rds\$1disable\$1gsh\$1rotation
Desativa a rotação da tabela `mysql.global_status_history`.
### Sintaxe
```
CALL mysql.rds_disable_gsh_rotation;
```
## mysql.rds\$1enable\$1gsh\$1collector
Ativa o histórico de status global para gerar snapshots padrão em intervalos especificados por `rds_set_gsh_collector`.
### Sintaxe
```
CALL mysql.rds_enable_gsh_collector;
```
## mysql.rds\$1enable\$1gsh\$1rotation
Ativa a rotação do conteúdo da tabela `mysql.global_status_history` com o da `mysql.global_status_history_old` em intervalos especificados por `rds_set_gsh_rotation`.
### Sintaxe
```
CALL mysql.rds_enable_gsh_rotation;
```
## mysql.rds\$1rotate\$1global\$1status\$1history
Reveza o conteúdo da tabela `mysql.global_status_history` para o da `mysql.global_status_history_old` sob demanda.
### Sintaxe
```
CALL mysql.rds_rotate_global_status_history;
```
## mysql.rds\$1set\$1gsh\$1collector
Especifica o intervalo em minutos entre os snapshots gerados pelo histórico de status global.
### Sintaxe
```
CALL mysql.rds_set_gsh_collector(intervalPeriod);
```
### Parâmetros
*intervalPeriod*
O intervalo em minutos entre snapshots. O valor padrão é `5`.
## mysql.rds\$1set\$1gsh\$1rotation
Especifica o intervalo em dias entre os revezamentos da tabela `mysql.global_status_history`.
### Sintaxe
```
CALL mysql.rds_set_gsh_rotation(intervalPeriod);
```
### Parâmetros
*intervalPeriod*
O intervalo em dias entre os revezamentos da tabela. O valor padrão é `7`.
# Configurar, iniciar e interromper a replicação de logs binários (binlogs)
É possível os seguintes procedimentos armazenados enquanto estiver conectado à instância primária em um cluster do Aurora MySQL. Esses procedimentos controlam como as transações são replicadas de um banco de dados externo para o Aurora MySQL ou do Aurora MySQL para um banco de dados externo.
**Topics**
+ [
## mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL versão 2)
](#mysql_rds_disable_session_binlog)
+ [
## mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL versão 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 versão 2)
](#mysql_rds_next_master_log)
+ [
## mysql.rds\$1next\$1source\$1log (Aurora MySQL versão 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 versão 2)
](#mysql_rds_reset_external_master)
+ [
## mysql.rds\$1reset\$1external\$1source (Aurora MySQL versão 3)
](#mysql_rds_reset_external_source)
+ [
## mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versão 3)
](#mysql_rds_set_binlog_source_ssl)
+ [
## mysql.rds\$1set\$1external\$1master (Aurora MySQL versão 2)
](#mysql_rds_set_external_master)
+ [
## mysql.rds\$1set\$1external\$1source (Aurora MySQL versão 3)
](#mysql_rds_set_external_source)
+ [
## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL versão 2)
](#mysql_rds_set_external_master_with_auto_position)
+ [
## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL versão 3)
](#mysql_rds_set_external_source_with_auto_position)
+ [
## mysql.rds\$1set\$1master\$1auto\$1position (Aurora MySQL versão 2)
](#mysql_rds_set_master_auto_position)
+ [
## mysql.rds\$1set\$1read\$1only (Aurora MySQL versão 3)
](#mysql_rds_set_read_only)
+ [
## mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL versão 2)
](#mysql_rds_set_session_binlog_format)
+ [
## mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL versão 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 versão 3)
](#mysql_rds_start_replication_until)
+ [
## mysql.rds\$1stop\$1replication
](#mysql_rds_stop_replication)
## mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL versão 2)
Desativa o registro em log binário para a sessão atual definindo a variável `sql_log_bin` como `OFF`.
### Sintaxe
```
CALL mysql.rds_disable_session_binlog;
```
### Parâmetros
Nenhum
### Observações de uso
Para um cluster de bancos de dados Aurora MySQL, você chama esse procedimento armazenado enquanto está conectado à instância primária.
Quanto ao Aurora, esse procedimento é compatível com o Aurora MySQL versão 2.12 e em versões posteriores compatíveis com o MySQL 5.7.
**nota**
No Aurora MySQL versão 3, é possível usar o comando a seguir para desabilitar o registro em log binário para a sessão atual, se tiver o privilégio `SESSION_VARIABLES_ADMIN`:
```
SET SESSION sql_log_bin = OFF;
```
## mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL versão 2)
Ativa o registro em log binário para a sessão atual definindo a variável `sql_log_bin` como `ON`.
### Sintaxe
```
CALL mysql.rds_enable_session_binlog;
```
### Parâmetros
Nenhum
### Observações de uso
Para um cluster de bancos de dados Aurora MySQL, você chama esse procedimento armazenado enquanto está conectado à instância primária.
Quanto ao Aurora, esse procedimento é compatível com o Aurora MySQL versão 2.12 e em versões posteriores compatíveis com o MySQL 5.7.
**nota**
No Aurora MySQL versão 3, é possível usar o comando a seguir para habilitar o registro em log binário para a sessão atual, se tiver o privilégio `SESSION_VARIABLES_ADMIN`:
```
SET SESSION sql_log_bin = ON;
```
## mysql.rds\$1import\$1binlog\$1ssl\$1material
Importa o certificado da autoridade de certificação, o certificado de cliente e a chave de cliente em um cluster de bancos de dados do Aurora MySQL. As informações são necessárias para a comunicação de SSL e a replicação criptografada.
**nota**
Atualmente, esse procedimento é compatível com o Aurora MySQL versão 2: 2.09.2, 2.10.0, 2.10.1, e 2.11.0; e versão 3: 3.01.1 e posteriores.
### Sintaxe
```
CALL mysql.rds_import_binlog_ssl_material (
ssl_material
);
```
### Parâmetros
*ssl\$1material*
A carga de JSON que contém o conteúdo dos arquivos de formato .pem a seguir de um cliente MySQL:
+ "ssl\$1ca":"*Certificado de autoridade de certificação*"
+ "ssl\$1cert":"*Certificado de cliente*"
+ "ssl\$1key":"*Chave de cliente*"
### Observações de uso
Prepare para a replicação criptografada antes de executar este procedimento:
+ Se você não tem o SSL habilitado na instância de banco de dados de origem externa do MySQL e não tem uma chave de cliente e um certificado de cliente preparados, habilite o SSL no servidor de banco de dados MySQL e gere a chave de cliente e o certificado de cliente necessários.
+ Se o SSL estiver habilitado na instância de banco de dados de origem externa, forneça uma chave e um certificado de cliente para o cluster de bancos de dados Aurora MySQL. Se você não os tiver, gere uma nova chave e certificado para o cluster de bancos de dados Aurora MySQL. Para assinar o certificado de cliente, é necessário ter a chave da autoridade de certificação usada para configurar o SSL na instância de banco de dados de origem externa do MySQL.
Para obter mais informações, consulte [Creating SSL certificates and keys using openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) na documentação do MySQL.
**Importante**
Após preparar para a replicação criptografada, use uma conexão SSL para executar este procedimento. A chave de cliente não deve ser transferida por meio de uma conexão incerta.
Este procedimento importa informações SSL de um banco de dados MySQL externo em um cluster de banco de dados Aurora MySQL. As informações de SSL estão em arquivos de formato .pem que contêm as informações SSL do cluster de banco de dados Aurora MySQL. Durante a replicação criptografada, o cluster do banco de dados de Aurora MySQL age como um cliente para o servidor de banco de dados do MySQL. Os certificados e chaves do cliente Aurora MySQL estão nos arquivos em formato .pem.
Você pode copiar informações desses arquivos no parâmetro `ssl_material` na carga de JSON correta. Para suportar a replicação criptografada, importe essas informações SSL no cluster do banco de dados Aurora MySQL.
A carga de JSON deve estar no seguinte formato.
```
'{"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"}'
```
### Exemplos
O exemplo a seguir importa informações de SSL no Aurora MySQL. Em arquivos de formato .pem, o código do corpo geralmente é maior que o código de corpo exibido no exemplo.
```
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 versão 2)
Altera a posição do log da instância de banco de dados de origem para o início do próximo log binário na instância de banco de dados de origem. Use este procedimento somente se estiver recebendo o erro 1236 de E/S de replicação em uma réplica de leitura.
### Sintaxe
```
CALL mysql.rds_next_master_log(
curr_master_log
);
```
### Parâmetros
*curr\$1master\$1log*
O índice do arquivo de log mestre atual. Por exemplo, se o arquivo atual dor denominado `mysql-bin-changelog.012345`, o índice será 12345. Para determinar o nome do arquivo de log do mestre, execute o comando `SHOW REPLICA STATUS` e veja o campo `Master_Log_File`.
### Observações de uso
O usuário mestre deve executar o procedimento `mysql.rds_next_master_log`.
**Atenção**
Chame `mysql.rds_next_master_log` somente se a replicação falhar após um failover de uma instância de banco de dados multi-AZ que for a origem da replicação, e o campo `Last_IO_Errno` do `SHOW REPLICA STATUS` reportar o erro 1236 de E/S.
Chamar `mysql.rds_next_master_log` pode resultar em perda de dados na réplica de leitura caso as transações na instância de origem não tenham sido gravadas no log binário no disco antes do evento de failover.
### Exemplos
Suponha que a replicação falhe em uma réplica de leitura do Aurora MySQL. A execução de `SHOW REPLICA STATUS\G` na réplica de leitura retorna o seguinte resultado:
```
*************************** 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
```
O campo `Last_IO_Errno` mostra que a instância está recebendo o erro 1236 de E/S. O campo `Master_Log_File` mostra que o nome do arquivo é `mysql-bin-changelog.012345`, o que significa que o índice de arquivos de log é `12345`. Para resolver o erro, chame `mysql.rds_next_master_log` com o seguinte parâmetro:
```
CALL mysql.rds_next_master_log(12345);
```
## mysql.rds\$1next\$1source\$1log (Aurora MySQL versão 3)
Altera a posição do log da instância de banco de dados de origem para o início do próximo log binário na instância de banco de dados de origem. Use este procedimento somente se estiver recebendo o erro 1236 de E/S de replicação em uma réplica de leitura.
### Sintaxe
```
CALL mysql.rds_next_source_log(
curr_source_log
);
```
### Parâmetros
*curr\$1source\$1log*
O índice do arquivo de log de origem atual. Por exemplo, se o arquivo atual dor denominado `mysql-bin-changelog.012345`, o índice será 12345. Para determinar o nome do arquivo de log de origem atual, execute o comando `SHOW REPLICA STATUS` e veja o campo `Source_Log_File`.
### Observações de uso
O usuário administrativo precisa executar o procedimento `mysql.rds_next_source_log`.
**Atenção**
Chame `mysql.rds_next_source_log` somente se a replicação falhar após um failover de uma instância de banco de dados multi-AZ que for a origem da replicação, e o campo `Last_IO_Errno` do `SHOW REPLICA STATUS` reportar o erro 1236 de E/S.
Chamar `mysql.rds_next_source_log` pode resultar em perda de dados na réplica de leitura caso as transações na instância de origem não tenham sido gravadas no log binário no disco antes do evento de failover. Você pode reduzir a chance de que isso aconteça configurando os parâmetros `sync_binlog` e `innodb_support_xa` da instância de origem como `1`, embora isso possa reduzir o desempenho.
### Exemplos
Suponha que a replicação falhe em uma réplica de leitura do Aurora MySQL. A execução de `SHOW REPLICA STATUS\G` na réplica de leitura retorna o seguinte resultado:
```
*************************** 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
```
O campo `Last_IO_Errno` mostra que a instância está recebendo o erro 1236 de E/S. O campo `Source_Log_File` mostra que o nome do arquivo é `mysql-bin-changelog.012345`, o que significa que o índice de arquivos de log é `12345`. Para resolver o erro, chame `mysql.rds_next_source_log` com o seguinte parâmetro:
```
CALL mysql.rds_next_source_log(12345);
```
## mysql.rds\$1remove\$1binlog\$1ssl\$1material
Remove o certificado de autoridade de certificado, o certificado de cliente e a chave de cliente para comunicação SSL e replicação criptografada. Essas informações são importada usando [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material).
### Sintaxe
```
CALL mysql.rds_remove_binlog_ssl_material;
```
## mysql.rds\$1reset\$1external\$1master (Aurora MySQL versão 2)
Reconfigura uma instância de banco de dados do Aurora MySQL para que não seja mais uma réplica de leitura de uma instância do MySQL executada fora do Amazon RDS.
**Importante**
Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### Sintaxe
```
CALL mysql.rds_reset_external_master;
```
### Observações de uso
O usuário mestre deve executar o procedimento `mysql.rds_reset_external_master`. Esse procedimento deve ser executado na instância de banco de dados MySQL a ser removida como a réplica de leitura de uma instância do MySQL sendo executada externamente ao Amazon RDS.
**nota**
Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Recomendamos que você use réplicas do Aurora para gerenciar a replicação em um cluster de banco de dados do Aurora MySQL sempre que possível. Para obter informações sobre como gerenciar a replicação em clusters de banco de dados do Aurora MySQL, consulte [Usar réplicas do Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
Para obter mais informações sobre como usar a replicação para importar dados de uma instância do MySQL executada fora do Aurora MySQL, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md).
## mysql.rds\$1reset\$1external\$1source (Aurora MySQL versão 3)
Reconfigura uma instância de banco de dados do Aurora MySQL para que não seja mais uma réplica de leitura de uma instância do MySQL executada fora do Amazon RDS.
**Importante**
Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### Sintaxe
```
CALL mysql.rds_reset_external_source;
```
### Observações de uso
O usuário administrativo precisa executar o procedimento `mysql.rds_reset_external_source`. Esse procedimento deve ser executado na instância de banco de dados MySQL a ser removida como a réplica de leitura de uma instância do MySQL sendo executada externamente ao Amazon RDS.
**nota**
Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Recomendamos que você use réplicas do Aurora para gerenciar a replicação em um cluster de banco de dados do Aurora MySQL sempre que possível. Para obter informações sobre como gerenciar a replicação em clusters de banco de dados do Aurora MySQL, consulte [Usar réplicas do Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
## mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versão 3)
Habilita a criptografia de `SOURCE_SSL` para replicação de logs binários. Consulte mais informações em [CHANGE REPLICATION SOURCE TO statement](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) na documentação do MySQL.
### Sintaxe
```
CALL mysql.rds_set_binlog_source_ssl(mode);
```
### Parâmetros
*modo*
Um valor que indica se a criptografia de `SOURCE_SSL` está habilitada:
+ `0`: a criptografia `SOURCE_SSL` está desabilitada. O padrão é `0`.
+ `1`: a criptografia `SOURCE_SSL` está habilitada. É possível configurar a criptografia usando SSL ou TLS.
### Observações de uso
Esse procedimento é compatível com o Aurora MySQL versão 3.06 e posterior.
## mysql.rds\$1set\$1external\$1master (Aurora MySQL versão 2)
Configura uma instância de banco de dados do Aurora MySQL para que seja uma réplica de leitura de uma instância do MySQL executada fora do Amazon RDS.
O procedimento `mysql.rds_set_external_master` está obsoleto e será removido em uma versão futura. Use `mysql.rds\$1set\$1external\$1source` em vez disso.
**Importante**
Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### Sintaxe
```
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
);
```
### Parâmetros
*host\$1name*
O nome de host ou o endereço IP da instância do MySQL executada externamente ao Amazon RDS que se tornará a instância de banco de dados de origem.
*host\$1port*
A porta usada para executar a instância do MySQL executada externamente ao Amazon RDS a ser configurada como a instância de banco de dados de origem. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH.
*replication\$1user\$1name*
O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância do MySQL executada externamente ao Amazon RDS. Recomendamos que você forneça uma conta que seja usada unicamente para a replicação com a instância externa.
*replication\$1user\$1password*
A senha do ID de usuário especificada em `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
O nome do log binário na instância de banco de dados de origem que contém as informações de replicação.
*mysql\$1binary\$1log\$1file\$1location*
O local no log binário `mysql_binary_log_file_name` no qual a replicação começa a ler as informações de replicação.
É possível determinar o nome e a localização do arquivo de binlog executando `SHOW MASTER STATUS` na instância do banco de dados de origem.
*ssl\$1encryption*
Um valor que especifica se a criptografia do Secure Sockets Layer (SSL) será usada na conexão de replicação. 1 especifica para usar criptografia de SSL, 0 especifica para não usar criptografia. O padrão é 0.
A opção `MASTER_SSL_VERIFY_SERVER_CERT` não tem suporte. Essa opção é definida como 0, o que significa que a conexão é criptografada, mas os certificados não são verificados.
### Observações de uso
O usuário mestre deve executar o procedimento `mysql.rds_set_external_master`. Esse procedimento deve ser executado na instância de banco de dados MySQL que será configurada como a réplica de leitura de uma instância do MySQL externa ao Amazon RDS.
Antes de executar `mysql.rds_set_external_master`, é necessário configurar a instância do MySQL executada externamente ao Amazon RDS para ser uma instância de banco de dados de origem. Para conectar-se à instância do MySQL sendo executada externamente ao Amazon RDS, você deve especificar valores de `replication_user_name` e `replication_user_password` que indicam um usuário de replicação com permissões de `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância externa do MySQL.
**Como configurar uma instância externa do MySQL como uma instância de banco de dados de origem**
1. Usando o cliente do MySQL de sua escolha, conecte-se à instância externa do MySQL e crie uma conta de usuário a ser usada para a replicação. Veja um exemplo a seguir.
**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';
```
**nota**
Especifique uma senha diferente do prompt mostrado aqui como prática recomendada de segurança.
1. Na instância externa do MySQL, conceda privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` para seu usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário 'repl\$1user' em todos os bancos de dados de seu domínio.
**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';
```
Para usar a replicação criptografada, configure a instância de banco de dados de origem para usar conexões SSL. Além disso, importe o certificado da autoridade de certificação, o certificado e a chave de clientes na instância de banco de dados ou no cluster do banco de dados usando o procedimento [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material).
**nota**
Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Recomendamos que você use réplicas do Aurora para gerenciar a replicação em um cluster de banco de dados do Aurora MySQL sempre que possível. Para obter informações sobre como gerenciar a replicação em clusters de banco de dados do Aurora MySQL, consulte [Usar réplicas do Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
Depois de chamar `mysql.rds_set_external_master` para configurar uma instância de banco de dados do Amazon RDS, é possível chamar [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) na réplica de leitura para iniciar o processo de replicação. É possível chamar [mysql.rds\$1reset\$1external\$1master (Aurora MySQL versão 2)](#mysql_rds_reset_external_master) para remover a configuração da réplica de leitura.
Quando `mysql.rds_set_external_master` é chamado, o Amazon RDS grava a hora, o usuário e uma ação do `set master` nas tabelas `mysql.rds_history` e `mysql.rds_replication_status`.
### Exemplos
Ao executar em uma instância de banco de dados MySQL, o exemplo a seguir configura a instância do banco de dados para ser uma réplica de leitura de uma instância do MySQL que é executada externamente ao Amazon RDS.
```
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 versão 3)
Configura uma instância de banco de dados do Aurora MySQL para que seja uma réplica de leitura de uma instância do MySQL executada fora do Amazon RDS.
**Importante**
Para executar esse procedimento, `autocommit` deve estar habilitado. Para habilitá-lo, defina o parâmetro `autocommit` como `1`. Para obter informações sobre como modificar parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
### Sintaxe
```
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
);
```
### Parâmetros
*host\$1name*
O nome de host ou o endereço IP da instância do MySQL executada externamente ao Amazon RDS que se tornará a instância de banco de dados de origem.
*host\$1port*
A porta usada para executar a instância do MySQL executada externamente ao Amazon RDS a ser configurada como a instância de banco de dados de origem. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH.
*replication\$1user\$1name*
O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância do MySQL executada externamente ao Amazon RDS. Recomendamos que você forneça uma conta que seja usada unicamente para a replicação com a instância externa.
*replication\$1user\$1password*
A senha do ID de usuário especificada em `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
O nome do log binário na instância de banco de dados de origem que contém as informações de replicação.
*mysql\$1binary\$1log\$1file\$1location*
O local no log binário `mysql_binary_log_file_name` no qual a replicação começa a ler as informações de replicação.
É possível determinar o nome e a localização do arquivo de binlog executando `SHOW MASTER STATUS` na instância do banco de dados de origem.
*ssl\$1encryption*
Um valor que especifica se a criptografia do Secure Sockets Layer (SSL) será usada na conexão de replicação. 1 especifica para usar criptografia de SSL, 0 especifica para não usar criptografia. O padrão é 0.
Você deve ter importado um certificado SSL personalizado usando [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) para habilitar essa opção. Se você não importou um certificado SSL personalizado, defina esse parâmetro como 0 e use [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versão 3)](#mysql_rds_set_binlog_source_ssl) para habilitar o SSL para replicação de log binário.
A opção `SOURCE_SSL_VERIFY_SERVER_CERT` não tem suporte. Essa opção é definida como 0, o que significa que a conexão é criptografada, mas os certificados não são verificados.
### Observações de uso
O usuário administrativo precisa executar o procedimento `mysql.rds_set_external_source`. Esse procedimento deve ser executado na instância de banco de dados do Aurora MySQL que será configurada como a réplica de leitura de uma instância do MySQL externa ao Amazon RDS.
Antes de executar `mysql.rds_set_external_source`, é necessário configurar a instância do MySQL executada externamente ao Amazon RDS para ser uma instância de banco de dados de origem. Para conectar-se à instância do MySQL sendo executada externamente ao Amazon RDS, você deve especificar valores de `replication_user_name` e `replication_user_password` que indicam um usuário de replicação com permissões de `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância externa do MySQL.
**Como configurar uma instância externa do MySQL como uma instância de banco de dados de origem**
1. Usando o cliente do MySQL de sua escolha, conecte-se à instância externa do MySQL e crie uma conta de usuário a ser usada para a replicação. Veja um exemplo a seguir.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**nota**
Especifique uma senha diferente do prompt mostrado aqui como prática recomendada de segurança.
1. Na instância externa do MySQL, conceda privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` para seu usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário 'repl\$1user' em todos os bancos de dados de seu domínio.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
Para usar a replicação criptografada, configure a instância de banco de dados de origem para usar conexões SSL. Além disso, importe o certificado de autoridade de certificação, o certificado e a chave de clientes na instância de banco de dados ou no cluster de banco de dados usando o procedimento [mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html).
**nota**
Oferecemos esses procedimentos armazenados principalmente para permitir a replicação com instâncias do MySQL externas ao Amazon RDS. Recomendamos que você use réplicas do Aurora para gerenciar a replicação em um cluster de banco de dados do Aurora MySQL sempre que possível. Para obter informações sobre como gerenciar a replicação em clusters de banco de dados do Aurora MySQL, consulte [Usar réplicas do Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas).
Depois de chamar `mysql.rds_set_external_source` para configurar uma instância de banco de dados do Aurora MySQL, é possível chamar [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) na réplica de leitura para iniciar o processo de replicação. É possível chamar [mysql.rds\$1reset\$1external\$1source (Aurora MySQL versão 3)](#mysql_rds_reset_external_source) para remover a configuração da réplica de leitura.
Quando `mysql.rds_set_external_source` é chamado, o Amazon RDS grava a hora, o usuário e uma ação do `set master` nas tabelas `mysql.rds_history` e `mysql.rds_replication_status`.
### Exemplos
Quando executado em uma instância de banco de dados do Aurora MySQL, o exemplo a seguir configura a instância de banco de dados para ser uma réplica de leitura de uma instância do MySQL que é executada externamente ao Amazon RDS.
```
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 versão 2)
Configura uma instância primária do Aurora MySQL para aceitar a replicação de entrada de uma instância externa do MySQL. Esse procedimento também configura a replicação com base em identificadores de transação global (GTIDs).
Esse procedimento não configura a replicação atrasada, pois o Aurora MySQL não oferece suporte à replicação atrasada.
### Sintaxe
```
CALL mysql.rds_set_external_master_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### Parâmetros
*host\$1name*
O nome de host ou o endereço IP da instância do MySQL sendo executada externamente ao Aurora que se torna a origem de replicação.
*host\$1port*
A porta utilizada para executar a instância do MySQL sendo executada externamente ao Aurora a ser configurada como a origem de replicação. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH.
*replication\$1user\$1name*
O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância do MySQL executada externamente ao Aurora. Recomendamos que você forneça uma conta que seja usada unicamente para a replicação com a instância externa.
*replication\$1user\$1password*
A senha do ID de usuário especificada em `replication_user_name`.
*ssl\$1encryption*
Essa opção não está implementada atualmente. O padrão é 0.
### Observações de uso
Para um cluster de bancos de dados Aurora MySQL, você chama esse procedimento armazenado enquanto está conectado à instância primária.
O usuário mestre deve executar o procedimento `mysql.rds_set_external_master_with_auto_position`. O usuário principal executa esse procedimento na instância primária de um cluster de bancos de dados Aurora MySQL que atua como um destino de replicação. Este pode ser o destino de replicação de uma instância de banco de dados externa do MySQL ou um cluster de bancos de dados Aurora MySQL.
Esse procedimento é compatível com o Aurora MySQL versão 2. Para o Aurora MySQL versão 3, prefira usar o procedimento [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL versão 3)](#mysql_rds_set_external_source_with_auto_position).
Antes de executar o `mysql.rds_set_external_master_with_auto_position`, configure a instância de banco de dados externa do MySQL para ser uma origem de replicação. Para conectar-se à instância externa do MySQL, especifique valores para `replication_user_name` e `replication_user_password`. Esses valores devem indicar um usuário de replicação que tenha as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância externa do MySQL.
**Para configurar uma instância externa do MySQL como uma origem de replicação**
1. Usando o cliente do MySQL de sua escolha, conecte-se à instância externa do MySQL e crie uma conta de usuário a ser usada para replicação. Veja um exemplo a seguir.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. Para a instância externa do MySQL, conceda os privilégios `REPLICATION CLIENT` e `REPLICATION SLAVE` ao seu usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário `'repl_user'` em todos os bancos de dados de seu domínio.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
Quando você chama `mysql.rds_set_external_master_with_auto_position`, o Amazon RDS registra algumas informações. Essas informações incluem o horário, o usuário e uma ação de `"set master"` nas tabelas `mysql.rds_history` e `mysql.rds_replication_status`.
Para ignorar uma transação específica baseada em GTID que seja conhecida por causar problemas, use o procedimento armazenado [mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL versões 2 e 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Para obter mais informações sobre como trabalhar com a replicação baseada em GTID, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md).
### Exemplos
Quando executado em uma instância primária do Aurora, o exemplo a seguir configura o cluster do Aurora para atuar como uma réplica de leitura de uma instância do MySQL executada fora do 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 versão 3)
Configura uma instância primária do Aurora MySQL para aceitar a replicação de entrada de uma instância externa do MySQL. Esse procedimento também configura a replicação com base em identificadores de transação global (GTIDs).
### Sintaxe
```
CALL mysql.rds_set_external_source_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### Parâmetros
*host\$1name*
O nome de host ou o endereço IP da instância do MySQL sendo executada externamente ao Aurora que se torna a origem de replicação.
*host\$1port*
A porta utilizada para executar a instância do MySQL sendo executada externamente ao Aurora a ser configurada como a origem de replicação. Se sua configuração de rede inclui replicação de porta Secure Shell (SSH) que converte o número da porta, especifique o número da porta exposto pelo SSH.
*replication\$1user\$1name*
O ID de um usuário com as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância do MySQL executada externamente ao Aurora. Recomendamos que você forneça uma conta que seja usada unicamente para a replicação com a instância externa.
*replication\$1user\$1password*
A senha do ID de usuário especificada em `replication_user_name`.
*ssl\$1encryption*
Essa opção não está implementada atualmente. O padrão é 0.
Use [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versão 3)](#mysql_rds_set_binlog_source_ssl) para habilitar o SSL para replicação de logs binários.
### Observações de uso
Para um cluster de bancos de dados Aurora MySQL, você chama esse procedimento armazenado enquanto está conectado à instância primária.
O usuário administrativo precisa executar o procedimento `mysql.rds_set_external_source_with_auto_position`. O usuário administrativo executa esse procedimento na instância primária de um cluster de bancos de dados Aurora MySQL que atua como um destino de replicação. Este pode ser o destino de replicação de uma instância de banco de dados externa do MySQL ou um cluster de bancos de dados Aurora MySQL.
Esse procedimento é compatível com o Aurora MySQL versão 3. Esse procedimento não configura a replicação atrasada, pois o Aurora MySQL não oferece suporte à replicação atrasada.
Antes de executar o `mysql.rds_set_external_source_with_auto_position`, configure a instância de banco de dados externa do MySQL para ser uma origem de replicação. Para conectar-se à instância externa do MySQL, especifique valores para `replication_user_name` e `replication_user_password`. Esses valores devem indicar um usuário de replicação que tenha as permissões `REPLICATION CLIENT` e `REPLICATION SLAVE` na instância externa do MySQL.
**Para configurar uma instância externa do MySQL como uma origem de replicação**
1. Usando o cliente do MySQL de sua escolha, conecte-se à instância externa do MySQL e crie uma conta de usuário a ser usada para replicação. Veja um exemplo a seguir.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. Para a instância externa do MySQL, conceda os privilégios `REPLICATION CLIENT` e `REPLICATION SLAVE` ao seu usuário de replicação. O exemplo a seguir concede privilégios de `REPLICATION CLIENT` e `REPLICATION SLAVE` ao usuário `'repl_user'` em todos os bancos de dados de seu domínio.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
Quando você chama `mysql.rds_set_external_source_with_auto_position`, o Amazon RDS registra algumas informações. Essas informações incluem o horário, o usuário e uma ação de `"set master"` nas tabelas `mysql.rds_history` e `mysql.rds_replication_status`.
Para ignorar uma transação específica baseada em GTID que seja conhecida por causar problemas, use o procedimento armazenado [mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL versões 2 e 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Para obter mais informações sobre como trabalhar com a replicação baseada em GTID, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md).
### Exemplos
Quando executado em uma instância primária do Aurora, o exemplo a seguir configura o cluster do Aurora para atuar como uma réplica de leitura de uma instância do MySQL executada fora do 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 versão 2)
Define o modo de replicação de base nas posições do arquivo de log binário ou nos identificadores de transações globais (GTIDs).
### Sintaxe
```
CALL mysql.rds_set_master_auto_position (
auto_position_mode
);
```
### Parâmetros
*auto\$1position\$1mode*
Um valor que indica se será usada a replicação de posição do arquivo de log ou a replicação com base no GTID:
+ `0`: usar o método de replicação com base na posição do arquivo de log binário. O padrão é `0`.
+ `1`: usar o método de replicação com base no GTID.
### Observações de uso
O usuário principal deve executar o procedimento `mysql.rds_set_master_auto_position`.
Esse procedimento é compatível com o Aurora MySQL versão 2.
## mysql.rds\$1set\$1read\$1only (Aurora MySQL versão 3)
Ativa ou desativa globalmente o modo `read_only` da instância de banco de dados.
### Sintaxe
```
CALL mysql.rds_set_read_only(mode);
```
### Parâmetros
*modo*
Um valor que indica se o modo `read_only` está ativado ou desativado globalmente para a instância de banco de dados:
+ `0`: `OFF`. O padrão é `0`.
+ `1` – `ON`
### Observações de uso
O procedimento `mysql.rds_set_read_only` armazenado modifica somente o parâmetro `read_only`. O parâmetro `innodb_read_only` não pode ser alterado nas instâncias de banco de dados do leitor.
A alteração do parâmetro `read_only` não persiste na reinicialização. Para fazer alterações permanentes em `read_only`, é necessário usar o parâmetro `read_only` do cluster de banco de dados.
Esse procedimento é compatível com o Aurora MySQL versão 3.06 e posterior.
## mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL versão 2)
Define o formato de log binário para a sessão atual.
### Sintaxe
```
CALL mysql.rds_set_session_binlog_format(format);
```
### Parâmetros
*formato*
Um valor que indica o formato do log binário da sessão atual:
+ `STATEMENT`: a origem de replicação grava eventos no log binário com base em declarações SQL.
+ `ROW`: a origem de replicação grava eventos no log binário que indicam alterações em linhas individuais da tabela.
+ `MIXED`: o registro em log geralmente é baseado em declarações SQL, mas muda para linhas em determinadas condições. Para receber mais informações, consulte [Mixed Binary Logging Format](https://dev.mysql.com/doc/refman/8.0/en/binary-log-mixed.html) na documentação do MySQL.
### Observações de uso
Para um cluster de bancos de dados Aurora MySQL, você chama esse procedimento armazenado enquanto está conectado à instância primária.
Para usar esse procedimento armazenado, você deve ter o registro em log binário configurado para a sessão atual.
Quanto ao Aurora, esse procedimento é compatível com o Aurora MySQL versão 2.12 e em versões posteriores compatíveis com o MySQL 5.7.
## mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL versão 3)
Define o modo de replicação de base nas posições do arquivo de log binário ou nos identificadores de transações globais (GTIDs).
### Sintaxe
```
CALL mysql.rds_set_source_auto_position (auto_position_mode);
```
### Parâmetros
*auto\$1position\$1mode*
Um valor que indica se será usada a replicação de posição do arquivo de log ou a replicação com base no GTID:
+ `0`: usar o método de replicação com base na posição do arquivo de log binário. O padrão é `0`.
+ `1`: usar o método de replicação com base no GTID.
### Observações de uso
Para um cluster de bancos de dados Aurora MySQL, você chama esse procedimento armazenado enquanto está conectado à instância primária.
O usuário administrativo precisa executar o procedimento `mysql.rds_set_source_auto_position`.
## mysql.rds\$1skip\$1repl\$1error
Ignora e exclui um erro de replicação em uma réplica de leitura de banco de dados MySQL.
### Sintaxe
```
CALL mysql.rds_skip_repl_error;
```
### Observações de uso
O usuário principal deve executar o procedimento `mysql.rds_skip_repl_error` em uma réplica de leitura. Para obter mais informações sobre esse procedimento, consulte [Ignorar o erro de replicação atual](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.SkipError).
Para determinar se há erros, execute o comando `SHOW REPLICA STATUS\G` do MySQL. Se um erro de replicação não for crítico, execute `mysql.rds_skip_repl_error` para ignorá-lo. Se houver vários, `mysql.rds_skip_repl_error` exclui o primeiro erro, depois avisa que há outros ainda. Assim, você pode usar `SHOW REPLICA STATUS\G` para determinar o plano de ação correto para o próximo erro. Para obter informações sobre os valores retornados, consulte [Instrução SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) na documentação do MySQL.
Para obter mais informações sobre como lidar com erros de replicação no Aurora MySQL, consulte [Diagnosticar e resolver uma falha de replicação de leitura do MySQL ](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.RR).
#### Erro de replicação interrompida
Ao chamar o procedimento `mysql.rds_skip_repl_error`, você pode receber uma mensagem de erro informando que a réplica está inativa ou desativada.
Essa mensagem de erro aparece quando você executa o procedimento na instância primária em vez da réplica de leitura. Você deve executar esse procedimento na réplica de leitura para que o procedimento funcione.
Essa mensagem de erro também poderá aparecer se você executar o procedimento na réplica de leitura, mas a replicação não poderá ser reiniciada com êxito.
Se você precisar ignorar um grande número de erros, o atraso de replicação poderá aumentar além do período de retenção padrão para arquivos de log binário (binlog). Nesse caso, você poderá encontrar um erro fatal, com os arquivos binlog sendo limpos antes de sua reprodução na réplica de leitura. Essa remoção faz com que a replicação pare, e você não consegue chamar o comando `mysql.rds_skip_repl_error` para ignorar erros de replicação.
É possível mitigar esse problema aumentando o número de horas em que os arquivos binlog são retidos na instância de banco de dados de origem. Após aumentar o período de retenção de log binário, você pode reiniciar a replicação e chamar o comando `mysql.rds_skip_repl_error` conforme necessário.
Para definir o período de retenção do binlog, use o procedimento [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) e especifique um parâmetro de configuração `'binlog retention hours'`, juntamente com o número de horas de retenção dos arquivos binlog no cluster do banco de dados. O exemplo a seguir define o período de retenção para arquivos de log binário em 48 horas.
```
CALL mysql.rds_set_configuration('binlog retention hours', 48);
```
## mysql.rds\$1start\$1replication
Inicia a replicação de um cluster de banco de dados do Aurora MySQL.
**nota**
Você pode usar o procedimento armazenado [mysql.rds\$1start\$1replication\$1until(Aurora MySQL versão 3)](#mysql_rds_start_replication_until) ou [mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL versão 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) para iniciar a replicação de uma instância de banco de dados do Aurora MySQL e interromper a replicação no local do arquivo de log binário especificado.
### Sintaxe
```
CALL mysql.rds_start_replication;
```
### Observações de uso
O usuário principal deve executar o procedimento `mysql.rds_start_replication`.
Para importar dados de uma instância do MySQL fora do Amazon RDS, chame `mysql.rds_start_replication` na réplica de leitura para iniciar o processo de replicação depois de ter chamado [mysql.rds\$1set\$1external\$1master (Aurora MySQL versão 2)](#mysql_rds_set_external_master) ou [mysql.rds\$1set\$1external\$1source (Aurora MySQL versão 3)](#mysql_rds_set_external_source) para criar a configuração de replicação. Para obter mais informações, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md).
Para exportar dados para uma instância do MySQL fora do Amazon RDS, chame `mysql.rds_start_replication` e `mysql.rds_stop_replication` na réplica de leitura para controlar algumas ações de replicação, como a remoção de logs binários. Para obter mais informações, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md).
Também é possível chamar `mysql.rds_start_replication` na réplica de leitura para reiniciar qualquer processo de replicação que tenha sido interrompido anteriormente chamando `mysql.rds_stop_replication`. Para obter mais informações, consulte [Erro de replicação interrompida](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicationStopped).
## mysql.rds\$1start\$1replication\$1until(Aurora MySQL versão 3)
Inicia a replicação de um cluster de banco de dados do Aurora MySQL e interrompe a replicação no local do arquivo de log binário especificado.
### Sintaxe
```
CALL mysql.rds_start_replication_until (
replication_log_file
, replication_stop_point
);
```
### Parâmetros
*replication\$1log\$1file*
O nome do log binário na instância de banco de dados de origem que contém as informações de replicação.
*replication\$1stop\$1point *
O local no log binário `replication_log_file` no qual a replicação será interrompida.
### Observações de uso
O usuário mestre deve executar o procedimento `mysql.rds_start_replication_until`.
Esse procedimento é compatível com o Aurora MySQL versão 3.04 e posterior.
O procedimento armazenado `mysql.rds_start_replication_until` não é compatível com a replicação gerenciada, o que inclui o seguinte:
+ [Replicar clusters de banco de dados do Amazon Aurora MySQL entre Regiões da AWS](AuroraMySQL.Replication.CrossRegion.md)
+ [Migrar de uma instância de banco de dados do RDS para MySQL para um cluster de banco de dados do Amazon Aurora MySQL usando uma réplica de leitura do Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
O nome do arquivo especificado para o parâmetro `replication_log_file` deve corresponder ao nome do arquivo do log binário da instância de banco de dados de origem.
Quando o parâmetro `replication_stop_point` especifica um local de parada no passado, a replicação é interrompida imediatamente.
### Exemplos
O exemplo a seguir inicia a replicação e replica as alterações até que ela atinja o local `120` no arquivo de log binário `mysql-bin-changelog.000777`.
```
call mysql.rds_start_replication_until(
'mysql-bin-changelog.000777',
120);
```
## mysql.rds\$1stop\$1replication
Interrompe a replicação de uma instância de banco de dados MySQL.
### Sintaxe
```
CALL mysql.rds_stop_replication;
```
### Observações de uso
O usuário mestre deve executar o procedimento `mysql.rds_stop_replication`.
Se você estiver configurando a replicação para importar dados de uma instância do MySQL em execução externamente ao Amazon RDS, chame `mysql.rds_stop_replication` na réplica de leitura para encerrar o processo de replicação após a importação ter sido concluída. Para obter mais informações, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md).
Se estiver configurando a replicação para exportar dados para uma instância do MySQL externa ao Amazon RDS, chame `mysql.rds_start_replication` e `mysql.rds_stop_replication` na réplica de leitura para controlar algumas ações de replicação, como a remoção de logs binários. Para obter mais informações, consulte [Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário)](AuroraMySQL.Replication.MySQL.md).
O procedimento armazenado `mysql.rds_stop_replication` não é compatível com a replicação gerenciada, o que inclui o seguinte:
+ [Replicar clusters de banco de dados do Amazon Aurora MySQL entre Regiões da AWS](AuroraMySQL.Replication.CrossRegion.md)
+ [Migrar de uma instância de banco de dados do RDS para MySQL para um cluster de banco de dados do Amazon Aurora MySQL usando uma réplica de leitura do Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
# Encerrar uma sessão ou consulta
Os procedimentos armazenados a seguir encerram uma sessão ou consulta.
**Topics**
+ [
## mysql.rds\$1kill
](#mysql_rds_kill)
+ [
## mysql.rds\$1kill\$1query
](#mysql_rds_kill_query)
## mysql.rds\$1kill
Encerra uma conexão ao servidor MySQL.
### Sintaxe
```
CALL mysql.rds_kill(processID);
```
### Parâmetros
*processID*
A identidade do thread de conexão a ser encerrada.
### Observações de uso
Cada conexão ao servidor do MySQL é executada em um thread separado. Para encerrar uma conexão, use o procedimento `mysql.rds_kill` e passe o ID de thread dessa conexão. Para obter o ID de thread, use o comando [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) do MySQL.
### Exemplos
O exemplo a seguir encerra uma conexão com um ID de thread de 4243:
```
CALL mysql.rds_kill(4243);
```
## mysql.rds\$1kill\$1query
Encerra uma consulta em execução no servidor MySQL.
### Sintaxe
```
CALL mysql.rds_kill_query(processID);
```
### Parâmetros
*processID*
A identidade do processo ou thread que está executando a consulta a ser encerrada.
### Observações de uso
Para encerrar uma consulta em execução no servidor MySQL, use o procedimento `mysql_rds_kill_query` e passe o ID do thread que está executando a consulta. O procedimento então encerra a conexão.
Para obter o ID, consulte a [tabela INFORMATION\$1SCHEMA PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html) do MySQL ou use o comando [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) do MySQL. O valor na coluna ID de `SHOW PROCESSLIST` ou `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` é *processID*.
### Exemplos
O seguinte exemplo encerra uma consulta com um ID de thread de consulta 230040:
```
CALL mysql.rds_kill_query(230040);
```
# Replicar transações com GTIDs
Os procedimentos armazenados a seguir controlam como as transações são replicadas usando identificadores de transações globais (GTIDs) com o Aurora MySQL. Para saber como usar a replicação com base em GTIDs com o Aurora MySQL, consulte [Usar a replicação baseada em GTID](mysql-replication-gtid.md).
**Topics**
+ [
## mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versão 3)
](#mysql_assign_gtids_to_anonymous_transactions)
+ [
## mysql.rds\$1gtid\$1purged (Aurora MySQL versão 3)
](#mysql_rds_gtid_purged)
+ [
## mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL versões 2 e 3)
](#mysql_rds_skip_transaction_with_gtid)
+ [
## mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL versão 3)
](#mysql_rds_start_replication_until_gtid)
## mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versão 3)
Configura a opção `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS` da instrução `CHANGE REPLICATION SOURCE TO`. Faz com que o canal de replicação atribua um GTID a transações replicadas que não têm um. Assim, é possível realizar a replicação de logs binários de uma origem que não utiliza replicação baseada em GTID para uma réplica que a utiliza. Para obter mais informações, consulte a [Instrução CHANGE REPLICATION SOURCE TO](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) e o tópico sobre [Replicação de uma origem sem GTIDs para uma réplica com GTIDs](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-assign-anon.html), no *Guia de referência do MySQL*.
### Sintaxe
```
CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option);
```
### Parâmetros
*gtid\$1option*
Valor da string. Os valores permitidos são `OFF`, `LOCAL` ou um UUID especificado.
### Observações de uso
Esse procedimento tem o mesmo efeito que a emissão da instrução `CHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = gtid_option` na comunidade do MySQL.
O GTID deve se transformar `ON` para que *gtid\$1option* seja definido como `LOCAL` ou um UUID específico.
O padrão é `OFF`, o que significa que o recurso não é utilizado.
`LOCAL` atribui um GTID que inclui o próprio UUID da réplica (a configuração `server_uuid`).
Transmitir um parâmetro que é um UUID atribui um GTID que inclui o UUID especificado, como a configuração `server_uuid` do servidor de origem de replicação.
### Exemplos
Para desabilitar esse recurso:
```
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)
```
Para utilizar o próprio UUID da réplica:
```
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)
```
Para utilizar um UUID especificado:
```
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 versão 3)
Define o valor global da variável de sistema `gtid_purged` como determinado conjunto de identificadores de transação global (GTID). A variável de sistema `gtid_purged` é um conjunto de GTID que consiste nos GTIDs de todas as transações que foram confirmadas no servidor mas não existem em nenhum arquivo de log binário no servidor.
Para permitir a compatibilidade com o MySQL 8.0, há duas maneiras de definir o valor de `gtid_purged`:
+ Substituir o valor de `gtid_purged` por seu conjunto de GTIDs especificado.
+ Anexar seu conjunto de GTIDs especificado ao conjunto de GTIDs que `gtid_purged` já contém.
### Sintaxe
Como substituir o valor de `gtid_purged` por seu conjunto de GTIDs especificado:
```
CALL mysql.rds_gtid_purged (gtid_set);
```
Como anexar o valor de `gtid_purged` ao seu conjunto de GTIDs especificado:
```
CALL mysql.rds_gtid_purged (+gtid_set);
```
### Parâmetros
*gtid\$1set*
O valor de *gtid\$1set* deve ser um superconjunto do valor atual de `gtid_purged` e não pode fazer uma intersecção com `gtid_subtract(gtid_executed,gtid_purged)`. Ou seja, o novo conjunto de GTIDs deve incluir todos os GTIDs que já estavam em `gtid_purged` e não pode incluir nenhum GTID em `gtid_executed` que ainda não tenha sido eliminado. O parâmetro *gtid\$1set* também não pode incluir nenhum GTID que esteja no conjunto `gtid_owned` global, os GTIDs para transações que estão sendo processadas no momento no servidor.
### Observações de uso
O usuário principal deve executar o procedimento `mysql.rds_gtid_purged`.
Esse procedimento é compatível com o Aurora MySQL versão 3.04 e posterior.
### Exemplos
O exemplo a seguir atribui o GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` à variável `gtid_purged` global.
```
CALL mysql.rds_gtid_purged('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1skip\$1transaction\$1with\$1gtid(Aurora MySQL versões 2 e 3)
Ignora a replicação de uma transação com o identificador de transação global (GTID) especificado em uma instância primária do Aurora.
Você pode usar esse procedimento para a recuperação de desastres, quando uma transação baseada em GTID específica for conhecida por causar desastres. Use esse procedimento armazenado para ignorar a transação problemática. Exemplos de transações problemáticas incluem transações que desabilitam a replicação, excluem dados importantes ou fazem com que a instância de banco de dados se torne indisponível.
### Sintaxe
```
CALL mysql.rds_skip_transaction_with_gtid (
gtid_to_skip
);
```
### Parâmetros
*gtid\$1to\$1skip*
O GTID da transação de replicação a ser ignorada.
### Observações de uso
O usuário principal deve executar o procedimento `mysql.rds_skip_transaction_with_gtid`.
Esse procedimento é compatível com o Aurora MySQL versões 2 e 3.
### Exemplos
O exemplo a seguir ignora a replicação da transação com o 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 versão 3)
Inicia a replicação de um cluster de banco de dados do Aurora MySQL e interrompe a replicação logo depois do identificador de transação global (GTID) especificado.
### Sintaxe
```
CALL mysql.rds_start_replication_until_gtid(gtid);
```
### Parâmetros
*gtid*
O GTID após o qual a replicação será interrompida.
### Observações de uso
O usuário principal deve executar o procedimento `mysql.rds_start_replication_until_gtid`.
Esse procedimento é compatível com o Aurora MySQL versão 3.04 e posterior.
O procedimento armazenado `mysql.rds_start_replication_until_gtid` não é compatível com a replicação gerenciada, o que inclui o seguinte:
+ [Replicar clusters de banco de dados do Amazon Aurora MySQL entre Regiões da AWS](AuroraMySQL.Replication.CrossRegion.md)
+ [Migrar de uma instância de banco de dados do RDS para MySQL para um cluster de banco de dados do Amazon Aurora MySQL usando uma réplica de leitura do Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
Quando o parâmetro `gtid` especifica uma transação que já tenha sido executada pela réplica, a replicação é interrompida imediatamente.
### Exemplos
O exemplo a seguir inicia a replicação e replica as alterações até atingir o GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`.
```
call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
# Alternar os logs de consulta
Os procedimentos armazenados a seguir fazem a rotação dos logs do MySQL para tabelas de backup. Para ter mais informações, consulte [Arquivos de log do banco de dados AuroraMySQL](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
Reveza a tabela `mysql.general_log` com uma tabela de backup.
### Sintaxe
```
CALL mysql.rds_rotate_general_log;
```
### Observações de uso
Você pode revezar a tabela `mysql.general_log` com uma tabela de backup, chamando o procedimento `mysql.rds_rotate_general_log`. Quando as tabelas de log são revezadas, a tabela de log atual é copiada para uma tabela de log de backup e as entradas na tabela de log atual são removidas. Se uma tabela de log de backup já existir, então ela será excluída antes que a tabela de log atual seja copiada ao backup. Você pode consultar a tabela de log de backup, se necessário. A tabela de log de backup para a tabela `mysql.general_log` é denominada `mysql.general_log_backup`.
É possível executar esse procedimento somente quando o parâmetro `log_output` está definido como `TABLE`.
## mysql.rds\$1rotate\$1slow\$1log
Reveza a tabela `mysql.slow_log` com uma tabela de backup.
### Sintaxe
```
CALL mysql.rds_rotate_slow_log;
```
### Observações de uso
Você pode revezar a tabela `mysql.slow_log` com uma tabela de backup, chamando o procedimento `mysql.rds_rotate_slow_log`. Quando as tabelas de log são revezadas, a tabela de log atual é copiada para uma tabela de log de backup e as entradas na tabela de log atual são removidas. Se uma tabela de log de backup já existir, então ela será excluída antes que a tabela de log atual seja copiada ao backup.
Você pode consultar a tabela de log de backup, se necessário. A tabela de log de backup para a tabela `mysql.slow_log` é denominada `mysql.slow_log_backup`.
# Definir e mostrar a configuração de logs binários
Os procedimentos armazenados a seguir definem e mostram parâmetros de configuração, como para retenção de arquivos de log binários.
**Topics**
+ [
## mysql.rds\$1set\$1configuration
](#mysql_rds_set_configuration)
+ [
## mysql.rds\$1show\$1configuration
](#mysql_rds_show_configuration)
## mysql.rds\$1set\$1configuration
Especifica o número de horas para retenção de logs binários ou o número de segundos para atrasar a replicação.
### Sintaxe
```
CALL mysql.rds_set_configuration(name,value);
```
### Parâmetros
*name*
(Opcional) O nome do parâmetro de configuração a definir.
*value*
O valor do parâmetro de configuração.
### Observações de uso
O procedimento `mysql.rds_set_configuration` oferece suporte aos seguintes parâmetros de configuração:
+ [horas de retenção do log binário](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours)
Os parâmetros de configuração são armazenados permanentemente e sobrevivem a qualquer reinicialização ou failover da instância de banco de dados.
#### horas de retenção do log binário
O parâmetro `binlog retention hours` é usado para especificar o número de horas para reter arquivos de log binários. O Amazon Aurora normalmente elimina um log binário o mais rápido possível, mas o log binário ainda pode ser necessário para a replicação com um banco de dados MySQL externo ao Aurora.
O valor padrão de `binlog retention hours` é `NULL`. No Aurora MySQL, `NULL` significa que os logs binários são limpos lentamente. Os registros binários do Aurora MySQL podem permanecer no sistema por determinado período, que geralmente não passa de um dia.
Para especificar o número de horas para reter os logs binários em um cluster de banco de dados, use o procedimento armazenado `mysql.rds_set_configuration` e especifique um período com tempo suficiente para que a replicação ocorra, conforme exibido no exemplo a seguir.
`call mysql.rds_set_configuration('binlog retention hours', 24);`
**nota**
Não é possível usar o valor `0` para `binlog retention hours`.
Para clusters de banco de dados do Aurora MySQL versão 2.11.0 e posterior e clusters de banco de dados versão 3, o valor máximo de `binlog retention hours` é 2.160 (90 dias).
Após configurar o período de retenção, monitore o uso de armazenamento da instância de banco de dados para garantir que os logs binários retidos não consumam muito armazenamento.
## mysql.rds\$1show\$1configuration
A quantidade de horas em que os logs binários são mantidos.
### Sintaxe
```
CALL mysql.rds_show_configuration;
```
### Observações de uso
Para verificar o número de horas durante as quais o Amazon RDS vai reter os logs binários, use o procedimento armazenado `mysql.rds_show_configuration`.
### Exemplos
O exemplo a seguir mostra exibe o período de retenção:
```
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.
```