Implantações de clusters de banco de dados multi-AZ - Amazon Relational Database Service

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 do Amazon RDS com duas instâncias de banco de dados em espera legíveis. Um cluster de banco de dados Multi-AZ tem uma instância de banco de dados de gravador e duas instâncias de banco de dados de leitor em três zonas de disponibilidade separadas na mesma região da AWS. Clusters de banco de dados Multi-AZ oferecem alta disponibilidade, maior capacidade para workloads de leitura e menor latência de gravação quando comparados com implantação de instância 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.

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. O reconhecimento de pelo menos uma instância de banco de dados de leitor é necessário para que uma alteração seja confirmada.

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.


				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.

Atualmente, os clusters de banco de dados multi-AZ estão disponíveis em algumas Regiões da AWS. Para obter informações sobre as Região da AWS compatíveis com clusters de banco de dados multi-AZ, consulte Limitações para clusters de banco de dados multi-AZ.

Criar e gerenciar um cluster de banco de dados multi-AZ

Você pode criar um cluster de banco de dados multi-AZ diretamente ou com a restauração de um snapshot. Para obter instruções, consulte estes tópicos:

Você pode modificar, reinicializar ou excluir um banco de dados multi-AZ seguindo as instruções nestes tópicos:

Você pode criar um snapshot de um cluster de banco de dados multi-AZ seguindo as instruções em Criar um snapshot de cluster de banco de dados Multi-AZ.

Você pode restaurar um cluster de banco de dados multi-AZ para um ponto anterior no tempo seguindo as instruções em Restaurar um cluster de banco de dados Multi-AZ para um horário especificado.

Gerenciar conexões para clusters de banco de dados multi-AZ

Um cluster de banco de dados Multi-AZ tem três instâncias de banco de dados em vez de uma única instância de banco de dados. Cada conexão é processada por uma instância de banco de dados específica. Quando você se conecta a um cluster de banco de dados multi-AZ, o nome do host e a porta especificados apontam para um nome de domínio totalmente qualificado chamado de endpoint. O cluster de banco de dados Multi-AZ utiliza o mecanismo de endpoint para abstrair essas conexões. Por isso, você não precisa codificar todos os nomes de host ou escrever a própria lógica para reorganizar conexões quando algumas instâncias de banco de dados não estão disponíveis.

O endpoint do gravador conecta-se à instância de banco de dados de gravador do cluster de banco de dados, que oferece suporte a operações de leitura e gravação. O endpoint leitor se conecta a qualquer uma das duas instâncias de banco de dados de leitor, que aceitam apenas operações de leitura.

Usando endpoints, você pode mapear todas as conexões para a instância de banco de dados apropriada ou o grupo de instâncias de banco de dados com base no seu caso de uso. Por exemplo, para realizar instruções DDL e DML, conecte-se à instância de banco de dados que atua como gravador. Para realizar consultas, você pode se conectar ao endpoint leitor, com o cluster de banco de dados multi-AZ gerenciando automaticamente as conexões entre as instâncias de banco de dados de leitor. Para diagnósticos ou ajustes, conecte-se a um endpoint de instância de banco de dados específico para examinar detalhes sobre uma instância de banco de dados específica.

Para saber mais sobre como se conectar à sua instância de banco de dados, consulte Conectar a uma instância de banco de dados do Amazon RDS.

Tipos de endpoints de cluster de banco de dados Multi-AZ

Um endpoint é representado por um identificador exclusivo que contém um endereço de host. Os tipos de endpoints a seguir estão disponíveis em um cluster de banco de dados Multi-AZ:

Endpoint do cluster

Um endpoint de cluster (ou endpoint de gravador) de um cluster de banco de dados Multi-AZ se conecta à instância de banco de dados de gravador atual desse cluster de banco de dados. Esse endpoint é o único capaz de realizar operações de gravação, como instruções DDL e DML. Esse endpoint também pode realizar operações de leitura.

Cada cluster de banco de dados Multi-AZ tem um único endpoint de cluster e uma única instância de banco de dados de gravador.

Use o endpoint cluster em todas as operações de gravação no cluster de banco de dados, inclusive inserções, atualizações, exclusões e alterações DDL. Você também pode usar o endpoint de cluster para operações de leitura, como consultas.

Se a instância de banco de dados de gravador atual de um cluster de banco de dados falhar, o cluster de banco de dados Multi-AZ fará failover automático para uma nova instância de banco de dados de gravador. Durante um failover, o cluster de banco de dados continua atendendo a solicitações de conexão para o endpoint de cluster pela nova instância de banco de dados de gravador, com interrupção mínima de serviço.

O exemplo a seguir ilustra um endpoint de cluster para um cluster de banco de dados Multi-AZ.

mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com

Endpoint de leitor

Um endpoint leitor de um cluster de banco de dados multi-AZ é compatível com balanceamento de carga para conexões somente leitura com o cluster de banco de dados. Use o endpoint do leitor para operações de leitura, como consultas. Ao processar essas instruções nas instâncias de banco de dados de leitor, esse endpoint reduz a sobrecarga na instância de banco de dados de gravador. Ele também ajuda o cluster a escalar a capacidade de processar consultas SELECT simultâneas. Cada cluster de banco de dados Multi-AZ tem um único endpoint de leitor.

O endpoint leitor envia cada solicitação de conexão para uma das instâncias de banco de dados de leitor. Quando você usa o endpoint de leitor para uma sessão, apenas é possível executar instruções somente leitura, como SELECT, nessa sessão.

O exemplo a seguir ilustra um endpoint de leitor para um cluster de banco de dados Multi-AZ.

mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com

Endpoint da instância

Um endpoint de instância conecta-se a uma instância de banco de dados específica dentro de um cluster de banco de dados Multi-AZ. Cada instância de banco de dados em um cluster de banco de dados, tem o próprio endpoint de instância exclusivo. Portanto, há um endpoint de instância para a instância de banco de dados de gravador atual do cluster de banco de dados e há um endpoint de instância para cada uma das instâncias de banco de dados de leitor no cluster de banco de dados.

O endpoint de instância oferece controle direto sobre as conexões com o cluster de banco de dados. Esse controle pode ajudar a resolver cenários nos quais talvez não seja apropriado utilizar o endpoint de cluster ou o endpoint de leitor. Por exemplo, o aplicativo cliente pode exigir um balanceamento de carga mais refinado com base no tipo de workload. Nesse caso, é possível configurar vários clientes para se conectarem a instâncias de banco de dados diferentes em um cluster de banco de dados com o objetivo de distribuir workloads de leitura.

O exemplo a seguir ilustra um endpoint de instância para uma instância de banco de dados em um cluster de banco de dados Multi-AZ.

mydbinstance.123456789012.us-east-1.rds.amazonaws.com

Visualizar os endpoints de um cluster de banco de dados Multi-AZ

No AWS Management Console, você vê o endpoint de cluster e o endpoint de leitor na página de detalhes de cada cluster de banco de dados Multi-AZ. Você vê o endpoint de instância na página de detalhes de cada instância de banco de dados.

Com a AWS CLI, você vê os endpoints de gravador e leitor na saída do comando describe-db-clusters. Por exemplo, o comando a seguir mostra os atributos de endpoint para todos os clusters na região atual da AWS.

aws rds describe-db-cluster-endpoints

Com a API do Amazon RDS, você recupera os endpoints chamando a função DescribeDBClusterEndpoints. Essa saída também mostra endpoints de cluster de bancos de dados Amazon Aurora, se houver.

Usar o endpoint de cluster

Cada cluster de banco de dados Multi-AZ tem um único endpoint de cluster integrado, cujo nome e outros atributos são gerenciados pelo Amazon RDS. Não crie, exclua nem modifique esse tipo de endpoint.

Use o endpoint de cluster ao administrar seu cluster de banco de dados, realizar operações Extract, Transform, Load (ETL – Extração, transformação, carregamento) ou desenvolver e testar aplicações. O endpoint de cluster conecta-se à instância de banco de dados de gravador do cluster. A instância de banco de dados de gravador é a única em que você cria tabelas e índices, executa instruções INSERT e realiza outras operações DDL e DML.

O endereço IP físico apontado pelo endpoint de cluster muda quando o mecanismo de failover promove uma nova instância de banco de dados como a instância de banco de dados de gravador do cluster. Caso você use alguma forma de agrupamento de conexões ou outra multiplexação, prepare-se para enviar ou reduzir a vida útil para todas as informações DNS armazenadas em cache. Isso garante que você não tente estabelecer uma conexão de leitura/gravação com uma instância de banco de dados que fique indisponível ou seja somente leitura após um failover.

Usar o endpoint de leitor

Use o endpoint de leitor em conexões somente leitura com o seu cluster de banco de dados Multi-AZ. Esse endpoint ajuda o cluster de banco de dados a lidar com uma workload com uso intensivo de consulta. O endpoint leitor é o endpoint fornecido para aplicações que geram relatórios ou fazem outra operações somente leitura sobre o cluster. O endpoint leitor envia as conexões para instâncias de banco de dados de leitor disponíveis em um cluster de banco de dados multi-AZ.

Cada cluster Multi-AZ tem um único endpoint de leitor integrado, cujo nome e outros atributos são gerenciados pelo Amazon RDS. Não crie, exclua nem modifique esse tipo de endpoint.

Usar os endpoints de instância

Cada instância de banco de dados em um cluster de banco de dados Multi-AZ tem seu próprio endpoint de instância integrado, cujo nome e outros atributos são gerenciados pelo Amazon RDS. Não crie, exclua nem modifique esse tipo de endpoint. Com um cluster de banco de dados Multi-AZ, você normalmente usa os endpoints de gravador e leitor com mais frequência do que os endpoints de instância.

Nas operações diárias, a principal maneira de usar endpoints de instância é diagnosticar problemas de capacidade ou performance que afetam uma instância de banco de dados específica em um cluster de banco de dados Multi-AZ. Conectado a uma instância de banco de dados específica, examine as variáveis de status, as métricas etc. Fazer isso pode ajudar a determinar o que está acontecendo nessa instância de banco de dados diferente do que está acontecendo com outras instâncias de banco de dados no cluster.

Como os endpoints de banco de dados Multi-AZ funcionam com alta disponibilidade

Para clusters de banco de dados Multi-AZ em que a alta disponibilidade é importante, utilize o endpoint de gravador para conexões de leitura/gravação ou de uso geral e o endpoint de leitor para conexões somente leitura. Os endpoints de leitor e de gravador gerenciam o failover da instância de banco de dados melhor do que os endpoints de instância. Ao contrário dos endpoints de instância, os endpoints de leitor e de gravador alteram automaticamente a qual instância de banco de dados eles se conectam caso uma instância de banco de dados no cluster fique indisponível.

Se a instância de banco de dados de gravador de um cluster de banco de dados falhar, o Amazon RDS fará failover automaticamente para uma nova instância de banco de dados de gravador. Ele faz isso promovendo uma instância de banco de dados do leitor para uma nova instância de banco de dados de gravador. Se ocorrer um failover, será possível utilizar o endpoint de gravador para se reconectar à instância de banco de dados de gravador recém-promovida. Ou você pode usar o endpoint de leitor para se reconectar a uma das instâncias de banco de dados de leitor no cluster de banco de dados. Durante um failover, o endpoint de leitor pode direcionar conexões à nova instância de banco de dados de gravador de um cluster de banco de dados por um curto período depois que uma instância de banco de dados de leitor é promovida para a nova instância de banco de dados de gravador. Se você projeta sua própria lógica de aplicação para gerenciar conexões de endpoint de instância, poderá descobrir manual ou programaticamente o conjunto resultante de instâncias de banco de dados disponíveis no cluster de banco de dados.

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.


				Cluster de banco de dados Multi-AZ no AWS Management 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.


				Ações de cluster de banco de dados Multi-AZ no AWS Management Console

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.


				Ações de instância de banco de dados em um cluster de banco de dados Multi-AZ no AWS Management Console

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.

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 obter 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 for 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 for 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 for MySQL e RDS for 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 for MySQL e o RDS for PostgreSQL.

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

Quando você está usando clusters de banco de dados multi-AZ do RDS for 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 superior 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 acelera as 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 para seu valor máximo de 86400 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 será semelhante ao mostrado a seguir.

+-------------------------------------------------+-------+ | 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 for 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 do banco de dados com o Performance Insights no Amazon RDS.

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

Quando você está usando clusters de banco de dados do RDS for 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 dos workloads de processamento de transações online (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

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.

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 Databases (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 Failover DB Cluster (Fazer failover do cluster de banco de dados) é exibida.

  5. Selecione Failover para confirmar o failover manual.

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

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

Limitações para clusters de banco de dados multi-AZ

As seguintes limitações se aplicam aos clusters de banco de dados multi-AZ:

  • É possível criar um cluster de banco de dados multi-AZ somente com o MySQL versão 8.0.28 e versões 8.0 posteriores, além do PostgreSQL versão 13.4.

  • Você pode criar clusters de banco de dados Multi-AZ somente nas seguintes regiões da AWS:

    • Leste dos EUA (Ohio)

    • Leste dos EUA (Norte da Virgínia)

    • Oeste dos EUA (Oregon)

    • Ásia-Pacífico (Cingapura)

    • Asia Pacific (Sydney)

    • Ásia-Pacífico (Tóquio)

    • Europa (Irlanda)

  • Clusters de banco de dados Multi-AZ oferecem suporte apenas ao armazenamento de IOPS provisionadas.

  • Você não pode alterar uma implantação de instância de banco de dados Single-AZ ou Multi-AZ em um cluster de banco de dados Multi-AZ. Como alternativa, você pode restaurar um snapshot de uma implantação de instância de banco de dados Single-AZ ou implantação de instância de banco de dados Multi-AZ para um cluster de banco de dados Multi-AZ.

  • Não é possível restaurar um snapshot de cluster de banco de dados Multi-AZ para uma implantação de instância de banco de dados Multi-AZ ou implantação Single-AZ.

  • Os clusters de banco de dados Multi-AZ não oferecem suporte para modificações no nível da instância de banco de dados porque todas as modificações são feitas no nível do cluster de banco de dados.

  • Clusters de banco de dados Multi-AZ não são compatíveis com os seguintes recursos:

    • Proxy do Amazon RDS

    • AWS Backup

    • AWS CloudFormation

    • Exportar de dados de snapshot de cluster de banco de dados Multi-AZ para um bucket do Amazon S3

    • IAM DB authentication

    • Autenticação de Kerberos

    • Integração com o AWS Secrets Manager

    • Modificar a porta

      Como alternativa, você pode restaurar um cluster de banco de dados Multi-AZ para um ponto no tempo e especificar uma porta diferente.

    • Grupos de opções

    • Réplicas de leitura

    • Instâncias de bancos de dados reservadas

    • Restaurar um snapshot de cluster de banco de dados Multi-AZ a partir de um bucket do Amazon S3

    • Escalabilidade automática do armazenamento definindo o armazenamento máximo alocado

      Como alternativa, é possível escalar o armazenamento manualmente.

    • Interromper e iniciar o cluster de banco de dados

  • Os clusters de banco de dados Multi-AZ do RDS for MySQL não oferecem suporte para replicação para um banco de dados de destino externo.

  • Os clusters de banco de dados do RDS for MySQL multi-AZ são compatíveis apenas com os seguintes procedimentos armazenados no sistema:

    • mysql.rds_rotate_general_log

    • mysql.rds_rotate_slow_log

    • mysql.rds_show_configuration

    Os clusters de banco de dados do RDS for MySQL multi-AZ não são compatíveis com outros procedimentos armazenados no sistema. Para obter informações sobre esses procedimentos, consulte MySQL em referência de SQL do Amazon RDS.

  • Os clusters de banco de dados Multi-AZ do RDS for PostgreSQL não oferecem suporte às seguintes extensões PostgreSQL: aws_s3, pg_transport e pglogical.

  • Os clusters de banco de dados Multi-AZ do RDS para PostgreSQL não oferecem suporte ao uso de um servidor DNS personalizado para acesso à rede de saída.

  • Os clusters de banco de dados Multi-AZ do RDS para PostgreSQL não oferecem suporte para replicação lógica.