# 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. **Topics** + [Limitações dos clusters ativos-ativos do RDS para MySQL](#mysql-active-active-clusters-limitations) + [Considerações e práticas recomendadas para cluster ativo-ativo do RDS para MySQL](#mysql-active-active-clusters-considerations) ## 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](USER_ReadRepl.Monitoring.md). + As implantações azul/verde não são compatíveis com instâncias de banco de dados em um cluster ativo-ativo. Para obter mais informações, consulte [Usar implantações azul/verde do Amazon RDS para atualizações de banco de dados](blue-green-deployments.md). + A autenticação Kerberos não é compatível com instâncias de banco de dados em um cluster ativo-ativo. Para obter mais informações, consulte [Uso da autenticação do Kerberos para o Amazon RDS para MySQL](mysql-kerberos.md). + 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 obter mais informações, consulte [Configurar e gerenciar uma implantação multi-AZ para o Amazon RDS](Concepts.MultiAZ.md). + 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 obter mais informações, consulte [Implantações de cluster de banco de dados multi-AZ para o Amazon RDS](multi-az-db-clusters-concepts.md). + 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](https://dev.mysql.com/doc/refman/8.0/en/group-replication-consistency-guarantees.html) 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](https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html) 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](https://dev.mysql.com/doc/refman/8.0/en/group-replication-fault-tolerance.html) 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](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only). + É 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](USER_UpgradeDBInstance.MySQL.md). + É 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](Concepts.MultiAZSingleStandby.md). + 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 obter mais informações, consulte [Janela de manutenção do Amazon RDS](USER_UpgradeDBInstance.Maintenance.md#Concepts.DBMaintenance). + 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\$1replication\$1recovery\$1use\$1ssl](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_recovery_use_ssl) e [ group\$1replication\$1ssl\$1mode](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_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\$1replication\$1ssl\$1mode](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_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\$1replication\$1enforce\$1update\$1everywhere\$1checks é e o parâmetro](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_enforce_update_everywhere_checks) é `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](https://dev.mysql.com/doc/refman/8.0/en/group-replication-connection-security.html) 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 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](mysql-active-active-clusters-adding.md#mysql-active-active-clusters-adding-pitr). + É 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](USER_DeleteInstance.md). + Quando uma instância de banco de dados deixa acidentalmente um cluster ativo-ativo, por padrão, o parâmetro `group_replication_exit_state_action` é alterado para `OFFLINE_MODE`. Nesse estado, a instância de banco de dados fica inacessível e você deve reinicializá-la para colocá-la novamente online e para que ela volte a fazer parte do cluster. Você pode alterar esse comportamento modificando o parâmetro `group_replication_exit_state_action` em um grupo de parâmetros personalizado. Ao definir o parâmetro como `READ_ONLY`, quando a instância de banco de dados sai acidentalmente de um cluster, ela entra em um super estado de somente leitura em vez de ficar offline.