Implantações de clusters de banco de dados multi-AZ

Uma implantação de cluster de banco de dados multi-AZ é um modo de implantação de alta disponibilidade semissíncrona do Amazon RDS com duas instâncias de banco de dados de réplica legíveis. Um cluster de bancos de dados multi-AZ tem uma instância de banco de dados de gravação e duas instâncias de banco de dados de leitura em três zonas de disponibilidade diferentes na mesma região da Região da AWS. Clusters de banco de dados multi-AZ oferecem alta disponibilidade, maior capacidade para workloads de leitura e menor latência do gravação quando comparados com implantação de instância de banco de dados multi-AZ.

Você pode importar dados de um banco de dados on-premises para um cluster de banco de dados multi-AZ seguindo as instruções em Importar dados para um banco de dados MariaDB ou MySQL do Amazon RDS com tempo de inatividade reduzido.

É possível comprar instâncias de banco de dados reservadas para um cluster de banco de dados multi-AZ. Para ter mais informações, consulte Instâncias de banco de dados reservadas para um cluster de banco de dados multi-AZ.

A disponibilidade e a compatibilidade de recursos variam entre versões específicas de cada mecanismo de banco de dados e entre Regiões da AWS. Para ter mais informações sobre a disponibilidade de versões e regiões do Amazon RDS com o clusters de banco de dados multi-AZ, consulte Clusters de banco de dados multi-AZ.

Tópicos

• Disponibilidade de classe de instância para clusters de banco de dados multi-AZ
• Visão geral de clusters de banco de dados multi-AZ
• Gerenciar um cluster de banco de dados multi-AZ com o AWS Management Console
• Trabalhar com grupos de parâmetros para clusters de banco de dados multi-AZ
• Atualizar a versão do mecanismo de um cluster de banco de dados multi-AZ
• Usando RDS Proxy com clusters de banco de dados multi-AZ
• Atraso de réplica e clusters de banco de dados multi-AZ
• Processo de failover para clusters de banco de dados multi-AZ
• Criar um cluster de banco de dados multi-AZ
• Conectar a um cluster de banco de dados multi-AZ
• Conectar automaticamente um recurso de computação da AWS e um cluster de banco de dados multi-AZ
• Modificar um cluster de banco de dados multi-AZ
• Renomear um cluster de banco de dados multi-AZ
• Reinicializar um cluster de banco de dados multi-AZ e instâncias de banco de dados de leitor
• Trabalhar com réplicas de leitura de cluster de banco de dados multi-AZ
• Usar a replicação lógica do PostgreSQL com clusters de banco de dados multi-AZ
• Excluir um cluster de banco de dados multi-AZ
• Limitações de clusters de banco de dados multi-AZ

Importante

Clusters de banco de dados multi-AZ não são idênticos a clusters de bancos de dados Aurora. Para obter informações sobre clusters de bancos de dados Aurora, consulte o Guia do usuário do Amazon Aurora.

Disponibilidade de classe de instância para clusters de banco de dados multi-AZ

As implantações de clusters de banco de dados multi-AZ são compatíveis com as seguintes classes de instância de banco de dados: db.m5d, db.m6gd, m6id, db.m6idn, db.r5d, db.r6gd, db.x2iedn, db.r6id, db.r6idn e db.c6gd.

nota

As classes de instância c6gd são as únicas compatíveis com o tamanho de instância medium.

Para ter mais informações sobre classes de instância de banco de dados, consulte Classes de instância de banco de dados .

Visão geral de clusters de banco de dados multi-AZ

Com um cluster de banco de dados multi-AZ, o Amazon RDS replica dados da instância de banco de dados de gravador para ambas as instâncias de banco de dados de leitor utilizando os recursos de replicação nativa do mecanismo de banco de dados. Quando uma alteração é feita na instância de banco de dados de gravador, ela é enviada a cada instância de banco de dados de leitor.

As implantações de cluster de banco de dados multi-AZ usam replicação semissíncrona, que requer reconhecimento de, pelo menos, uma instância de banco de dados de leitor para que uma alteração seja confirmada. Isso não exige o reconhecimento de que os eventos foram totalmente executados e confirmados em todas as réplicas.

Instâncias de banco de dados de leitor atuam como destinos de failover automático e também servem tráfego de leitura para aumentar a taxa de transferência de leitura da aplicação. Se ocorrer uma interrupção na instância de banco de dados de gravador, o RDS fará o gerenciamento do failover para uma das instâncias de banco de dados de leitor. O RDS faz isso com base em qual instância de banco de dados de leitor tem o registro de alteração mais recente.

O diagrama a seguir mostra um cluster de banco de dados multi-AZ.

Em geral, clusters de banco de dados multi-AZ têm menor latência de gravação quando comparados a implantações de instâncias de banco de dados multi-AZ. Ele também permite que workloads de somente leitura sejam executadas em instâncias de banco de dados do leitor. O console do RDS mostra a zona de disponibilidade da instância de banco de dados de gravador e as zonas de disponibilidade das instâncias de banco de dados de leitor. Você também pode usar o comando describe-db-clusters da CLI ou a operação de API DescribeDBClusters para encontrar essas informações.

Importante

Para evitar erros de replicação em clusters de banco de dados multi-AZ do RDS para MySQL, é altamente recomendável que todas as tabelas tenham uma chave primária.

Gerenciar um cluster de banco de dados multi-AZ com o AWS Management Console

É possível gerenciar um cluster de banco de dados multi-AZ com o console.

Para gerenciar um cluster de banco de dados multi-AZ com o console

1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

2. No painel de navegação, escolha Databases (Bancos de dados) e depois o cluster de banco de dados multi-AZ que você deseja gerenciar.

A seguinte imagem mostra um cluster de banco de dados multi-AZ no console.

As ações disponíveis no menu Actions (Ações) dependem de o cluster de banco de dados multi-AZ estar selecionado ou de uma instância de banco de dados no cluster estar selecionadar.

Escolha o cluster de banco de dados multi-AZ para visualizar os detalhes do cluster e realizar ações em nível de cluster.

Escolha uma instância de banco de dados em um cluster de banco de dados multi-AZ para visualizar os detalhes dessa instância e realizar ações em nível de instância.

Trabalhar com grupos de parâmetros para clusters de banco de dados multi-AZ

Em um cluster de banco de dados multi-AZ, um grupo de parâmetros de cluster de banco de dados atua como um contêiner para valores de configuração de mecanismo que são aplicados a cada instância de banco de dados no cluster de banco de dados multi-AZ.

Em um cluster de banco de dados multi-AZ, um grupo de parâmetros de banco de dados é definido como o grupo de parâmetros de banco de dados padrão do mecanismo de banco de dados e da versão do mecanismo de banco de dados. As configurações no grupo de parâmetros do cluster de banco de dados são utilizadas para todas as instâncias de banco de dados do cluster.

Para obter informações sobre grupos de parâmetros, consulte Trabalhar com grupos de parâmetros.

Atualizar a versão do mecanismo de um cluster de banco de dados multi-AZ

O Amazon RDS fornece versões mais recentes de cada mecanismo de banco de dados compatível, para que você possa manter o cluster de banco de dados multi-AZ atualizado. Quando o Amazon RDS oferecer suporte a uma nova versão de um mecanismo de banco de dados, escolha como e quando fazer a atualização do cluster de banco de dados multi-AZ.

Existem dois tipos de atualizações que você pode realizar:

Atualizações da versão principal

Uma atualização da versão principal do mecanismo pode apresentar alterações não compatíveis com as aplicações existentes. Ao iniciar uma atualização de versão principal, o Amazon RDS atualiza simultaneamente as instâncias de leitor e gravador. Portanto, o cluster de banco de dados pode não estar disponível até que a atualização seja concluída.

Atualizações de versões secundárias

Uma atualização de versão secundária inclui somente alterações compatíveis com versões anteriores dos aplicativos existentes. Quando você inicia uma atualização de versão secundária, o Amazon RDS primeiro atualiza as instâncias de banco de dados de leitor, uma por vez. Depois, uma das instâncias de banco de dados de leitor passa a ser a nova instância de banco de dados de gravador. Depois, o Amazon RDS atualiza a antiga instância de gravador (que agora é uma instância de leitor).

O tempo de inatividade durante a atualização é limitado ao tempo necessário para que uma das instâncias de banco de dados de leitor se torne a nova instância de banco de dados de gravador. Esse tempo de inatividade funciona como um failover automático. Para ter mais informações, consulte Processo de failover para clusters de banco de dados multi-AZ. Observe que o atraso da réplica do cluster de banco de dados multi-AZ pode afetar o tempo de inatividade. Para ter mais informações, consulte Atraso de réplica e clusters de banco de dados multi-AZ.

Para réplicas de leitura de cluster de banco de dados multi-AZ do RDS para PostgreSQL, o Amazon RDS atualiza as instâncias membros do cluster uma por vez. Os perfis do cluster de leitor e gravador não mudam durante a atualização. Portanto, o cluster de banco de dados pode passar por tempo de inatividade enquanto o Amazon RDS atualiza a instância de gravador de cluster.

nota

O tempo de inatividade para uma atualização da versão secundária de cluster de banco de dados multi-AZ é geralmente de 35 segundos. Quando usado com o RDS Proxy, é possível reduzir ainda mais o tempo de inatividade para um segundo ou menos. Para ter mais informações, consulte Usar o Amazon RDS Proxy. Como alternativa, é possível usar um proxy de banco de dados de código aberto, como ProxySQL, PgBouncer ou Driver AWS JDBC para MySQL.

No momento, o Amazon RDS é compatível com as atualizações de versão principal apenas para clusters de banco de dados multi-AZ do RDS para PostgreSQL. O Amazon RDS é compatível com atualizações de versão secundária para todos os mecanismos de banco de dados compatíveis com clusters de banco de dados multi-AZ.

O Amazon RDS não atualiza automaticamente réplicas de leitura de clusters de banco de dados multi-AZ. Com relação às atualizações de versão secundária, primeiro é necessário atualizar manualmente todas as réplicas de leitura e, depois, atualizar o cluster. Caso contrário, a atualização será bloqueada. Quando você realiza uma atualização de versãoprincipal de um cluster, o estado da replicação de todas as réplicas de leitura muda para Encerrado. Você deve excluir e recriar as réplicas de leitura após a conclusão da atualização. Para ter mais informações, consulte Monitoramento da replicação de leitura.

O processo de atualização da versão do mecanismo de um cluster de banco de dados multi-AZ é o mesmo processo de atualização de uma versão do mecanismo de instância de banco de dados. Para obter instruções, consulte Atualizar a versão de mecanismo de uma instância de banco de dados. A única diferença é que, ao usar a AWS Command Line Interface (AWS CLI), você usa o comando modifique-db-cluster e especifica o parâmetro --db-cluster-identifier (bem como o parâmetro --allow-major-version-upgrade).

Para ter mais informações sobre atualizações de versões principais e secundárias, consulte a seguinte documentação do mecanismo de banco de dados:

• Atualizar o mecanismo de banco de dados PostgreSQL para Amazon RDS

• Atualizar o mecanismo de banco de dados MySQL

Usando RDS Proxy com clusters de banco de dados multi-AZ

É possível usar o Amazon RDS Proxy para criar um proxy para os clusters de banco de dados multi-AZ. Com o RDS Proxy, as aplicações podem agrupar e compartilhar conexões de banco de dados para melhorar a capacidade de escala. Cada proxy também executa a multiplexação de conexões, também conhecida como reutilização de conexões. Com a multiplexação, o RDS Proxy executa todas as operações para uma transação usando uma conexão de banco de dados subjacente. O RDS Proxy também pode reduzir o tempo de inatividade de uma atualização de versão secundária de um cluster de banco de dados multi-AZ para um segundo ou menos. Para obter mais informações sobre os benefícios do &AS;, consulte Usar o Amazon RDS Proxy.

Para configurar um proxy para um cluster de banco de dados multi-AZ, escolha Criar um proxy RDS ao criar o cluster. Para obter instruções sobre como criar e gerenciar endpoints do RDS Proxy, consulte. Como trabalhar com endpoints do proxy do Amazon RDS

Atraso de réplica e clusters de banco de dados multi-AZ

Atraso de réplica é a diferença de tempo entre a transação mais recente na instância de banco de dados do gravador e a transação aplicada mais recente em uma instância de banco de dados do leitor. A métrica do Amazon CloudWatch ReplicaLag representa essa diferença de tempo. Para ter mais informações sobre métricas do CloudWatch, consulte Monitorar métricas do Amazon RDS com o Amazon CloudWatch.

Embora os clusters de banco de dados multi-AZ permitam uma alta performance de gravação, o atraso de réplica ainda pode ocorrer devido à natureza da replicação baseada em mecanismo. Como qualquer failover deve primeiro resolver o atraso de réplica antes de promover uma nova instância de banco de dados do gravador, monitorar e gerenciar esse atraso de réplica é algo a ser levado em consideração.

Para clusters de banco de dados multi-AZ do RDS para MySQL, o tempo de failover depende do atraso de réplica das duas instâncias de banco de dados de leitor. Ambas as instâncias de banco de dados do leitor devem aplicar transações não aplicadas antes que uma delas seja promovida para a nova instância de banco de dados de gravador.

Para clusters de banco de dados do RDS para PostgreSQL multi-AZ, o tempo de failover depende do menor atraso de réplica das duas instâncias de banco de dados de leitor restantes. A instância de banco de dados de leitor com o menor atraso de réplica deve aplicar as transações não aplicadas antes de ser promovida para a nova instância de banco de dados de gravador.

Para obter um tutorial que mostra como criar um alarme do CloudWatch quando o atraso de réplica excede um período de tempo definido, consulte Tutorial: criar um alarme do Amazon CloudWatch para atraso de réplica de cluster de banco de dados multi-AZ.

Causas comuns de atraso de réplica

Em geral, o atraso de réplica ocorre quando o workload de gravação é muito alto para que as instâncias de banco de dados do leitor apliquem as transações de forma eficiente. Vários workloads podem incorrer em atraso de réplica temporário ou contínuo. Os seguintes exemplos demonstram as causas comuns:

• Alta simultaneidade de gravação ou atualização em lote pesado na instância de banco de dados do gravador, fazendo com que o processo de aplicação nas instâncias de banco de dados do leitor fique para trás.

• Workload de leitura pesada que usa recursos em uma ou mais instâncias de banco de dados do leitor. Executar consultas lentas ou grandes pode afetar o processo de aplicação e causar atraso de réplica.

• As transações que modificam grandes quantidades de dados ou instruções DDL às vezes podem causar um aumento temporário no atraso de réplica porque o banco de dados deve preservar a ordem de confirmação.

Diminuir o atraso de réplica

Para clusters de banco de dados multi-AZ para RDS para MySQL e RDS para PostgreSQL, você pode mitigar o atraso de réplica reduzindo a carga na instância de banco de dados do gravador. Você também pode usar o controle de fluxo para reduzir o atraso da réplica. O controle de fluxo funciona controlando a utilização das gravações na instância de banco de dados do gravador, o que garante que o atraso de réplica não continue a crescer de forma não vinculada. O controle de utilização da gravação é realizado adicionando um atraso ao fim de uma transação, o que diminui a taxa de transferência de gravação na instância de banco de dados do gravador. Embora o controle de fluxo não garanta a eliminação do atraso, ele pode ajudar a reduzir o atraso geral em muitos workloads. As seções a seguir fornecem informações sobre como usar o controle de fluxo com o RDS para MySQL e o RDS para PostgreSQL.

Reduzir o atraso de réplica com controle de fluxo para o RDS para MySQL

Quando você está usando clusters de banco de dados multi-AZ do RDS para MySQL, o controle de transmissão é ativado por padrão usando o parâmetro dinâmico rpl_semi_sync_master_target_apply_lag. Esse parâmetro especifica o limite posterior que você deseja para o atraso de réplica. À medida que o atraso de réplica se aproxima desse limite configurado, o controle de transmissão controla a utilização das transações de gravação na instância de banco de dados de gravador para tentar conter o atraso de réplica abaixo do valor especificado. Em alguns casos, o atraso de réplica pode exceder o limite especificado. Por padrão, esse parâmetro é definido como 120 segundos. Para desativar o controle de transmissão, defina esse parâmetro como o valor máximo de 86.400 segundos (um dia).

Para exibir o atraso atual injetado pelo controle de transmissão, mostre o parâmetro Rpl_semi_sync_master_flow_control_current_delay executando a seguinte consulta.

SHOW GLOBAL STATUS like '%flow_control%';

O resultado deve ser semelhante ao seguinte:

+-------------------------------------------------+-------+
| Variable_name                                   | Value |
+-------------------------------------------------+-------+
| Rpl_semi_sync_master_flow_control_current_delay | 2010  |
+-------------------------------------------------+-------+
1 row in set (0.00 sec)

nota

O atraso é mostrado em microssegundos.

Quando você tem o Performance Insights ativado para um cluster de banco de dados multi-AZ do RDS para MySQL, você pode monitorar o evento de espera correspondente a uma instrução SQL indicando que as consultas foram atrasadas por um controle de fluxo. Quando um atraso foi introduzido por um controle de fluxo, você pode visualizar o evento de espera /wait/synch/cond/semisync/semi_sync_flow_control_delay_cond correspondente à instrução SQL no painel do Performance Insights. Para visualizar essas métricas, verifique se o Performance Schema está ativado. Para obter informações sobre o Performance Insights, consulte Monitorar a carga de banco de dados com o Performance Insights no Amazon RDS.

Reduzir o atraso de réplica com controle de fluxo para o RDS para PostgreSQL

Quando você está usando clusters de banco de dados do RDS para PostgreSQL multi-AZ, o controle e fluxo é implantado como uma extensão. Ela ativa um operador em segundo plano para todas as instâncias de banco de dados em um cluster de banco de dados. Por padrão, os operadores em segundo plano nas instâncias de banco de dados do leitor comunicam o atraso de réplica atual com o operador em segundo plano na instância de banco de dados do gravador. Se o atraso exceder dois minutos em qualquer instância de banco de dados do leitor, o operador em segundo plano na instância de banco de dados do gravador adicionará um atraso no final de uma transação. Para controlar o limite de atraso, use o parâmetro flow_control.target_standby_apply_lag.

Quando um controle de fluxo acelera um processo PostgreSQL, o evento de espera Extension em pg_stat_activity e o Performance Insights indicam isso. A função get_flow_control_stats exibe detalhes sobre quanto atraso está sendo adicionado no momento.

O controle de fluxo pode beneficiar a maioria das workloads de processamento de transações on-line (OLTP) que apresentam transações curtas, mas altamente simultâneas. Se o atraso for causado por transações de longa duração, como operações em lote, o controle de fluxo não proporcionará um benefício tão forte.

Você pode desativar o controle de fluxo removendo a extensão do preload_shared_libraries e reinicializando sua instância de banco de dados.

Processo de failover para clusters de banco de dados multi-AZ

Se houver uma interrupção planejada ou não planejada da sua instância de banco de dados de gravador em um cluster de banco de dados multi-AZ, o Amazon RDS fará o failover automaticamente para uma instância de banco de dados de leitor em uma zona de disponibilidade diferente. O tempo de conclusão do failover depende da atividade do banco de dados e de outras condições no momento em que a instância de banco de dados de gravador se tornou indisponível. Em geral, os tempos de failover ficam abaixo de 35 segundos. O failover será concluído quando ambas as instâncias de banco de dados de leitor tiverem aplicado transações pendentes do gravador com falha. Quando o failover é concluído, o console do RDS pode levar mais um tempo para refletir a nova zona de disponibilidade.

Failovers automáticos

O Amazon RDS processa os failovers automaticamente para que você possa retomar as operações de banco de dados o mais rápido possível e sem intervenção administrativa. Para fazer failover, a instância de banco de dados de gravador alterna automaticamente para uma instância de banco de dados de leitor.

Fazer o failover manual de cluster de banco de dados multi-AZ

Se você fizer failover de um cluster de banco de dados multi-AZ manualmente, o RDS primeiro encerrará a instância de banco de dados primária. Depois, o sistema de monitoramento interno detecta que a instância de banco de dados primária não está íntegra e promove uma instância de banco de dados de réplica legível. Em geral, os tempos de failover ficam abaixo de 35 segundos.

Você pode fazer failover de um cluster de banco de dados multi-AZ manualmente usando o AWS Management Console, a AWS CLI ou a API do RDS.

Console

Para fazer failover de um cluster de banco de dados multi-AZ manualmente

1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

2. No painel de navegação, escolha Bancos de dados.

3. Escolha o cluster de banco de dados multi-AZ do qual você deseja fazer failover.

4. Em Actions (Ações), selecione Failover.

   A página Cluster de banco de dados de failover é exibida.

5. Selecione Failover para confirmar o failover manual.

AWS CLI

Para fazer failover de um cluster de banco de dados multi-AZ manualmente, utilize o comando da AWS CLI failover-db-cluster.

aws rds failover-db-cluster --db-cluster-identifier mymultiazdbcluster

API do RDS

Para fazer failover de um cluster de banco de dados multi-AZ manualmente, chame a API FailoverDBCluster do Amazon RDS e especifique o DBClusterIdentifier.

Determinar se um cluster de banco de dados multi-AZ fez failover

Para determinar se ocorreu failover no cluster de banco de dados multi-AZ, faça o seguinte:

• Configure assinaturas de eventos de banco de dados para notificar você por e-mail ou SMS de que um failover foi iniciado. Para ter mais informações sobre eventos do , consulte Trabalhar com a notificação de eventos do Amazon RDS.

• Visualize seus eventos de banco de dados usando o console do Amazon RDS ou operações de API.

• Veja o estado atual do seu cluster de banco de dados multi-AZ utilizando o console do Amazon RDS, a AWS CLI e a API do RDS.

Para obter informações sobre como você pode responder aos failovers, reduzir o tempo de recuperação e outras melhores práticas para o Amazon RDS, consulte Práticas recomendadas do Amazon RDS.

Definir o JVM TTL para pesquisas de nome DNS

O mecanismo de failover modifica automaticamente o registro de Domain Name System (DNS) da instância de banco de dados para apontar para a instância de banco de dados de leitor. Como resultado, você precisará restabelecer todas as conexões existentes para sua instância de banco de dados. Em um ambiente de máquina virtual Java (JVM), devido à forma como o mecanismo de cache DNS do Java funciona, talvez seja necessário reconfigurar as configurações da JVM.

A JVM armazena em cache pesquisas de nome DNS. Ao resolver um nome de host para um endereço IP, a JVM armazena em cache o endereço IP por um período especificado, conhecido como Time-To-Live (TTL – Vida útil).

Como os recursos AWS usam entradas de nome DNS que acabam mudando, recomendamos configurar a JVM com um valor TTL de até 60 segundos. Isso garante que quando o endereço IP de um recurso mudar, seu aplicativo poderá receber e usar o novo endereço IP do recurso, consultando novamente o DNS.

Em algumas configurações do Java, o TTL padrão da JVM é definido de maneira que jamais atualiza entradas DNS até a JVM ser reiniciada. Por isso, se o endereço IP de um recurso AWS mudar enquanto a aplicação ainda estiver em execução, não será possível usar esse recurso até você reiniciar manualmente a JVM e as informações de IP armazenadas em cache serem atualizadas. Nesse caso, é crucial definir o TTL da JVM, de forma que ele atualize periodicamente as informações de IP armazenadas em cache.

nota

O TTL padrão pode variar de acordo com a versão da JVM e a possibilidade de um gerenciador de segurança estar instalado. Muitas JVMs oferecem um TTL padrão menor que 60 segundos. Se estiver usando uma JVM como essa, e não um gerenciador de segurança, será possível ignorar o restante deste tópico. Para ter mais informações sobre gerenciadores de segurança no Oracle, consulte The security manager (O gerenciador de segurança) na documentação do Oracle.

Para modificar o TTL da JVM, defina o valor da propriedade networkaddress.cache.ttl. Use um dos seguintes métodos, dependendo das necessidades:

• Para definir o valor da propriedade globalmente para todos os aplicativos que usam a JVM, defina networkaddress.cache.ttl no arquivo $JAVA_HOME/jre/lib/security/java.security.

  
  networkaddress.cache.ttl=60					
  				

• Para definir a propriedade localmente somente para seu aplicativo, defina networkaddress.cache.ttl no código de inicialização do aplicativo antes de quaisquer conexões de rede serem estabelecidas.

  
  java.security.Security.setProperty("networkaddress.cache.ttl" , "60");