Replicação de único mestre com o Amazon Aurora MySQL - Amazon Aurora

Replicação de único mestre com o Amazon Aurora MySQL

Os recursos de replicação do Aurora MySQL são fundamentais para a alta disponibilidade e a performance do cluster. O Aurora facilita criar ou redimensionar clusters com até 15 réplicas do Aurora.

Todas as réplicas funcionam pelos mesmos dados subjacentes. Se algumas instâncias de banco de dados ficarem offline, outras permanecerão disponíveis para continuar o processamento de consultas ou para assumir a gravação, caso necessário. O Aurora distribui automaticamente as conexões somente leitura entre várias instâncias de banco de dados, ajudando o cluster do Aurora a dar suporte a workloads que exigem muitas consultas.

Em seguida, é possível encontrar informações sobre como a replicação do Aurora MySQL funciona e como ajustar as configurações de replicação tendo em vista disponibilidade e performance melhores.

nota

Depois disso, é possível saber mais sobre os recursos de replicação para clusters do Aurora usando a replicação de único mestre. Este tipo de cluster é o padrão para o Aurora. Para obter informações sobre os clusters de vários mestres do Aurora, consulte Como trabalhar com clusters de vários mestres do Aurora.

Usar réplicas do Aurora

As réplicas do Aurora são endpoints independentes em um cluster de banco de dados do Aurora, cuja melhor utilidade é dimensionar operações de leitura e aumentar a disponibilidade. Até 15 réplicas do Aurora podem ser distribuídas entre as zonas de disponibilidade abrangidas por um cluster de banco de dados em uma região da AWS. Embora o volume do cluster de banco de dados seja composto de várias cópias dos dados para o cluster de banco de dados, os dados no volume do cluster são representados como um único volume lógico para a instância primária e para as réplicas do Aurora no cluster de banco de dados. Para mais informações sobre réplicas do Aurora, consulte Réplicas do Aurora.

As réplicas do Aurora funcionam bem para a escalabilidade de leitura porque são totalmente dedicadas a operações de leitura no seu volume de cluster. As operações de gravação são gerenciadas pela instância principal. Como o volume do cluster é compartilhado entre todas as instâncias no seu cluster de banco de dados do Aurora MySQL, nenhum trabalho adicional é necessário para replicar uma cópia dos dados para cada réplica do Aurora. Por outro lado, as réplicas de leitura do MySQL devem reproduzir, em um único thread, todas as operações de gravação da instância de banco de dados de origem no armazenamento de dados local. Essa limitação pode afetar a possibilidade de réplicas de leitura do MySQL de dar suporte a grandes volumes de tráfego de leitura.

Com o Aurora MySQL, quando a réplica do Aurora é excluída, o endpoint da instância é removido imediatamente, e a réplica do Aurora é removida do endpoint leitor. Se houver instruções em execução na réplica do Aurora que está sendo excluída, haverá um período de carência de três minutos. As instruções existentes podem ser concluídas durante o período de carência. Quando o período de carência termina, a réplica do Aurora é fechada e excluída.

Importante

As réplicas do Aurora para o Aurora MySQL usam sempre o nível de isolamento de transação padrão REPEATABLE READ para operações nas tabelas do InnoDB. Você pode usar o comando SET TRANSACTION ISOLATION LEVEL para alterar o nível de transação somente para a instância primária de um cluster de banco de dados do Aurora MySQL. Essa restrição evita bloqueios no nível do usuário nas réplicas do Aurora e permite que elas escalem para oferecer suporte a milhares de conexões de usuários ativos ainda que com um mínimo de atraso na réplica.

nota

As instruções DDL executadas na instância principal podem interromper conexões de banco de dados nas réplicas do Aurora associadas. Se uma conexão de réplica do Aurora estiver usando um objeto de banco de dados ativamente (por exemplo, uma tabela) e esse objeto for modificado na instância principal usando uma instrução DDL, a conexão de réplica do Aurora será interrompida.

nota

A região China (Ningxia) não oferece suporte a réplicas de leitura entre regiões.

Opções de replicação para Amazon Aurora MySQL

Você pode configurar a replicação entre qualquer uma das seguintes opções:

nota

Reinicializar a instância primária de um cluster de banco de dados do Amazon Aurora também reinicia automaticamente as réplicas do Aurora desse cluster de banco de dados para restabelecer um ponto de entrada que garante a consistência de leitura/gravação em todo o cluster de banco de dados.

Considerações sobre performance da replicação do Amazon Aurora MySQL

Os recursos a seguir ajudam você a ajustar a performance da replicação do Aurora MySQL.

Desde o Aurora MySQL 1.17.4, o recurso de compactação do log de réplicas reduz a largura de banda da rede para mensagens de replicação. Como cada mensagem é transmitida para todas as réplicas do Aurora, os benefícios são maiores para cluster maiores. Esse recurso envolve certa sobrecarga da CPU no nó gravador para realizar a compactação. Por isso, esse recurso só está disponível nas classes de instância 8xlarge e 16xlarge, que têm alta capacidade de CPU. Ele permanece habilitado por padrão nessas classes de instância. Você pode controlar esse recurso desativando o parâmetro aurora_enable_replica_log_compression. Por exemplo, convém desativar a compactação do log de réplica para classes de instância maiores, caso o nó gravador esteja próximo da capacidade de CPU máxima.

Desde o Aurora MySQL 1.17.4, o recurso de filtragem de logs binários reduz a largura de banda da rede para mensagens de replicação. Como as réplicas do Aurora não usam as informações de log binário incluídas nas mensagens de replicação, esses dados são omitidos das mensagens enviadas para esses nós. Você controla esse recurso alterando o parâmetro aurora_enable_repl_bin_log_filtering. Por padrão, esse parâmetro está ativado. Como essa otimização destina-se a ser transparente, você pode desativar essa configuração somente durante operações de diagnóstico ou solução de problemas relacionadas a replicação. Por exemplo, você pode fazer isso para corresponder o comportamento de um cluster do Aurora MySQL mais antigo no qual esse recurso não estava disponível.

Zero-downtime restart (ZDR – Reinício com tempo de inatividade zero) para Amazon Aurora MySQL

O recurso Zero-downtime restart (ZDR – Reinício com tempo de inatividade zero) pode preservar algumas ou todas as conexões ativas com instâncias de banco de dados durante determinados tipos de reinicializações. O ZDR se aplica a reinicializações que o Aurora executa automaticamente para resolver condições de erro, por exemplo, quando uma réplica começa a ficar muito atrasada em relação à origem.

Importante

O mecanismo ZDR opera com base no melhor esforço. As versões, as classes de instância, as condições de erro, operações SQL compatíveis e outros fatores do Aurora MySQL que determinam onde o ZDR se aplica estão sujeitos a alterações a qualquer momento.

Nas versões 1.* do Aurora MySQL em que o ZDR está disponível, habilite esse recurso ativando o parâmetro aurora_enable_zdr no grupo de parâmetros do cluster. O ZDR para Aurora MySQL 2.* requer a versão 2.10 e posterior. O ZDR está disponível em todas as versões secundárias do Aurora MySQL 3.*. No Aurora MySQL versões 2 e 3, o mecanismo ZDR está habilitado por padrão, e o Aurora não usa o parâmetro aurora_enable_zdr.

Na página Events (Eventos), o Aurora informa atividades relacionadas ao reinício do tempo de inatividade zero. O Aurora registra um evento quando tenta reiniciar usando o mecanismo ZDR. Esse evento indica por que o Aurora executa a reinicialização. Em seguida, o Aurora registra outro evento quando a reinicialização for concluída. Esse evento final relata quanto tempo o processo demorou e quantas conexões foram preservadas ou descartadas durante a reinicialização. Você pode consultar o log de erros do banco de dados para ver mais detalhes sobre o que aconteceu durante a reinicialização.

Embora as conexões permaneçam intactas após uma operação ZDR bem-sucedida, algumas variáveis e recursos são reinicializados. Os seguintes tipos de informações não são preservados por meio de uma reinicialização causada pela reinicialização do tempo de inatividade zero:

  • Variáveis globais. O Aurora restaura variáveis de sessão, mas não restaura variáveis globais após a reinicialização.

  • Variáveis de status. Em particular, o valor do tempo de atividade informado pelo status do mecanismo é redefinido.

  • LAST_INSERT_ID.

  • Estado de auto_increment na memória para tabelas. O estado de incremento automático na memória é reinicializado. Para obter mais informações sobre valores de incremento automático, consulte o MySQL Reference Manual (Manual de referência do MySQL).

  • Informações diagnósticas das tabelas INFORMATION_SCHEMA e PERFORMANCE_SCHEMA. Essas informações de diagnóstico também aparecem na saída de comandos como SHOW PROFILE e SHOW PROFILES.

A tabela a seguir mostra as versões, funções de instância, classes de instância e outras circunstâncias que determinam se o Aurora pode usar o mecanismo ZDR ao reiniciar instâncias de banco de dados em seu cluster.

Aurora MySQL versão O ZDR se aplica ao gravador? O ZDR se aplica aos leitores? Observações

Aurora MySQL versão 1.*, 1.17.3 e inferiores

Não

Não

O ZDR não está disponível para essas versões.

Aurora MySQL versão 1.*, 1.17.4 e posteriores

Não

Sim

Nessas versões do Aurora MySQL, as seguintes condições se aplicam ao mecanismo ZDR:

  • O Aurora não utilizará o mecanismo ZDR se o log binário estiver habilitado na instância de banco de dados.

  • O Aurora reverte todas as transações que estão em andamento em conexões ativas. Sua aplicação deve tentar executar as transações novamente.

  • O Aurora cancela todas as conexões que usam TLS/SSL, tabelas temporárias, bloqueios de tabela ou bloqueios de usuário.

Aurora MySQL versão 2.*, anterior à 2.10.0

Não

Não

O ZDR não está disponível para essas versões. O parâmetro aurora_enable_zdr não está disponível no grupo de parâmetros de cluster padrão para o Aurora MySQL versão 2.

Aurora MySQL versão 2.*, 2.10.0 e posterior

Sim

Sim

O mecanismo ZDR está sempre habilitado.

Nessas versões do Aurora MySQL, as seguintes condições se aplicam ao mecanismo ZDR:

  • O Aurora reverte todas as transações que estão em andamento em conexões ativas. Sua aplicação deve tentar executar as transações novamente.

  • O Aurora cancela todas as conexões que usam TLS/SSL, tabelas temporárias, bloqueios de tabela ou bloqueios de usuário.

Aurora MySQL versão 3.*

Sim

Sim

O mecanismo ZDR está sempre habilitado.

As mesmas condições do Aurora MySQL versão 2.10 são válidas. O ZDR é aplicável a todas as classes de instâncias.

Monitorar a replicação do Amazon Aurora MySQL

A escalabilidade de leitura e a alta disponibilidade dependem de um tempo de atraso mínimo. É possível monitorar até que ponto uma réplica do Aurora está atrasada em relação à instância primária do cluster de banco de dados do Aurora MySQL, monitorando a métrica AuroraReplicaLag do Amazon CloudWatch. A métrica AuroraReplicaLag é registrada em cada réplica do Aurora.

A instância de banco de dados principal também registra as métricas AuroraReplicaLagMaximum e AuroraReplicaLag do Amazon CloudWatch. A métrica AuroraReplicaLagMaximum registra a quantidade máxima de atraso entre a instância de banco de dados principal e cada réplica do Aurora no cluster de banco de dados. A métrica AuroraReplicaLag registra a quantidade mínima de atraso entre a instância de banco de dados principal e cada réplica do Aurora no cluster de banco de dados.

Se você precisar do valor mais atual para o atraso da réplica do Aurora, consulte a tabela recrystallisations na instância principal do cluster de banco de dados do Aurora MySQL e verifique o valor na coluna Replica_lag_in_msec. O valor dessa coluna é fornecido ao Amazon CloudWatch como o valor da métrica AuroraReplicaLag. O atraso da réplica do Aurora também é registrado em cada réplica do Aurora na tabela INFORMATION_SCHEMA.REPLICA_HOST_STATUS no cluster de banco de dados do Aurora MySQL.

Para obter mais informações sobre como monitorar as instâncias do RDS e as métricas do CloudWatch, consulte Monitorar métricas em um cluster do Amazon Aurora.

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)

Como o Amazon Aurora MySQL é compatível com o MySQL, você pode configurar a replicação entre um banco de dados MySQL e um cluster de banco de dados do Amazon Aurora MySQL. Esse tipo de replicação usa a replicação de log binário do MySQL e também referido como replicação de log binário. Se você usar a replicação de log binário com o Aurora, recomendamos que o banco de dados MySQL execute o MySQL versão 5.5 ou superior. É possível configurar a replicação em que o cluster de banco de dados do Aurora MySQL é a origem da replicação ou a réplica. É possível replicar com uma instância de banco de dados MySQL do Amazon RDS, um banco de dados MySQL externo ao Amazon RDS ou outro cluster de banco de dados do Aurora MySQL.

nota

Você não pode usar a replicação de log binário de/para determinados tipos de clusters do Aurora. Em particular, a replicação de log binário não está disponível para clusters Aurora Serverless v1 nem com vários mestres. Se as instruções SHOW MASTER STATUS e SHOW SLAVE STATUS(Aurora MySQL versões 1 e 2) ou SHOW REPLICA STATUS (Aurora MySQL versão 3) não retornarem uma saída, verifique se o cluster em uso oferece suporte para replicação de binlog.

Também é possível replicar com uma instância de banco de dados RDS for MySQL ou cluster de banco de dados do Aurora MySQL em outra região da AWS. Quando você estiver executando a replicação em regiões da AWS, verifique se os clusters e instâncias de banco de dados estão acessíveis publicamente. Os clusters de banco de dados do Aurora MySQL devem fazer parte de uma sub-rede pública em sua VPC.

Se quiser configurar a replicação entre um cluster de banco de dados do Aurora MySQL e um cluster de banco de dados do Aurora MySQL em outra região, poderá criar um cluster de banco de dados do Aurora MySQL como uma réplica de leitura em uma região da AWS diferente do cluster de banco de dados de origem. Para obter mais informações, consulte Replicar clusters de banco de dados do Amazon Aurora MySQL entre regiões da AWS.

Com o Aurora MySQL 2.04 e versões posteriores, é possível replicar entre o Aurora MySQL e uma origem ou um destino externo que utilize identificadores de transação global (GTIDs) para replicação. Certifique-se de que os parâmetros relacionados ao GTID no cluster de banco de dados do Aurora MySQL tenham configurações compatíveis com o status de GTID do banco de dados externo. Para aprender a fazer isso, consulte Usar a replicação baseada em GTID para o Amazon Aurora MySQL. No Aurora MySQL versão 3.01 e posteriores, é possível escolher como atribuir GTIDs a transações replicadas de uma origem que não utiliza GTIDs. Para saber mais sobre o procedimento armazenado que controla essa configuração, consulte mysql.rds_assign_gtids_to_anonymous_transactions (Aurora MySQL versão 3 e versões superiores).

Atenção

Ao replicar entre o Aurora MySQL e o MySQL, certifique-se de usar apenas tabelas do InnoDB. Se você tiver tabelas do MyISAM que deseja replicar, poderá convertê-las no formato do InnoDB antes de configurar a replicação, com o seguinte comando.

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

Configurar a replicação do MySQL com o Aurora MySQL envolve as seguintes etapas, que são abordadas em detalhes mais adiante neste tópico:

1. Habilitar o registro em log binário na origem de replicação

2. Retenha os logs binários na origem da replicação até que não seja necessário

3. Crie um snapshot da origem da replicação

4. Carregue o snapshot em seu destino de réplica

5. Habilitar a replicação no seu destino de réplica

6. Monitore sua réplica

Configurar a replicação com MySQL ou outro cluster de banco de dados do Aurora

Para configurar a replicação do Aurora com o MySQL, execute as seguintes etapas.

1. Habilitar o registro em log binário na origem de replicação

Encontre instruções a seguir sobre como habilitar o registro em log binário na origem de replicação para seu o mecanismo de banco de dados.

Mecanismo do banco de dados Instruções

Aurora

Para habilitar o registro em log binário em um cluster de banco de dados do Aurora MySQL

Definir o parâmetro binlog_format como ROW, STATEMENT ou MIXED. MIXED é recomendável, a menos que você precise de um formato de binário específico. O parâmetro binlog_format é um parâmetro em nível de cluster que se encontra no parameter group de cluster padrão. Se você estiver alterando o parâmetro binlog_format de OFF para outro valor, será necessário reinicializar o cluster de banco de dados Aurora para que a alteração entre em vigor.

Para obter mais informações, consulte Parâmetros do cluster de banco de dados e da instância de bancos de dados Amazon Aurora e Trabalhar com grupos de parâmetros.

RDS for MySQL

Para habilitar o registro em log binário em uma instância de banco de dados do Amazon RDS

Não é possível habilitar o registro em log binário diretamente para uma instância de banco de dados do Amazon RDS, mas é possível habilitá-lo seguindo um destes procedimentos:

  • Habilite backups automáticos da instância de banco de dados. Você pode habilitar backups automáticos ao criar uma instância de banco de dados ou pode habilitar backups modificando uma instância de banco de dados existente. Para obter mais informações, consulte Criar uma instância de banco de dados no Guia do usuário do Amazon RDS.

  • Crie uma réplica de leitura para a instância de banco de dados. Para obter mais informações, consulte Como trabalhar com réplicas de leitura no Guia do usuário do Amazon RDS.

MySQL (externo)

Para configurar replicação criptografada

Para replicar dados de forma segura com Aurora MySQL versão 5.6, você pode usar a replicação criptografada.

No momento, a replicação criptografada com um banco de dados MySQL externo só é compatível com o Aurora MySQL versão 5.6.

nota

Se você não precisar usar a replicação criptografada, você pode pular essas etapas.

Veja a seguir os pré-requisitos para usar a replicação criptografada:

  • O Secure Sockets Layer (SSL) deve ser habilitado no banco de dados de origem externa do MySQL.

  • Uma chave e certificado de cliente devem estar preparados para o cluster do banco de dados do 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.

  1. Certifique-se de que você estará preparado para a replicação criptografada:

    • Se você não tem o SSL habilitado no banco de dados de origem externo 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 origem externa, forneça uma chave e um certificado de cliente para o cluster de banco de dados do Aurora MySQL. Se você não os tiver, gere uma nova chave e certificado para o cluster de banco de dados do Aurora MySQL. Para assinar o certificado de cliente, é necessário ter a chave de autoridade de certificado usada para configurar o SSL no 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.

    Você precisa do certificado de autoridade de certificação, a chave do cliente e o certificado do cliente.

  2. Conecte-se ao cluster de banco de dados do Aurora MySQL como o usuário mestre usando SSL.

    Para obter informações sobre como se conectar ao cluster de banco de dados do Aurora MySQL com SSL, consulte Usar SSL/TLS com clusters de banco de dados do Aurora MySQL.

  3. Execute o procedimento armazenado mysql.rds_import_binlog_ssl_material para importar as informações de SSL para o cluster de banco de dados do Aurora MySQL.

    Para o parâmetro ssl_material_value, insira as informações dos arquivos em formato .pem no cluster de banco de dados do Aurora MySQL, na carga JSON correta.

    O exemplo a seguir importa informações SSL em um cluster de banco de dados 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"}');

    Para obter mais informações, consulte mysql_rds_import_binlog_ssl_material e Usar SSL/TLS com clusters de banco de dados do Aurora MySQL.

    nota

    Após executar o procedimento, os segredos são armazenados em arquivos. Para apagar os arquivos mais tarde, você pode executar o procedimento armazenado mysql_rds_remove_binlog_ssl_material.

Para habilitar o registro em log binário em um banco de dados MySQL externo

  1. Em um shell de comando, interrompa o serviço mysql.

    sudo service mysqld stop
  2. Edite o arquivo my.cnf (esse arquivo normalmente se encontra em /etc).

    sudo vi /etc/my.cnf

    Adicione as opções log_bin e server_id à seção [mysqld]. A opção log_bin fornece um identificador de nome de arquivo para arquivos de log binário. A opção server_id fornece um identificador exclusivo para o servidor em relações entre origem e réplica.

    Se a replicação criptografada não for necessária, verifique se o banco de dados MySQL externo é iniciado com binlogs habilitados e o SSL desabilitado.

    A seguir veja as entradas relevantes no arquivo /etc/my.cnf para obter dados não criptografados.

    log-bin=mysql-bin server-id=2133421 innodb_flush_log_at_trx_commit=1 sync_binlog=1

    Se a replicação criptografada for necessária, assegure-se de que o banco de dados MySQL externo é iniciado SSL e logs binários estão habilitados.

    As entradas no arquivo /etc/my.cnf incluem os locais de arquivos .pem para servidor de banco de dados MySQL.

    log-bin=mysql-bin server-id=2133421 innodb_flush_log_at_trx_commit=1 sync_binlog=1 # Setup SSL. ssl-ca=/home/sslcerts/ca.pem ssl-cert=/home/sslcerts/server-cert.pem ssl-key=/home/sslcerts/server-key.pem

    Além disso, a opção sql_mode de sua Instância de banco de dados MySQL deve ser definida como 0, ou não deve ser incluída no arquivo my.cnf.

    Quando conectado ao banco de dados MySQL externo, grave a posição do log binário do banco de dados externo do MySQL.

    mysql> SHOW MASTER STATUS;

    Sua saída deve ser similar à seguinte:

    +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000031 | 107 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)

    Para obter mais informações, consulte Setting the replication source configuration na documentação do MySQL.

  3. Inicie o serviço mysql.

    sudo service mysqld start

2. Retenha os logs binários na origem da replicação até que não seja necessário

Quando você usa a replicação de log binário do MySQL, o Amazon RDS não gerencia o processo de replicação. Como resultado, é necessário garantir que os arquivos de log binário na origem da replicação sejam retidos até que as alterações tenham sido aplicadas à réplica. Esta manutenção ajuda a garantir que você possa restaurar o banco de dados de origem em caso de falha.

Encontre instruções sobre como manter os logs binários para o mecanismo do seu banco de dados a seguir.

Mecanismo do banco de dados Instruções

Aurora

Para manter os logs binários em um cluster de banco de dados do Aurora MySQL

Você não tem acesso aos arquivos de log binário de um cluster de banco de dados do Aurora MySQL. Como resultado, é necessário escolher um período para reter os arquivos de log binário na origem da replicação o suficiente para garantir que as alterações tenham sido aplicadas à réplica antes que o arquivo de log binário seja excluído pelo Amazon RDS. Você pode manter arquivos de log binário em um cluster de banco de dados do Aurora MySQL por até 90 dias.

Se você for configurar a replicação com um banco de dados MySQL ou instância de banco de dados RDS for MySQL como a réplica e o banco de dados para o qual você estiver criando uma réplica for muito grande, escolha um período longo para manter arquivos de log binário até que a cópia inicial do banco de dados para a réplica seja concluída e o lag de réplica chegue a 0.

Para definir o período de retenção do log binário, use o procedimento mysql_rds_set_configuration especifique um parâmetro de configuração de 'binlog retention hours', junto com o número de horas para reter arquivos de log binário no cluster de banco de dados em até 2160 (90 dias). O exemplo a seguir define o período de retenção para arquivos de log binário em 6 dias:

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

Após a replicação ter sido iniciada, você poderá verificar se as mudanças foram aplicadas à sua réplica executando o comando SHOW SLAVE STATUS (Aurora MySQL versões 1 e 2) ou SHOW REPLICA STATUS (Aurora MySQL versão 3) na sua réplica e verificando o campo Seconds behind master. Se o campo Seconds behind master for 0, não haverá atraso de réplica. Quando não há atraso de réplica, reduza o período em que os arquivos de log binário são mantidos definindo o parâmetro de configuração binlog retention hours para um período menor.

Se essa configuração não for especificada, o padrão de Aurora MySQL será 24 (1 dia).

Se você especificar um valor para 'binlog retention hours' que seja maior que 2160, Aurora MySQL usará um valor de 2160.

RDS for MySQL

Para manter os logs binários em uma instância de banco de dados do Amazon RDS

Você pode manter arquivos de log binário em uma instância de banco de dados do Amazon RDS definindo os horários de retenção do log binário, assim como fez com o cluster de banco de dados do Aurora MySQL descrito na seção anterior.

Você também pode manter arquivos de log binário em uma instância de banco de dados do Amazon RDS criando uma réplica de leitura para a instância de banco de dados. Esta réplica de leitura é temporária e tem como finalidade exclusiva manter os arquivos de log binário. Depois de criar a réplica de leitura, chame o procedimento mysql_rds_stop_replication nela. Enquanto a replicação estiver interrompida, o Amazon RDS não excluirá nenhum dos arquivos de log binário na origem da replicação. Após configurar a replicação com a réplica permanente, você poderá excluir a réplica de leitura quando o atraso da réplica (campo Seconds behind master) entre a origem da replicação e a réplica permanente chegar a 0.

MySQL (externo)

Para manter os logs binários em um banco de dados MySQL externo

Como os arquivos de log binário em um banco de dados MySQL externo não são gerenciados pelo Amazon RDS, eles serão mantidos até você os exclua.

Após a replicação ter sido iniciada, você poderá verificar se as mudanças foram aplicadas à sua réplica executando o comando SHOW SLAVE STATUS (Aurora MySQL versões 1 e 2) ou SHOW REPLICA STATUS (Aurora MySQL versão 3) na sua réplica e verificando o campo Seconds behind master. Se o campo Seconds behind master for 0, não haverá atraso de réplica. Quando não há atraso de réplica, você pode excluir arquivos de log binário antigos.

3. Crie um snapshot da origem da replicação

Use um snapshot da origem da replicação para carregar uma cópia da linha de base dos dados na réplica e comece a replicar a partir desse ponto.

Encontre instruções sobre como criar um snapshot da origem da replicação para o mecanismo de banco de dados a seguir.

Mecanismo do banco de dados Instruções

Aurora

Para criar um snapshot de um cluster de banco de dados do Aurora MySQL

  1. Crie um snapshot de cluster de banco de dados do seu cluster de banco de dados Amazon Aurora. Para obter mais informações, consulte Criar um snapshot de cluster de banco de dados.

  2. Crie um novo cluster de banco de dados Aurora restaurando a partir do snapshot de cluster de banco de dados que você acabou de criar. Certifique-se de manter o mesmo parameter group de banco de dados para o cluster de banco de dados restaurado como seu cluster de banco de dados original. Isso garantirá que a cópia do seu cluster de banco de dados tenha o log binário habilitado. Para obter mais informações, consulte Restauração a partir de um snapshot de um cluster de banco de dados.

  3. No console, escolha Databases (Bancos de dados) e clique na instância primária (gravador) do seu cluster de banco de dados do Aurora para mostrar seus detalhes. Role até Recent Events. Uma mensagem de evento mostra que inclui o nome e a posição do arquivo de log binário. A mensagem de evento está no seguinte formato.

    Binlog position from crash recovery is binlog-file-name binlog-position

    Salve o nome do arquivo de log binário e os valores de posição para quando você iniciar a replicação.

    Você também pode obter o nome e a posição do arquivo de log binário chamando o comando describe-events da AWS CLI. O exemplo a seguir mostra um comando de describe-events com saída de exemplo.

    PROMPT> aws rds describe-events
    { "Events": [ { "EventCategories": [], "SourceType": "db-instance", "SourceArn": "arn:aws:rds:us-west-2:123456789012:db:sample-restored-instance", "Date": "2016-10-28T19:43:46.862Z", "Message": "Binlog position from crash recovery is mysql-bin-changelog.000003 4278", "SourceIdentifier": "sample-restored-instance" } ] }

    Você também pode obter o nome e a posição do arquivo de log binário verificando o log de erros do MySQL à procura da posição do arquivo de log binário do MySQL.

  4. Se sua réplica de destino for um cluster de banco de dados do Aurora de propriedade de outra conta da AWS, um banco de dados MySQL externo ou uma instância de banco de dados RDS for MySQL, não será possível carregar os dados de um snapshot de cluster de banco de dados do Amazon Aurora. Em vez disso, crie um despejo de seu cluster de banco de dados do Amazon Aurora conectando-se ao seu cluster de banco de dados usando um cliente MySQL e emitindo o comando mysqldump. Certifique-se de executar o comando mysqldump na cópia do cluster de banco de dados do Amazon Aurora que você criou. Veja um exemplo a seguir.

    PROMPT> mysqldump --databases <database_name> --single-transaction --order-by-primary -r backup.sql -u <local_user> -p
  5. Após terminar de criar o despejo de seus dados no cluster de banco de dados Aurora recém-criado, exclua esse cluster de banco de dados, já que não é mais necessário.

RDS for MySQL

Para criar um snapshot da instância de banco de dados do Amazon RDS

  1. Crie uma réplica de leitura de sua instância de banco de dados do Amazon RDS. Para obter mais informações, consulte Criar uma réplica de leitura no Guia do usuário do Amazon Relational Database Service.

  2. Conecte-se à sua réplica de leitura e interrompa a replicação executando o procedimento mysql_rds_stop_replication.

  3. Enquanto a réplica de leitura estiver no estado Stopped (Interrompida), conecte-se a ela e execute o comando SHOW SLAVE STATUS (Aurora MySQL versões 1 e 2) ou SHOW REPLICA STATUS (Aurora MySQL versão 3). Recupere o nome de arquivo de log binário atual no campo Relay_Master_Log_File e a posição do arquivo de log no campo Exec_Master_Log_Pos. Salve esses valores para quando você iniciar a replicação.

  4. Enquanto a réplica de leitura permanece Stopped (Interrompido), crie um snapshot de banco de dados da réplica de leitura. Para obter mais informações, consulte Criar um snapshot de banco de dados no Guia do usuário do Amazon Relational Database Service.

  5. Exclua a réplica de leitura.

MySQL (externo)

Para criar um snapshot de um banco de dados MySQL externo

  1. Antes de criar um snapshot, é necessário garantir que o local de log binário do snapshot seja atual com os dados na instância de origem. Para isso, primeiro você deve interromper todas as operações de gravação da instância com o seguinte comando:

    mysql> FLUSH TABLES WITH READ LOCK;
  2. Crie um despejo de seu banco de dados MySQL usando o comando mysqldump, conforme mostrado a seguir:

    PROMPT> sudo mysqldump --databases <database_name> --master-data=2 --single-transaction \ --order-by-primary -r backup.sql -u <local_user> -p
  3. Após criar o snapshot, desbloqueie as tabelas em seu banco de dados MySQL com o seguinte comando:

    mysql> UNLOCK TABLES;

4. Carregue o snapshot em seu destino de réplica

Se você planeja carregar dados de um despejo de um banco de dados MySQL que seja externo ao Amazon RDS, você poderia criar uma instância do EC2 para copiar os arquivos de despejo e, em seguida, carregar os dados em seu cluster de banco de dados ou instância de banco de dados a partir dessa instância do EC2. Com essa abordagem, você pode compactar o(s) arquivo(s) de despejo antes de copiá-los na instância do EC2 para reduzir os custos de rede associados à cópia de dados para o Amazon RDS. Você também pode criptografar o arquivo ou arquivos de despejo para proteger os dados à medida que são transferidos pela rede.

Encontre instruções sobre como carregar o snapshot da origem da replicação no destino de réplica para o mecanismo de banco de dados a seguir.

Mecanismo do banco de dados Instruções

Aurora

Para carregar um snapshot em um cluster de banco de dados do Aurora MySQL

  • Se o snapshot da origem da replicação for um snapshot de cluster de banco de dados, você poderá fazer a restauração pelo snapshot do cluster de banco de dados para criar um cluster de banco de dados do Aurora MySQL como o destino de réplica. Para obter mais informações, consulte Restauração a partir de um snapshot de um cluster de banco de dados.

  • Se o snapshot da origem replicação for um snapshot de banco de dados, você poderá migrar os dados do snapshot de banco de dados para um cluster de banco de dados do Aurora MySQL. Para obter mais informações, consulte Migrar dados para um cluster de banco de dados do Amazon Aurora.

  • Se o snapshot da origem da replicação for o resultado do comando mysqldump, siga estas etapas:

    1. Copie a saída do comando mysqldump da origem da replicação para um local que também possa ser conectado ao cluster de banco de dados do Aurora MySQL.

    2. Conecte-se ao seu cluster de banco de dados do Aurora MySQL usando o comando mysql. Veja um exemplo a seguir.

      PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p
    3. No prompt mysql, execute o comando source e passe a ele o nome do arquivo de despejo do banco de dados para carregar os dados no cluster de banco de dados Aurora MySQL, por exemplo:

      mysql> source backup.sql;

RDS for MySQL

Para carregar um snapshot em uma instância de banco de dados do Amazon RDS

  1. Copie a saída do comando mysqldump da origem da replicação para um local que também possa ser conectado à instância de banco de dados MySQL.

  2. Conecte-se a sua instância de banco de dados MySQL usando o comando mysql. Veja um exemplo a seguir.

    PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p
  3. No prompt mysql, execute o comando source e passe a ele o nome do arquivo de despejo do banco de dados para carregar os dados na instância de banco de dados MySQL, por exemplo:

    mysql> source backup.sql;

MySQL (externo)

Para carregar um snapshot em um banco de dados MySQL externo

Você não pode carregar um snapshot de banco de dados ou um snapshot de cluster de banco de dados em um banco de dados MySQL externo. Em vez disso, você deve usar o resultado do comando mysqldump.

  1. Copie a saída do comando mysqldump da origem da replicação para um local que também possa ser conectado ao banco de dados MySQL.

  2. Conecte-se ao seu banco de dados MySQL usando o comando mysql. Veja um exemplo a seguir.

    PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p
  3. No prompt mysql, execute o comando source e passe a ele o nome do arquivo de despejo do banco de dados para carregar os dados em seu banco de dados MySQL. Veja um exemplo a seguir.

    mysql> source backup.sql;

5. Habilitar a replicação no seu destino de réplica

Antes de habilitar a replicação, convém obter um snapshot manual do destino de réplica do cluster de banco de dados do Aurora MySQL ou da instância de banco de dados do RDS for MySQL. Se surgir um problema e for preciso restabelecer a replicação com o cluster de banco de dados ou o destino de réplica da instância de banco de dados, você poderá restaurar o cluster de banco de dados ou a instância de banco de dados desse snapshot em vez de precisar importar os dados em seu destino de réplica novamente.

Além disso, crie um ID de usuário usado exclusivamente para replicação. Veja um exemplo a seguir.

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

O usuário requer os privilégios REPLICATION CLIENT e REPLICATION SLAVE. Concede esses privilégios ao usuário.

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

Se você precisar usar replicação criptografada, exija conexões SSL para o usuário de replicação. Você pode usar um dos seguintes comandos, por exemplo, para solicitar conexões SSL na conta de usuário repl_user.

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

Se REQUIRE SSL não está incluído, a conexão de replicação pode silenciosamente cair de volta para uma conexão não criptografada.

Encontre instruções sobre como habilitar a replicação para o seu mecanismo de banco de dados a seguir.

Mecanismo do banco de dados Instruções

Aurora

Para habilitar a replicação de um cluster de banco de dados do Aurora MySQL

  1. Se seu destino de réplica do cluster de banco de dados foi criado a partir de um snapshot de banco de dados de cluster, conecte-se ao destino de réplica do cluster de banco de dados e emita o comando SHOW MASTER STATUS. Recupere o nome de arquivo de log binário atual no campo File e a posição do arquivo de log no campo Position.

    Se o seu destino de réplica do cluster de banco de dados foi criado a partir de um snapshot de banco de dados, você precisará do arquivo de log binário e da posição do log binário que representam o ponto inicial para a replicação. Você recuperou esses valores do comando SHOW SLAVE STATUS (Aurora MySQL versões 1 e 2) ou SHOW REPLICA STATUS (Aurora MySQL versão 3) ao criar o snapshot da sua origem de replicação.

  2. Conecte-se ao cluster de banco de dados e emita os procedimentos mysql_rds_set_external_master (Aurora MySQL versões 1 e 2), mysql_rds_set_external_source (Aurora MySQL versão 3 e posteriores) e mysql_rds_start_replication para iniciar a replicação com a sua origem de replicação utilizando o nome e a localização do arquivo de log binário da etapa anterior. Veja um exemplo a seguir.

    For Aurora MySQL version 1 and 2: CALL mysql.rds_set_external_master ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0); For Aurora MySQL version 3 and higher: CALL mysql.rds_set_external_source ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0); For all versions: CALL mysql.rds_start_replication;

RDS for MySQL

Para habilitar a replicação de uma instância de banco de dados do Amazon RDS

  1. Se o seu destino de réplica da instância de banco de dados foi criado a partir de um snapshot de banco de dados, você precisará do arquivo de log binário e da posição do log binário que representam o ponto inicial para a replicação. Você recuperou esses valores do comando SHOW SLAVE STATUS (Aurora MySQL versões 1 e 2) ou SHOW REPLICA STATUS (Aurora MySQL versão 3) ao criar o snapshot da sua origem de replicação.

  2. Conecte-se à instância de banco de dados e emita os procedimentos mysql_rds_set_external_master e mysql_rds_start_replication para iniciar a replicação com seu mestre de replicação usando o nome e a localização do arquivo de log binário da etapa anterior. Veja um exemplo a seguir.

    For Aurora MySQL version 1 and 2: CALL mysql.rds_set_external_master ('mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0); For Aurora MySQL version 3 and higher: CALL mysql.rds_set_external_source ('mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0); For all versions: CALL mysql.rds_start_replication;

MySQL (externo)

Para habilitar a replicação a partir de um banco de dados MySQL externo

  1. Recupere o arquivo de log binário e a posição de log binário que representam são o ponto de partida para a replicação. Você recuperou esses valores do comando SHOW SLAVE STATUS (Aurora MySQL versões 1 e 2) ou SHOW REPLICA STATUS (Aurora MySQL versão 3) ao criar o snapshot da sua origem de replicação. Se o seu destino de réplica do MySQL externo tiver sido preenchido com o resultado do comando mysqldump com a opção --master-data=2, o arquivo de log binário e a posição do log binário estão inclusos no resultado. Veja um exemplo a seguir.

    -- -- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
  2. Conecte-se ao destino de réplica do MySQL externo e emita CHANGE MASTER TO e START SLAVE (Aurora MySQL versões 1 e 2) ou START REPLICA (Aurora MySQL versão 3) para iniciar a replicação com sua origem de replicação utilizando o nome e a localização do arquivo de log binário da etapa anterior, por exemplo:

    CHANGE MASTER TO MASTER_HOST = 'mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', MASTER_PORT = 3306, MASTER_USER = 'repl_user', MASTER_PASSWORD = '<password>', MASTER_LOG_FILE = 'mysql-bin-changelog.000031', MASTER_LOG_POS = 107; -- And one of these statements depending on your engine version: START SLAVE; -- Aurora MySQL version 1 and 2 START REPLICA; -- Aurora MySQL version 3

Se a replicação falhar, isso pode resultar em um grande aumento na E/S não intencional na réplica, o que pode prejudicar a performance. Se a replicação falhar ou não for mais necessária, você poderá executar o procedimento mysql.rds_reset_external_master armazenado para remover a configuração de replicação.

6. Monitore sua réplica

Ao configurar a replicação do MySQL com um cluster de banco de dados do Aurora MySQL, você deve monitorar eventos de failover para o cluster de banco de dados do Aurora MySQL quando se tratar do destino da réplica. Se ocorrer um failover, o cluster de banco de dados que for seu destino de réplica poderá ser recriado em um novo host com um endereço de rede diferente. Para obter informações sobre como monitorar eventos de failover, consulte Trabalhar com a notificação de eventos do Amazon RDS.

Também é possível monitorar até que ponto o destino de réplica está atrasado em relação à origem de replicação, conectando-se a esse destino de réplica e executando o comando SHOW SLAVE STATUS (Aurora MySQL versões 1 e 2) ou SHOW REPLICA STATUS (Aurora MySQL versão 3). No resultado do comando, o campo Seconds Behind Master indica quanto o destino da réplica está atrasado em relação à origem.

Como interromper a replicação entre o Aurora e o MySQL ou entre o Aurora e outro cluster de banco de dados Aurora

Para interromper a replicação do log binário com uma instância de banco de dados MySQL, um banco de dados MySQL externo ou outro cluster de banco de dados Aurora, siga estas etapas, abordadas a fundo no tópico a seguir.

1. Interrompa a replicação do log binário no destino da réplica

2. Desabilitar o registro em log binário na origem da replicação

1. Interrompa a replicação do log binário no destino da réplica

Encontre instruções sobre como interromper a replicação de log binário para o mecanismo do seu banco de dados a seguir.

Mecanismo do banco de dados Instruções

Aurora

Para interromper a replicação de log binário em um destino de réplica de cluster de banco de dados do Aurora MySQL

Conecte-se ao cluster do banco de dados Aurora, que é o destino de réplica, e chame o procedimento mysql_rds_stop_replication.

RDS for MySQL

Para interromper a replicação de log binário em uma instância de banco de dados do Amazon RDS

Conecte-se à instância do banco de dados RDS, que é o destino de réplica, e chame o procedimento mysql_rds_stop_replication. O procedimento mysql.rds_stop_replication está disponível somente para versões do MySQL 5.5 e mais recente, 5.6 e mais recente, 5.7 e mais recente.

MySQL (externo)

Para interromper a replicação de um log binário em um banco de dados MySQL externo

Conecte-se ao banco de dados MySQL e chame o comando STOP REPLICATION.

2. Desabilitar o registro em log binário na origem da replicação

Encontre instruções a seguir sobre como desabilitar o registro em log binário na origem de replicação para seu o mecanismo de banco de dados.

Mecanismo do banco de dados Instruções

Aurora

Para desabilitar o registro em log binário em um cluster de banco de dados do Amazon Aurora

  1. Conecte-se ao cluster do banco de dados do Aurora, que é a origem da replicação, e defina o período de retenção do log binário como 0. Para definir o período de retenção do log binário, use o procedimento mysql_rds_set_configuration e especifique um parâmetro de configuração de 'binlog retention hours', juntamente com o número de horas para reter arquivos de log binário no cluster do banco de dados, neste caso 0, conforme mostrado no exemplo a seguir.

    CALL mysql.rds_set_configuration('binlog retention hours', 0);
  2. Defina o parâmetro binlog_format como OFF na origem da replicação. O parâmetro binlog_format é um parâmetro em nível de cluster que se encontra no parameter group de cluster padrão.

    Após ter alterado o valor do parâmetro binlog_format, reinicie seu cluster de banco de dados para que a alteração entre em vigor.

    Para obter mais informações, consulte Parâmetros do cluster de banco de dados e da instância de bancos de dados Amazon Aurora e Modificar parâmetros em um grupo de parâmetros de banco de dados.

RDS for MySQL

Para desabilitar o registro em log binário em uma instância de banco de dados do Amazon RDS

Não é possível desabilitar o registro em log binário diretamente para uma instância de banco de dados do Amazon RDS, mas é possível desabilitá-lo seguindo um destes procedimentos:

  1. Desabilite backups automáticos da instância de banco de dados. É possível desabilitar backups automáticos modificando uma instância de banco de dados existente e definindo Backup Retention Period (Período de retenção de backup) como 0. Para obter mais informações, consulte Modificar uma instância de banco de dados do Amazon RDS e Trabalhar com backups no Guia do usuário do Amazon Relational Database Service.

  2. Exclua todas as réplicas de leitura para a instância de banco de dados. Para obter mais informações, consulte Trabalho com réplicas de leitura do MariaDB, MySQL e instâncias de banco de dados PostgreSQL no Guia do usuário do Amazon Relational Database Service.

MySQL (externo)

Para desabilitar o registro em log binário em um banco de dados MySQL externo

Conecte-se ao banco de dados MySQL e chame o comando STOP REPLICATION.

  1. Em um shell de comando, interrompa o serviço mysqld:

    sudo service mysqld stop
  2. Edite o arquivo my.cnf (esse arquivo normalmente se encontra em /etc).

    sudo vi /etc/my.cnf

    Exclua as opções log_bin e server_id da seção [mysqld].

    Para obter mais informações, consulte Setting the replication source configuration na documentação do MySQL.

  3. Inicie o serviço mysql.

    sudo service mysqld start

Como usar o Amazon Aurora para escalar leituras para seu banco de dados MySQL

Você pode usar o Amazon Aurora com sua instância de banco de dados MySQL para aproveitar os recursos de escalabilidade de leitura do Amazon Aurora e expandir a workload de leitura de sua instância do banco de dados MySQL. Para usar o Aurora para dimensionar a leitura da instância de banco de dados MySQL, crie um cluster de banco de dados do Amazon Aurora MySQL e faça dele uma réplica de leitura da instância do banco de dados MySQL. Isso se aplica a uma instância de banco de dados RDS for MySQL ou a um banco de dados MySQL executado externamente em relação ao Amazon RDS.

Para obter informações sobre como criar com um cluster de banco de dados do Amazon Aurora, consulte Criar um cluster de bancos de dados Amazon Aurora.

Ao configurar a replicação entre sua instância de banco de dados MySQL e seu cluster de banco de dados Amazon Aurora, certifique-se de seguir estas diretrizes:

  • Use o endereço de endpoint do cluster de banco de dados do Amazon Aurora ao fazer referência a seu cluster de banco de dados do Amazon Aurora MySQL. Se ocorrer um failover, a réplica do Aurora promovida a instância primária para o cluster de banco de dados do Aurora MySQL continuará a usar o endereço do endpoint do cluster de banco de dados.

  • Retenha os logs binários na instância de gravador até confirmar que eles foram aplicados à réplica do Aurora. Essa manutenção garante que você possa restaurar a instância de gravador em caso de falha.

Importante

Ao usar a replicação autogerenciada, você será responsável por monitorar e resolver quaisquer problemas de replicação que possam ocorrer. Para obter mais informações, consulte Diagnosticar e resolver atrasos entre réplicas de leitura.

nota

As permissões necessárias para iniciar a replicação em um cluster de banco de dados do Amazon Aurora MySQL são restritas e não estão disponíveis ao seu usuário principal do Amazon RDS. Por isso, você deve usar os procedimentos do Amazon RDS, mysql_rds_set_external_master e mysql_rds_start_replication, para configurar a replicação entre o cluster de banco de dados do Amazon Aurora MySQL e sua instância de banco de dados MySQL.

Iniciar a replicação entre uma instância de origem externa e uma instância de banco de dados MySQL no Amazon RDS

  1. Confirme que a instância do banco de dados MySQL é somente leitura:

    mysql> FLUSH TABLES WITH READ LOCK; mysql> SET GLOBAL read_only = ON;
  2. Execute o comando SHOW MASTER STATUS na instância do banco de dados MySQL de origem para determinar a localização do log binário. Você recebe um resultado semelhante ao seguinte exemplo:

    File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------
  3. Copie o banco de dados da instância de banco de dados MySQL externa para o cluster de banco de dados do Amazon Aurora MySQL usando mysqldump. Para bancos de dados muito grandes, pode ser conveniente usar o procedimento descrito em Importar dados para uma instância de banco de dados MariaDB ou MySQL do Amazon RDS com tempo de inatividade reduzido no Guia do usuário do Amazon Relational Database Service.

    Para Linux, macOS ou Unix:

    mysqldump \ --databases <database_name> \ --single-transaction \ --compress \ --order-by-primary \ -u <local_user> \ -p <local_password> | mysql \ --host aurora_cluster_endpoint_address \ --port 3306 \ -u <RDS_user_name> \ -p <RDS_password>

    Para Windows:

    mysqldump ^ --databases <database_name> ^ --single-transaction ^ --compress ^ --order-by-primary ^ -u <local_user> ^ -p <local_password> | mysql ^ --host aurora_cluster_endpoint_address ^ --port 3306 ^ -u <RDS_user_name> ^ -p <RDS_password>
    nota

    Confirme que não há um espaço entre a opção -p e a senha inserida.

    Use as opções --host, --user (-u), --port e -p no comando mysql para especificar o nome do host, o nome do usuário, a porta e a senha para conectar-se ao cluster de banco de dados do Aurora. O nome do host é o nome de DNS do endpoint do cluster de banco de dados do Amazon Aurora, por exemplo, mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com. Você pode encontrar o valor do endpoint nos detalhes do cluster no Console de gerenciamento do Amazon RDS.

  4. Confirme que é possível gravar na instância do banco de dados MySQL novamente:

    mysql> SET GLOBAL read_only = OFF; mysql> UNLOCK TABLES;

    Para obter mais informações sobre como fazer backups para usar com a replicação, consulte Backing up a source or replica by making it read only na documentação do MySQL.

  5. No Console de gerenciamento do Amazon RDS, adicione o endereço IP do servidor que hospeda o banco de dados MySQL de origem ao grupo de segurança da VPC para o cluster de banco de dados do Amazon Aurora. Para obter mais informações sobre como modificar um grupo de segurança da VPC, consulte Grupos de segurança para a VPC no Manual do usuário da Amazon Virtual Private Cloud.

    Você também pode precisar configurar sua rede local para permitir conexões com o endereço IP de seu cluster de banco de dados Amazon Aurora, para que ele possa se comunicar com sua instância MySQL de origem. Para encontrar o endereço IP do cluster de banco de dados do Amazon Aurora, use o comando host.

    host <aurora_endpoint_address>

    O nome do host é o nome de DNS do endpoint do cluster de banco de dados Amazon Aurora.

  6. Usando o cliente de sua preferência, conecte-se à instância externa do MySQL e crie um usuário do MySQL a ser usado para a replicação. Esta conta é usada unicamente para replicação e deve estar restrita ao seu domínio para melhorar a segurança. Veja um exemplo a seguir.

    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';
  7. Para a instância externa do MySQL, conceda privilégios de REPLICATION CLIENT e REPLICATION SLAVE para seu usuário de replicação. Por exemplo, para conceder os privilégios de REPLICATION CLIENT e REPLICATION SLAVE em todos os bancos de dados para o usuário 'repl_user' de seu domínio, emita o seguinte comando.

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';
  8. Faça um snapshot manual do cluster de banco de dados do Aurora MySQL para ser a réplica de leitura antes de configurar a replicação. Se for necessário restabelecer a replicação com o cluster de banco de dados como uma réplica de leitura, você poderá restaurar o cluster de banco de dados do Aurora MySQL desse snapshot, em vez de precisar importar os dados da instância de banco de dados MySQL para um novo cluster de banco de dados do Aurora MySQL.

  9. Faça do cluster de banco Amazon Aurora a réplica. Conecte-se ao cluster de banco de dados do Amazon Aurora como o usuário mestre e identifique o banco de dados MySQL de origem como o mestre de replicação usando o procedimento mysql_rds_set_external_master. Use o nome do arquivo de log mestre e a posição do log mestre que você determinou na Etapa 2. Veja um exemplo a seguir.

    For Aurora MySQL version 1 and 2: CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0); For Aurora MySQL version 3 and higher: CALL mysql.rds_set_external_source ('mymasterserver.mydomain.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);
  10. No cluster de banco de dados do Amazon Aurora, use o procedimento mysql_rds_start_replication para iniciar a replicação.

    CALL mysql.rds_start_replication;

Após ter estabelecido a replicação entre sua instância de banco de dados MySQL e seu cluster de banco de dados do Amazon Aurora, você poderá adicionar réplicas do Aurora ao seu cluster de banco de dados do Amazon Aurora. Você poderá então se conectar às réplicas do Aurora para fazer a escalabilidade de leitura de seus dados. Para obter informações sobre como criar uma réplica do Aurora, consulte Adicionar réplicas do Aurora a um cluster de banco de dados.

Otimização da replicação de log binário

A seguir, você pode aprender como otimizar a performance da replicação de log binário e solucionar problemas relacionados no Aurora MySQL.

dica

Esta discussão presume que você esteja familiarizado com o mecanismo de replicação de log binário do MySQL e como funciona. Para obter informações anteriores, consulte Implementação de replicação na documentação do MySQL.

Replicação de logs binários de versões posteriores (Aurora MySQL versão 3 e posteriores)

Com a replicação de logs binários de vários threads, um thread SQL faz a leitura de eventos do log de retransmissão e coloca esses eventos em fila para que os threads de operador SQL sejam aplicados. Os threads de operador SQL são gerenciados por um thread coordenador. Os eventos de log binário são aplicados em paralelo sempre que possível.

Quando uma instância do Aurora MySQL está configurada para utilizar a replicação de log binário, por padrão, a instância de réplica utiliza a replicação de um único thread. Para habilitar a replicação de vários threads, atualize o parâmetro replica_parallel_workers para um valor superior a no seu grupo de parâmetros personalizado.

As opções de configuração a seguir ajudam a ajustar a replicação de vários threads. Para obter informações sobre uso, consulte o tópico sobre Opções e variáveis de replicação e registro em log binário, no Manual de referência do MySQL.

A configuração ideal depende de diversos fatores. Por exemplo, a performance da replicação de log binário é influenciada pelas características da workload do seu banco de dados e pela classe de instância de banco de dados na qual a réplica está sendo executada. Por isso, convém testar completamente todas as alterações nesses parâmetros de configuração antes de aplicar novas configurações de parâmetros a uma instância de produção.

  • replica_parallel_workers

  • replica_parallel_type

  • replica_preserve_commit_order

  • binlog_transaction_dependency_tracking

  • binlog_transaction_dependency_history_size

  • binlog_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

Otimizar a replicação de binlog (Aurora MySQL 2,10 e posteriores)

No Aurora MySQL 2.10 e posteriores, o Aurora aplica automaticamente uma otimização conhecida como cache de E/S de binlog à replicação de log binário. Ao armazenar em cache os eventos de binlog confirmados mais recentemente, essa otimização foi projetada para melhorar a performance do processo de despejo de binlog, limitando o impacto nas transações em primeiro plano na instância de origem do binlog.

nota

Essa memória usada para esse recurso é independente da configuração binlog_cache do MySQL.

Esse recurso não se aplica a instâncias de banco de dados do Aurora que usam as classes de instância db.t2 e db.t3.

Você não precisa ajustar nenhum parâmetro de configuração para ativar essa otimização. Especificamente, se você ajustar o parâmetro de configuração aurora_binlog_replication_max_yield_seconds para um valor diferente de zero em versões anteriores do Aurora MySQL, defina-o de volta para zero no Aurora MySQL 2.10 e posteriores.

As variáveis de status aurora_binlog_io_cache_reads e aurora_binlog_io_cache_read_requests estão disponíveis no Aurora MySQL 2.10 e posteriores. Essas variáveis de status ajudam você a monitorar a frequência com que os dados são lidos do cache de E/S do binlog.

  • aurora_binlog_io_cache_read_requests: mostra o número de solicitações de leitura de E/S para binlog provenientes do cache.

  • aurora_binlog_io_cache_reads: mostra o número de leituras de E/S para binlog que recuperam informações do cache.

A consulta SQL a seguir calcula a porcentagem de solicitações de leitura de binlog que aproveitam as informações armazenadas em cache. Nesse caso, quanto mais próxima a proporção for de 100, melhor ela é.

mysql> SELECT (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads') / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests') * 100 as binlog_io_cache_hit_ratio; +---------------------------+ | binlog_io_cache_hit_ratio | +---------------------------+ | 99.99847949080622 | +---------------------------+

O recurso de cache de E/S de binlog também inclui novas métricas relacionadas aos processos de despejo de binlog. Processos de despejo são os processos criados quando novas réplicas de binlog são conectadas à instância de origem de binlog.

As métricas de processos de despejo são impressas no log do banco de dados a cada 60 segundos com o prefixo [Dump thread metrics]. As métricas incluem informações para cada réplica de binlog Secondary_id, como Secondary_uuid, nome do arquivo de binlog e a posição que cada réplica está lendo. As métricas também incluem Bytes_behind_primary, que representa a distância em bytes entre a origem da replicação e a réplica. Essa métrica mede o atraso do processo de E/S da réplica. Essa figura é diferente do lag do processo do aplicador SQL da réplica, que é representado pela métrica seconds_behind_master na réplica do binlog. Você pode determinar se as réplicas de binlog estão alcançando a origem ou ficando para trás, verificando se a distância diminui ou aumenta.

Otimizar a replicação de binlog (Aurora MySQL 2.04.5 a 2.09)

Para otimizar a replicação de log binário para Aurora MySQL, ajuste os seguintes parâmetros de otimização no nível do cluster. Esses parâmetros ajudam você a especificar o equilíbrio correto entre a latência na instância de origem do log binário e o atraso de replicação.

  • aurora_binlog_use_large_read_buffer

  • aurora_binlog_read_buffer_size

  • aurora_binlog_replication_max_yield_seconds

nota

Para clusters compatíveis com o MySQL 5.7, você pode usar esses parâmetros no Aurora MySQL versão 2.04.5 a 2.09*. No Aurora MySQL 2.10.0 e posteriores, esses parâmetros são substituídos pela otimização do cache de E/S de binlog e você não precisa usá-los.

Para clusters compatíveis com o MySQL 5.6, você pode usar esses parâmetros na Aurora MySQL versão 1.17.6 e posterior.

Visão geral do grande buffer de leitura e otimizações de rendimento máximo

Você pode observar performance reduzida da replicação de log binário quando o thread de despejo de log binário acessa o volume do Aurora cluster enquanto o cluster processa um número elevado de transações. Você pode usar os parâmetros aurora_binlog_use_large_read_buffer, aurora_binlog_replication_max_yield_seconds e aurora_binlog_read_buffer_size para ajudar a minimizar esse tipo de contenção.

Suponha uma situação em que aurora_binlog_replication_max_yield_seconds está definido como maior que 0, e o arquivo de log binário atual do thread de despejo está ativo. Nesse caso, o thread de despejo de log binário aguarda até um número específico de segundos para que o arquivo de binlog atual seja preenchido por transações. Esse período de espera evita a disputa que pode surgir da replicação de cada evento de log binário individualmente. No entanto, isso aumenta o atraso da réplica para réplicas de log binário. Essas réplicas podem ficar atrás da origem pelo mesmo número de segundos que a configuração de aurora_binlog_replication_max_yield_seconds.

O arquivo de log binário atual significa o arquivo de log binário que o thread de despejo está fazendo a leitura atualmente para executar a replicação. Consideramos que um arquivo de log binário está ativo quando o arquivo de log binário está atualizando ou aberto para ser atualizado por transações recebidas. Depois de Aurora MySQL preencher o arquivo de log binário ativo, o MySQL cria e muda para um novo arquivo de log binário. O arquivo de log de binário antigo fica inativo. Ele não é mais atualizado por transações recebidas.

nota

Antes de ajustar esses parâmetros, meça a latência e a taxa de transferência da transação ao longo do tempo. Você pode achar que a performance de replicação de log binário é estável e tem baixa latência, mesmo que haja contenção ocasional.

aurora_binlog_use_large_read_buffer

Se esse parâmetro for definido como 1, Aurora MySQL otimiza a replicação de log binário com base nas configurações dos parâmetros aurora_binlog_read_buffer_size e aurora_binlog_replication_max_yield_seconds. Se aurora_binlog_use_large_read_buffer for 0, Aurora MySQL ignora os valores dos parâmetros aurora_binlog_read_buffer_size e aurora_binlog_replication_max_yield_seconds.

aurora_binlog_read_buffer_size

Os threads de despejo de log binário com buffer de leitura maior minimizam o número de operações de E/S de leitura lendo mais eventos para cada E/S. O parâmetro aurora_binlog_read_buffer_size define o tamanho do buffer de leitura. O buffer de leitura grande pode reduzir a disputa de log binário para workloads que geram uma grande quantidade de dados de log binário.

nota

Este parâmetro só tem um efeito quando o cluster também tem a configuração aurora_binlog_use_large_read_buffer=1.

Aumentar o tamanho do buffer de leitura não afeta a performance da replicação de log binário. Os threads de despejo de log binário não esperam a atualização de transações para preencher o buffer de leitura.

aurora_binlog_replication_max_yield_seconds

Se sua carga de trabalho exigir baixa latência de transação e você pode suportar algum atraso de replicação, é possível aumentar o parâmetro de aurora_binlog_replication_max_yield_seconds. Esse parâmetro controla a propriedade de rendimento máximo da replicação de log binário no cluster.

nota

Este parâmetro só tem um efeito quando o cluster também tem a configuração aurora_binlog_use_large_read_buffer=1.

Aurora MySQL reconhece qualquer alteração no valor do parâmetro aurora_binlog_replication_max_yield_seconds imediatamente. Você não precisa reiniciar a instância de banco de dados. No entanto, quando você habilita essa configuração, o thread de despejo apenas começa a gerar resultados quando o arquivo de binlog atual atinge seu tamanho máximo de 128 MB e é alternado para um novo arquivo.

Parâmetros relacionados

Utilize os seguintes parâmetros de cluster de banco de dados para habilitar a otimização de binlog.

Parâmetros de otimização de log binário para a Aurora MySQL versão 2.04.5 e posterior
Parâmetro Padrão Valores válidos Descrição
aurora_binlog_use_large_read_buffer 1 0, 1 Alterne para ativar o recurso de melhoria de replicação. Quando é 1, o thread de despejo de log binário usa aurora_binlog_read_buffer_size para replicação de log binário; caso contrário, o tamanho do buffer padrão (8K) é usado.
aurora_binlog_read_buffer_size 5242880 8192-536870912 Leia o tamanho do buffer usado pelo thread de despejo de log binário quando o parâmetro aurora_binlog_use_large_read_buffer é definido como 1.
aurora_binlog_replication_max_yield_seconds 0 0-36000 Para o Aurora MySQL versões entre 2.04.5 - 2.04.8 e entre 2.05 - 2.08.*, o valor máximo aceito é de 45. Você pode ajustá-lo para um valor mais alto em 2.04.9 e versões posteriores do 2.04.* e em versões 2.09 e posteriores. Esse parâmetro funciona somente quando o parâmetro aurora_binlog_use_large_read_buffer é definido como 1.
Parâmetros de otimização de log binário para a Aurora MySQL versão 1.17.6 e posterior
Parâmetro Padrão Valores válidos Descrição
aurora_binlog_use_large_read_buffer 0 0, 1 Alterne para ativar o recurso de melhoria de replicação. Quando é 1, o thread de despejo de log binário é usado aurora_binlog_read_buffer_size para replicação de log binário. Caso contrário, o tamanho do buffer padrão (8 KB) será usado.
aurora_binlog_read_buffer_size 5242880 8192-536870912 Leia o tamanho do buffer usado pelo thread de despejo de log binário quando o parâmetro aurora_binlog_use_large_read_buffer é definido como 1.
aurora_binlog_replication_max_yield_seconds 0 0-36000 Máximo de segundos para produzir quando o thread de despejo de log binário replica o arquivo de log binário atual (o arquivo usado por consultas em primeiro plano) para réplicas. Esse parâmetro funciona somente quando o parâmetro aurora_binlog_use_large_read_buffer é definido como 1.
Habilitar o mecanismo de rendimento máximo para replicação de log binário

Você pode ativar a otimização de rendimento máximo de replicação de log binário da seguinte forma. Isso minimiza a latência para transações na instância de origem do log binário. No entanto, você pode ter maior atraso de replicação.

Para habilitar a otimização de binlog com rendimento máximo para um cluster do Aurora MySQL

  1. Crie ou edite um grupo de parâmetros de cluster de banco de dados usando as seguintes configurações de parâmetros:

    • aurora_binlog_use_large_read_buffer: ative um valor de ON ou 1.

    • aurora_binlog_replication_max_yield_seconds: especifique um valor maior que 0.

  2. Associe o grupo de parâmetro do cluster de banco de dados ao cluster de Aurora MySQL que funciona como a origem do log binário. Para isso, siga o procedimento em Trabalhar com grupos de parâmetros.

  3. Confirme se a alteração do parâmetro entra em vigor. Para isso, execute a seguinte consulta na instância de origem do log binário.

    SELECT @@aurora_binlog_use_large_read_buffer, @@aurora_binlog_replication_max_yield_seconds;

    Sua saída deve ser similar à seguinte.

    +---------------------------------------+-----------------------------------------------+ | @@aurora_binlog_use_large_read_buffer | @@aurora_binlog_replication_max_yield_seconds | +---------------------------------------+-----------------------------------------------+ | 1 | 45 | +---------------------------------------+-----------------------------------------------+
Desativar a otimização de rendimento máximo de replicação de log binário

Você pode desativar a otimização de rendimento máximo de replicação de log binário da seguinte forma. Isso minimiza o atraso de replicação. No entanto, você pode ter maior latência para transações na instância de origem do log binário.

Para desativar a otimização de rendimento máximo de um cluster de Aurora MySQL

  1. Certifique-se que o grupo de parâmetros de cluster de banco de dados associado ao cluster do Aurora MySQL tenha aurora_binlog_replication_max_yield_seconds definido como 0. Para obter mais informações sobre a definição de parâmetros de configuração usando grupos de parâmetros, consulte Trabalhar com grupos de parâmetros.

  2. Confirme se a alteração do parâmetro entra em vigor. Para isso, execute a seguinte consulta na instância de origem do log binário.

    SELECT @@aurora_binlog_replication_max_yield_seconds;

    Sua saída deve ser similar à seguinte.

    +-----------------------------------------------+ | @@aurora_binlog_replication_max_yield_seconds | +-----------------------------------------------+ | 0 | +-----------------------------------------------+
Desativando o grande buffer de leitura

É possível desabilitar todo o recurso de buffer de leitura grande da seguinte maneira.

Para desativar o buffer de leitura de log binário grande para um cluster de Aurora MySQL

  1. Redefina o aurora_binlog_use_large_read_buffer para OFF ou 0.

    Certifique-se que o grupo de parâmetros de cluster de banco de dados associado ao cluster do Aurora MySQL tenha aurora_binlog_use_large_read_buffer definido como 0. Para obter mais informações sobre a definição de parâmetros de configuração usando grupos de parâmetros, consulte Trabalhar com grupos de parâmetros.

  2. Na instância de origem do log binário, execute a seguinte consulta.

    SELECT @@ aurora_binlog_use_large_read_buffer;

    Sua saída deve ser similar à seguinte.

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

Como sincronizar senhas entre a fonte e o destino da replicação

Ao alterar contas e senhas de usuário na fonte de replicação usando instruções SQL, as alterações são automaticamente replicadas para o destino de replicação.

Se você usar o AWS Management Console, a AWS CLI ou a API do RDS para alterar a senha primária na fonte de replicação, essas alterações não serão replicadas automaticamente para o destino de replicação. Se quiser sincronizar o usuário primário e a senha primária entre os sistemas de fonte e de destino, você deverá fazer a mesma alteração no destino de replicação por conta própria.