Implantações de cluster de banco de dados multi-AZ para o Amazon RDS

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 Regiões e mecanismos de banco de dados compatíveis com clusters de banco de dados multi-AZ no Amazon RDS.

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, db.m6id, db.m6idn, db.r5d, db.r6gd, db.x2iedn, db.r6id, db.r6idn e db.c6gd.

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

Arquitetura de cluster 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.

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 de clusters de banco de dados multi-AZ.

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 do cluster de banco de dados multi-AZ para o Amazon RDS.

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:

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)

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 shared_preload_libraries e reinicializando sua instância de banco de dados.

Snapshots de cluster de banco de dados multi-AZ

O Amazon RDS cria e salva backups automáticos do cluster de banco de dados multi-AZ durante a janela de backup configurada. O RDS cria um snapshot do volume de armazenamento do cluster de banco de dados fazendo backup de todo o cluster e não apenas das instâncias individuais.

Também é possível fazer backups manuais do cluster de banco de dados multi-AZ. Para backups de prazo muito longo, pense em exportar dados de snapshot para o Amazon S3. Para ter mais informações, consulte Criar um snapshot do cluster de banco de dados multi-AZ para o Amazon RDS.

É possível restaurar seu cluster de banco de dados multi-AZ para um momento específico criando um cluster de banco de dados multi-AZ. Para obter instruções, consulte Restaurar um cluster de banco de dados multi-AZ para um horário especificado.

Também é possível restaurar um snapshot de cluster de banco de dados multi-AZ para uma implantação single-AZ ou uma implantação de instância de banco de dados multi-AZ. Para obter instruções, consulte Restauração de um snapshot de cluster de banco de dados multi-AZ para uma instância de banco de dados.