Replicação com o Amazon Aurora MySQL - Amazon Aurora
Réplicas do AuroraOpções de replicaçãoPerformance de replicaçãoZero-downtime restart (ZDR – Reinício com tempo de inatividade zero)Configurar filtros de replicaçãoMonitorar a replicação do

Replicação 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.

Nos tópicos a seguir, é 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.

Tópicos

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. É possível distribuir até 15 réplicas do Aurora entre as zonas de disponibilidade que um cluster de banco de dados abrange 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 obter 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.

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. Ele está sempre habilitado no Aurora MySQL versão 2 e versão 3.

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.

No Aurora MySQL versão 2, você pode controlar esse recurso alterando o valor do 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.

A filtragem do log binário está sempre habilitada no Aurora MySQL versão 3.

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.

O ZDR para Aurora MySQL 2.x requer a versão 2.10 e posterior. O ZDR está disponível em todas as versões secundárias do Aurora MySQL 3.x. 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 ter mais informações sobre valores de incremento automático, consulte o Guia 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, os perfis de instância e outras circunstâncias que determinam se o Aurora pode ou não usar o mecanismo ZDR ao reiniciar instâncias de banco de dados no cluster.

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

2.x, anterior a 2.10.0

Não

Não

N/D

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

2.10.0 a 2.11.0

Sim

Sim

Sim

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.

2.11.1 e posterior

Sim

Sim

Sim

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 tabelas temporárias, bloqueios de tabela ou bloqueios de usuário.

3.01 a 3.03

Sim

Sim

Sim

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.

3.04 e posterior

Sim

Sim

Sim

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 tabelas temporárias, bloqueios de tabela ou bloqueios de usuário.

Configurar filtros de replicação com o Aurora MySQL

Você pode usar filtros de replicação para especificar quais bancos de dados e tabelas são replicados com uma réplica de leitura. Os filtros de replicação podem incluir bancos de dados e tabelas na replicação ou excluí-los da replicação.

Veja a seguir alguns casos de uso para filtros de replicação:

  • Para reduzir o tamanho de uma réplica de leitura. Com a filtragem de replicação, você pode excluir os bancos de dados e tabelas que não são necessários na réplica de leitura.

  • Para excluir bancos de dados e tabelas de réplicas de leitura por motivos de segurança.

  • Para replicar diferentes bancos de dados e tabelas para casos de uso específicos em diferentes réplicas de leitura. Por exemplo, você pode usar réplicas de leitura específicas para análise ou fragmentação.

  • Para um cluster de banco de dados que tenha réplicas de leitura em diferentes Regiões da AWS, para replicar diferentes bancos de dados ou tabelas em diferentes Regiões da AWS.

  • Para especificar quais bancos de dados e tabelas serão replicados com um cluster de banco de dados do Aurora MySQL configurado como uma réplica em uma topologia de replicação de entrada. Para obter mais informações sobre essa configuração, 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).

Configurar parâmetros de filtragem de replicação para o Aurora MySQL

Para configurar filtros de replicação, defina os seguintes parâmetros:

  • binlog-do-db: replicar alterações para os logs binários especificados. Ao definir esse parâmetro para um cluster de origem do log binário, somente os logs binários especificados no parâmetro são replicados.

  • binlog-ignore-db: não replicar alterações para os logs binários especificados. Quando o parâmetro binlog-do-db é definido para um cluster de origem do log binário, esse parâmetro não é avaliado.

  • replicate-do-db – Replicar alterações nos bancos de dados especificados. Ao definir esse parâmetro para um cluster de réplica do log binário, somente os bancos de dados especificados no parâmetro são replicados.

  • replicate-ignore-db – Não replique as alterações nos bancos de dados especificados. Quando o parâmetro replicate-do-db é definido para um cluster de réplica do log binário, esse parâmetro não é avaliado.

  • replicate-do-table – Replicar alterações nas tabelas especificadas. Quando você define esse parâmetro para uma réplica de leitura, somente as tabelas especificadas no parâmetro são replicadas. Além disso, quando o parâmetro replicate-do-db ou replicate-ignore-db estiver definido, inclua o banco de dados que contém as tabelas especificadas na replicação com o cluster de réplica do log binário.

  • replicate-ignore-table – Não replique as alterações nas tabelas especificadas. Quando o parâmetro replicate-do-table é definido para um cluster de réplica do log binário, esse parâmetro não é avaliado.

  • replicate-wild-do-table – Replicar tabelas com base nos padrões de nome de banco de dados e tabela especificados. Os caracteres curinga % e _ são compatíveis. Quando o parâmetro replicate-do-db ou replicate-ignore-db estiver definido, inclua o banco de dados que contém as tabelas especificadas na replicação com o cluster de réplica do log binário.

  • replicate-wild-ignore-table – Não replique tabelas com base nos padrões de nome de banco de dados e tabela especificados. Os caracteres curinga % e _ são compatíveis. Quando o parâmetro replicate-do-table ou replicate-wild-do-table é definido para um cluster de réplica do log binário, esse parâmetro não é avaliado.

Os parâmetros são avaliados na ordem em que estão listados. Para obter mais informações sobre como esses parâmetros funcionam, consulte a documentação do MySQL:

Por padrão, cada um desses parâmetros tem um valor vazio. Em cada cluster de log binário, é possível usar esses parâmetros para definir, alterar e excluir filtros de replicação. Quando você define um desses parâmetros, separe cada filtro dos outros com uma vírgula.

Você pode usar % os caracteres curinga _ e nos parâmetros replicate-wild-do-table e replicate-wild-ignore-table. O curinga % corresponde a qualquer número de caracteres e o caractere curinga _ corresponde apenas a um caractere.

O formato de log binário da instância de banco de dados de origem é importante para replicação porque determina o registro de alterações de dados. A configuração do parâmetro binlog_format determina se a replicação é baseada em linha ou baseada em declaração. Para obter mais informações, consulte Configurar o registro em log binário do Aurora MySQL.

nota

Todas as instruções DDL (Data Definition Language, linguagem de definição de dados) são replicadas como instruções, independentemente da binlog_format configuração na instância de banco de dados de origem.

Limitações de filtragem de replicação para o Aurora MySQL

As seguintes limitações se aplicam à filtragem de replicação para o Aurora MySQL:

  • Os filtros de replicação são compatíveis somente com o Aurora MySQL versão 3.

  • Cada parâmetro de filtragem de replicação tem um limite de 2.000 caracteres.

  • As vírgulas não são compatíveis em filtros de replicação.

  • A filtragem de replicação não suporta transações XA.

    Para obter mais informações, consulte Restrictions on XA Transactions na documentação do MySQL.

Exemplos de filtragem de replicação para o Aurora MySQL

Para configurar a filtragem de replicação para uma réplica de leitura, modifique os parâmetros de filtragem de replicação no grupo de parâmetros do cluster de banco de dados associado à réplica de leitura.

nota

Não é possível modificar um grupo de parâmetros de cluster de banco de dados padrão. Se a réplica de leitura estiver usando um grupo de parâmetros padrão, crie um novo grupo de parâmetros e o associe à instância de banco de dados. Para obter mais informações sobre os grupos de parâmetros de cluster de banco de dados, consulte Trabalhar com grupos de parâmetros.

Você pode definir parâmetros em um grupo de parâmetros de cluster de banco de dados usando o AWS Management Console, a AWS CLI ou a API do RDS. Para obter informações sobre como configurar parâmetros, consulte Modificar parâmetros em um grupo de parâmetros de banco de dados. Quando você define parâmetros em um grupo de parâmetros de cluster de banco de dados, todos os clusters de banco de dados associados ao grupo de parâmetros usam as configurações de parâmetros. Se você definir os parâmetros de filtragem de replicação em um grupo de parâmetros de cluster de banco de dados, verifique se o grupo de parâmetros está associado apenas a clusters de réplica de leitura. Deixe os parâmetros de filtragem de replicação vazios para instâncias de banco de dados de origem.

Os exemplos a seguir definem os parâmetros usando o AWS CLI. Estes exemplos definem ApplyMethod para immediate de modo que as mudanças do parâmetro ocorram imediatamente depois que o comando CLI termina. Se você quiser que uma alteração pendente seja aplicada depois que a réplica de leitura for reinicializada, defina como ApplyMethod pending-reboot.

Os exemplos a seguir definem filtros de replicação:

exemplo Incluir bancos de dados em replicação

O exemplo a seguir inclui os bancos de dados mydb1 e mydb2 na replicação.

Para Linux, macOS ou Unix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"

Para Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"
exemplo Incluir tabelas na replicação

O exemplo a seguir inclui as tabelas table1 e table2 no banco de dados mydb1 na replicação.

Para Linux, macOS ou Unix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"

Para Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"
exemplo Incluir tabelas na replicação usando caracteres curinga

O exemplo a seguir inclui tabelas com nomes que começam com order e return no banco de dados mydb na replicação.

Para Linux, macOS ou Unix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"

Para Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"
exemplo Excluir bancos de dados da replicação

O exemplo a seguir exclui os bancos de dados mydb5 e mydb6 da replicação.

Para Linux, macOS ou Unix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate"

Para Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6,ApplyMethod=immediate"
exemplo Excluir tabelas da replicação

O exemplo a seguir exclui a tabela table1 no banco de dados mydb5 e a tabela table2 no banco de dados mydb6 da replicação.

Para Linux, macOS ou Unix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"

Para Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"
exemplo Excluir tabelas da replicação usando caracteres curinga

O exemplo a seguir exclui tabelas com nomes que começam com order e return no banco de dados mydb7 da replicação.

Para Linux, macOS ou Unix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"

Para Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"

Visualizar os filtros de replicação para uma réplica de leitura

Você pode visualizar os filtros de replicação de uma réplica de leitura das seguintes maneiras:

  • Verifique as configurações dos parâmetros de filtragem de replicação no grupo de parâmetros associado à réplica de leitura.

    Para obter instruções, consulte Visualizar valores de parâmetros para um grupo de parâmetros de banco de dados.

  • Em um cliente MySQL, conecte-se à réplica de leitura e execute a instrução SHOW REPLICA STATUS.

    Na saída, os campos a seguir mostram os filtros de replicação para a réplica de leitura:

    • Binlog_Do_DB

    • Binlog_Ignore_DB

    • Replicate_Do_DB

    • Replicate_Ignore_DB

    • Replicate_Do_Table

    • Replicate_Ignore_Table

    • Replicate_Wild_Do_Table

    • Replicate_Wild_Ignore_Table

    Para obter mais informações sobre esses campos, consulte Verificar o status da replicação na documentação do MySQL.

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 AuroraReplicaLagMinimum 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 AuroraReplicaLagMinimum 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, confira a métrica AuroraReplicaLag no Amazon CloudWatch. O atraso da réplica do Aurora também é registrado em cada réplica do Aurora do cluster de banco de dados do Aurora MySQL na tabela information_schema.replica_host_status. Para obter mais informações sobre essa tabela, consulte information_schema.replica_host_status.

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.