Replicação

É 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. Para aprender a usar a replicação com base em identificadores de transação global (GTIDs) com o Aurora MySQL, consulte Usar a replicação baseada em GTID para o Amazon Aurora MySQL.

Tópicos

mysql.rds_assign_gtids_to_anonymous_transactions (Aurora MySQL versão 3)
mysql.rds_disable_session_binlog (Aurora MySQL versão 2)
mysql.rds_enable_session_binlog (Aurora MySQL versão 2)
mysql.rds_gtid_purged (Aurora MySQL versão 3)
mysql.rds_import_binlog_ssl_material
mysql.rds_next_master_log (Aurora MySQL versão 2)
mysql.rds_next_source_log (Aurora MySQL versão 3)
mysql.rds_remove_binlog_ssl_material
mysql.rds_reset_external_master (Aurora MySQL versão 2)
mysql.rds_reset_external_source (Aurora MySQL versão 3)
mysql.rds_set_binlog_source_ssl (Aurora MySQL versão 3)
mysql.rds_set_external_master (Aurora MySQL versão 2)
mysql.rds_set_external_master_with_auto_position (Aurora MySQL versão 2)
mysql.rds_set_external_source (Aurora MySQL versão 3)
mysql.rds_set_external_source_with_auto_position (Aurora MySQL versão 3)
mysql.rds_set_master_auto_position (Aurora MySQL versão 2)
mysql.rds_set_read_only (Aurora MySQL versão 3)
mysql.rds_set_session_binlog_format (Aurora MySQL versão 2)
mysql.rds_set_source_auto_position (Aurora MySQL versão 3)
mysql.rds_skip_transaction_with_gtid (Aurora MySQL versões 2 e 3)
mysql.rds_skip_repl_error
mysql.rds_start_replication
mysql.rds_start_replication_until (Aurora MySQL versão 3)
mysql.rds_start_replication_until_gtid (Aurora MySQL versão 3)
mysql.rds_stop_replication

mysql.rds_assign_gtids_to_anonymous_transactions (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 e o tópico sobre Replicação de uma origem sem GTIDs para uma réplica com GTIDs, no Guia de referência do MySQL.

Sintaxe


CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option);

Parâmetros

gtid_option: 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_option 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_disable_session_binlog (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_enable_session_binlog (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_gtid_purged (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_set: O valor de gtid_set 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_set 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_import_binlog_ssl_material

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_material

A carga de JSON que contém o conteúdo dos arquivos de formato .pem a seguir de um cliente MySQL:

"ssl_ca":"Certificado de autoridade de certificação"
"ssl_cert":"Certificado de cliente"
"ssl_key":"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 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_next_master_log (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_master_log: 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.

nota
As versões anteriores do MySQL usavam SHOW SLAVE STATUS em vez de SHOW REPLICA STATUS. Se você estiver usando uma versão do MySQL anterior à 8.0.23, use SHOW SLAVE STATUS.

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);

nota

As versões anteriores do MySQL usavam SHOW SLAVE STATUS em vez de SHOW REPLICA STATUS. Se você estiver usando uma versão do MySQL anterior à 8.0.23, use SHOW SLAVE STATUS.

mysql.rds_next_source_log (Aurora MySQL versão 3)

Sintaxe


CALL mysql.rds_next_source_log(
curr_source_log
);

Parâmetros

curr_source_log: 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 mestre deve 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.

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_remove_binlog_ssl_material

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_import_binlog_ssl_material.

Sintaxe


CALL mysql.rds_remove_binlog_ssl_material;

mysql.rds_reset_external_master (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.

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.

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).

mysql.rds_reset_external_source (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

Sintaxe


CALL mysql.rds_reset_external_source;

Observações de uso

O usuário mestre deve 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

mysql.rds_set_binlog_source_ssl (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 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_set_external_master (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_set_external_source em vez disso.

Importante

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_name

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_port

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_user_name

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_user_password

A senha do ID de usuário especificada em replication_user_name.

mysql_binary_log_file_name

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_binary_log_file_location

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_encryption

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.

nota

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

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.
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_user' 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_import_binlog_ssl_material.

nota

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_start_replication na réplica de leitura para iniciar o processo de replicação. É possível chamar mysql.rds_reset_external_master (Aurora MySQL versão 2) 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,
  0);

mysql.rds_set_external_master_with_auto_position (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_name: O nome de host ou o endereço IP da instância do MySQL sendo executada externamente ao Aurora que se torna o mestre de replicação.
host_port: A porta usada para executar a instância do MySQL sendo executada externamente ao Aurora a ser configurada como o mestre 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_user_name: 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_user_password: A senha do ID de usuário especificada em replication_user_name.
ssl_encryption: 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_set_external_source_with_auto_position (Aurora MySQL versão 3).

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 um mestre 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 um mestre de replicação

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'
```
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_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 para o Amazon Aurora MySQL.

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_set_external_source (Aurora MySQL versão 3)

Configura uma instância de banco de dados do Aurora MySQL para ser uma réplica de leitura de uma instância do MySQL que é executada externamente ao Amazon RDS.

Importante

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_name

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_port

replication_user_name

replication_user_password

A senha do ID de usuário especificada em replication_user_name.

mysql_binary_log_file_name

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_binary_log_file_location

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_encryption

nota

Você deve ter importado um certificado SSL personalizado usando 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_set_binlog_source_ssl (Aurora MySQL versão 3) para habilitar o SSL para replicação de log binário.

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 principal deve 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

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.
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_user' 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 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_import_binlog_ssl_material.

nota

Depois de chamar mysql.rds_set_external_source para configurar uma instância de banco de dados do Aurora MySQL como réplica de leitura, você pode chamar mysql.rds_start_replication na réplica de leitura para iniciar o processo de replicação. Você pode chamar 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,
  0);

mysql.rds_set_external_source_with_auto_position (Aurora MySQL versão 3)

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_name: 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_port: 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_user_name: 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_user_password: A senha do ID de usuário especificada em replication_user_name.
ssl_encryption: Essa opção não está implementada atualmente. O padrão é 0.

nota
Use mysql.rds_set_binlog_source_ssl (Aurora MySQL versão 3) 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

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'
```
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.

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_set_master_auto_position (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_position_mode

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_set_read_only (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_set_session_binlog_format (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

format

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 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_set_source_auto_position (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_position_mode

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_skip_transaction_with_gtid (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_to_skip: 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_skip_repl_error

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.

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 na documentação do MySQL.

nota

As versões anteriores do MySQL usavam SHOW SLAVE STATUS em vez de SHOW REPLICA STATUS. Se você estiver usando uma versão do MySQL anterior à 8.0.23, use SHOW SLAVE STATUS.

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.

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_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_start_replication

Inicia a replicação de um cluster de banco de dados do Aurora MySQL.

nota

Você pode usar o procedimento armazenado mysql.rds_start_replication_until (Aurora MySQL versão 3) ou mysql.rds_start_replication_until_gtid (Aurora MySQL versão 3) 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_set_external_master ou mysql.rds_set_external_source para criar a configuração de replicação. Para ter 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).

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 ter 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).

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 ter mais informações, consulte Erro de replicação interrompida.

mysql.rds_start_replication_until (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_log_file: 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_stop_point: 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:

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_start_replication_until_gtid (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:

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');

mysql.rds_stop_replication

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 ter 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).

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 ter 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).

O procedimento armazenado mysql.rds_stop_replication não é compatível com a replicação gerenciada, o que inclui o seguinte:

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Como gerenciar o histórico de status global

Tabelas information_schema