Limitações e considerações sobre cluster ativo-ativo - Amazon Relational Database Service

Limitações e considerações sobre cluster ativo-ativo

O clusters ativo-ativo no Amazon RDS oferece maior disponibilidade e escalabilidade ao distribuir workloads em várias instâncias. No entanto, há limitações e considerações importantes a saber ao usar essa arquitetura.

As seções a seguir descrevem os principais fatores, como atrasos na replicação, resolução de conflitos, alocação de recursos e comportamento de failover. Compreender essas considerações pode ajudar a garantir o desempenho e a confiabilidade ideais em implantações de cluster ativo-ativo.

Limitações dos clusters ativos-ativos do RDS para MySQL

As seguintes limitações se aplicam a clusters ativos-ativos do RDS para MySQL:

  • O nome de usuário principal não pode ser rdsgrprepladmin para instâncias de banco de dados em um cluster ativo-ativo. Esse nome de usuário é reservado para conexões da Group Replication.

  • Para instâncias de banco de dados com réplicas de leitura em clusters ativos-ativos, um status de replicação prolongado diferente de Replicating pode fazer com que os arquivos de log excedam os limites de armazenamento. Para ter informações sobre o status de réplicas de leitura, consulte Monitoramento da replicação de leitura.

  • As implantações azul/verde não são compatíveis com instâncias de banco de dados em um cluster ativo-ativo. Para ter mais informações, consulte Usar implantações azul/verde do Amazon RDS para atualizações de banco de dados.

  • A autenticação Kerberos não é compatível com instâncias de banco de dados em um cluster ativo-ativo. Para ter mais informações, consulte Usar a autenticação Kerberos do Amazon RDS para Microsoft SQL Server.

  • As instâncias de banco de dados em um cluster de banco de dados multi-AZ não podem ser adicionadas a um cluster ativo-ativo. No entanto, as instâncias de banco de dados em uma implantação de instância de banco de dados multi-AZ podem ser adicionadas a um cluster ativo-ativo. Para ter mais informações, consulte Configurar e gerenciar uma implantação multi-AZ para o Amazon RDS.

  • As tabelas que não têm uma chave primária não são replicadas em um cluster ativo-ativo porque as gravações são rejeitadas pelo plug-in Group Replication.

  • As tabelas que não são do InnoDB não são replicadas em um cluster ativo-ativo.

  • Clusters ativos-ativos não comportam declarações DML e DDL simultâneas em diferentes instâncias de banco de dados no cluster.

  • Não é possível configurar um cluster ativo-ativo para usar o modo primário único para o modo de replicação do grupo. Para essa configuração, recomendamos usar um cluster de banco de dados multi-AZ. Para ter mais informações, consulte Implantações de cluster de banco de dados multi-AZ para o Amazon RDS.

  • A replicação de várias fontes não é compatível com instâncias de banco de dados em um cluster ativo-ativo.

  • Um cluster ativo-ativo entre regiões não pode impor a verificação da autoridade de certificação (CA) para conexões da Group Replication.

Considerações e práticas recomendadas para cluster ativo-ativo do RDS para MySQL

Antes de usar clusters ativos-ativos do RDS para MySQL, analise as seguintes considerações e práticas recomendadas:

  • Os clusters ativos-ativos não podem ter mais de nove instâncias de banco de dados.

  • Com o plug-in Group Replication, é possível controlar as garantias de consistência da transação do cluster ativo-ativo. Para ter mais informações, consulte Transaction Consistency Guarantees na documentação do MySQL.

  • Conflitos são possíveis quando diferentes instâncias de banco de dados atualizam a mesma linha em um cluster ativo-ativo. Para ter informações sobre conflitos e sua resolução, consulte Group Replication na documentação do MySQL.

  • Para tolerância a falhas, inclua pelo menos três instâncias de banco de dados no cluster ativo-ativo. É possível configurar um cluster ativo-ativo com apenas uma ou duas instâncias de banco de dados, mas o cluster não tolerará falhas. Para ter informações sobre tolerância a falhas, consulte Fault -tolerance na documentação do MySQL.

  • Quando uma instância de banco de dados ingressa em um cluster ativo-ativo existente e está executando a mesma versão que a mais baixa do mecanismo no cluster, a instância de banco de dados ingressa no modo de leitura-gravação.

  • Quando uma instância de banco de dados ingressa em um cluster ativo-ativo existente e está executando uma versão mais alta do que a mais do mecanismo no cluster, a instância de banco de dados deve permanecer no modo de leitura-gravação.

  • Se você habilitar a Group Replication para uma instância de banco de dados definindo o parâmetro rds.group_replication_enabled como 1 no grupo de parâmetros do banco de dados, mas a replicação não foi iniciada ou falhou ao iniciar, a instância de banco de dados será colocada no modo de superleitura para evitar inconsistências de dados. Para ter informações sobre o modo superleitura, consulte a documentação do MySQL.

  • É possível atualizar uma instância de banco de dados em um cluster ativo-ativo, mas a instância de banco de dados é somente leitura até que todas as outras instâncias de banco de dados no cluster ativo-ativo sejam atualizadas para a mesma versão do mecanismo ou uma versão superior. Quando você atualiza uma instância de banco de dados, a instância de banco de dados ingressa automaticamente no mesmo cluster ativo-ativo quando a atualização é concluída. Para evitar uma mudança não intencional para o modo somente leitura de uma instância de banco de dados, desabilite as atualizações automáticas de versões secundárias para ela. Para ter mais informações sobre como atualizar uma instância de banco de dados MySQL, consulte Atualizações do mecanismo de banco de dados do RDS para MySQL.

  • É possível adicionar uma instância de banco de dados em uma implantação de instância de banco de dados multi-AZ para um cluster ativo-ativo existente. Também é possível converter uma instância de banco de dados single-AZ em um cluster ativo-ativo em uma implantação de instância de banco de dados multi-AZ. Se uma instância de banco de dados primária em uma implantação multi-AZ falhar, essa instância primária fará o failover para a instância em espera. A nova instância de banco de dados primária ingressa automaticamente no mesmo cluster após a conclusão do failover. Para ter mais informações sobre implantações de instâncias de banco de dados multi-AZ, consulte Implantações de instâncias de banco de dados multi-AZ para o Amazon RDS.

  • Recomendamos que as instâncias de banco de dados em um cluster ativo-ativo tenham intervalos de tempo diferentes para as janelas de manutenção. Essa prática evita que várias instâncias de banco de dados no cluster fiquem off-line para manutenção ao mesmo tempo. Para ter mais informações, consulte A janela de manutenção do Amazon RDS.

  • Clusters ativos-ativos podem usar SSL para conexões entre instâncias de banco de dados. Para configurar conexões SSL, defina os parâmetros group_replication_recovery_use_ssl e group_replication_ssl_mode. Os valores desses parâmetros devem coincidir em todas as instâncias de banco de dados no cluster ativo-ativo.

    Atualmente, os clusters ativos-ativos não comportam a verificação de autoridade de certificação (CA) para conexões entre Regiões da AWS. Portanto, o parâmetro group_replication_ssl_mode deve ser definido como DISABLED (o padrão) ou como REQUIRED para clusters entre regiões.

  • Um cluster ativo-ativo do RDS para MySQL é executado no modo multiprimário. O valor padrão de group_replication_enforce_update_everywhere_checks é e o parâmetro é ON e o parâmetro é estático. Quando esse parâmetro é definido como ON, as aplicações não podem ser inseridas em uma tabela que tenha restrições de chave externa em cascata.

  • Um cluster ativo do RDS para MySQL usa a pilha de comunicação MySQL para segurança de conexão em vez de XCOM. Para ter mais informações, consulte Communication Stack for Connection Security Management na documentação do MySQL.

  • Quando um grupo de parâmetros de banco de dados está associado a uma instância de banco de dados em um cluster ativo-ativo, recomendamos associar esse grupo de parâmetros de banco de dados somente a outras instâncias de banco de dados que estejam no cluster.

  • Os clusters ativos-ativos são compatíveis somente com instâncias de banco de dados do RDS para MySQL. Essas instâncias de banco de dados devem estar executando versões compatíveis do mecanismo de banco de dados.

  • Quando uma instância de banco de dados em um cluster ativo-ativo sofre uma falha inesperada, o RDS inicia a recuperação dela automaticamente. Se a instância de banco de dados não se recuperar, recomendamos substituí-la por uma nova instância de banco de dados executando uma recuperação pontual com uma instância de banco de dados íntegra no cluster. Para obter instruções, consulte Adicionar uma instância de banco de dados a um cluster ativo-ativo usando a recuperação para um ponto no tempo.

  • É possível excluir uma instância de banco de dados em um cluster ativo-ativo sem afetar as outras instâncias de banco de dados no cluster. Para obter informações sobre como excluir uma instância de banco de dados, consulte Excluir uma instância de banco de dados.