ApsaraDB RDS:Use the MGR mode

Por que usar o MGR

O MGR utiliza o protocolo Paxos para manter todos os nós sincronizados, conferindo ao seu cluster RDS três propriedades que a replicação assíncrona e semissíncrona não conseguem garantir:

• Consistência forte de dados — se o nó primário falhar, o cluster o remove automaticamente e promove um nó secundário. Os dados no novo primário são consistentes com aqueles que o nó com falha havia confirmado.

• Alta confiabilidade dos dados — uma transação no primário só é confirmada após a maioria (mais da metade) dos nós secundários confirmar o recebimento dos dados, o que evita perdas.

• Consistência global de transações configurável — o parâmetro group_replication_consistency permite ajustar a consistência de leitura e escrita por sessão, conforme as necessidades da sua carga de trabalho.

O MGR oferece throughput menor que a replicação assíncrona e consome mais memória do que os modos assíncrono e semissíncrono. Teste cargas de trabalho sensíveis a desempenho ou com restrições de memória antes de migrar para o MGR.

Pré-requisitos

Antes de começar, verifique se o seu cluster RDS atende a todos os requisitos abaixo. Visualize a edição do RDS, a versão principal do mecanismo e o tipo de instância na página Basic Information do cluster no console ApsaraDB RDS.

Para fazer upgrade da RDS High-availability Edition para a RDS Cluster Edition, consulte Fazer upgrade da edição do RDS da RDS High-availability Edition para a RDS Cluster Edition . Para atualizar a versão secundária do mecanismo, consulte Atualizar a versão secundária do mecanismo . Para atualizar a versão do proxy de banco de dados, consulte Atualizar a versão do proxy de banco de dados . Para alterar as especificações da instância, consulte Alterar especificações da instância .

Limitações

Não é possível ativar o MGR se o cluster contiver tabelas X-Engine ou tabelas sem chaves primárias. Execute as consultas a seguir para verificar.

Verificar tabelas X-Engine — um resultado igual a 0 indica que não existem tabelas X-Engine:

SELECT
  COUNT(1)
FROM
  information_schema.TABLES
WHERE
  ENGINE = 'xengine'
  AND table_schema NOT IN(
    'information_schema', 'performance_schema',
    'mysql', 'test', 'sys', '__recycle_bin__'
  );

Verificar tabelas sem chaves primárias — um resultado igual a 0 indica que todas as tabelas possuem chaves primárias:

SELECT
  COUNT(1) AS count
FROM
  information_schema.TABLES t1
  LEFT OUTER JOIN information_schema.columns t2 ON t1.table_schema = t2.TABLE_SCHEMA
  AND t1.table_name = t2.TABLE_NAME
  AND t2.COLUMN_KEY = 'PRI'
WHERE
  t2.table_name IS NULL
  AND t1.table_type = 'BASE TABLE'
  AND t1.TABLE_SCHEMA NOT IN(
    'information_schema', 'performance_schema',
    'mysql', 'sys'
  );

Para obter a lista completa de requisitos e limitações do MySQL Group Replication, consulte Requirements and Limitations na documentação do MySQL.

Impactos

A alteração da replicação assíncrona ou semissíncrona para o MGR aciona um switchover de instância. Realize essa mudança em horários de baixa demanda e certifique-se de que sua aplicação esteja configurada para reconectar automaticamente. Para detalhes sobre o que ocorre durante um switchover, consulte Impactos de um switchover de instância.

Faturamento

O MGR está disponível sem custo adicional.

Ativar o MGR

Observações de uso

gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
binlog_format=ROW
binlog_transaction_dependency_tracking=WRITESET
transaction_write_set_extraction=XXHASH64
master_info_repository=TABLE
relay_log_info_repository=TABLE

slave_preserve_commit_order=ON
slave_parallel_type=LOGICAL_CLOCK
rpl_semi_sync_master_enabled=OFF
rpl_semi_sync_slave_enabled=OFF

disabled_storage_engines=MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY,XENGINE
replication_communication_stack=MYSQL
group_replication_single_primary_mode=ON
group_replication_paxos_single_leader=ON
group_replication_consistency=BEFORE_ON_PRIMARY_FAILOVER

Perguntas frequentes

É possível reverter do MGR para a replicação assíncrona ou semissíncrona?

Sim. Na página Basic Information, clique em Change Data Replication Mode na seção Instance Topology Management e selecione o modo desejado. A alternância é bidirecional entre os modos assíncrono, semissíncrono e MGR.

Os nós secundários podem atender a solicitações de leitura no modo MGR?

Sim. No entanto, se os nós secundários estiverem sobrecarregados, o desempenho de escrita no primário será degradado. Ative o recurso de proxy de banco de dados com divisão de leitura/escrita para distribuir as leituras entre os secundários, controlando a latência de replicação e os pesos de leitura. Isso evita que os nós secundários se tornem um gargalo.

O MGR suporta o modo multi-primary?

Não. O MGR no ApsaraDB RDS for MySQL suporta apenas o modo single-primary. O modo multi-primary introduz instabilidade: qualquer oscilação ou falha em um único nó afeta a disponibilidade de todo o cluster.

Por que o MGR exige pelo menos 8 GB de memória?

O MGR adiciona três fontes de consumo de memória além do que a replicação normal utiliza:

• A camada de comunicação XCom mantém um cache de mensagens de aproximadamente 1 GB.

• O módulo de certificação de transações mantém um array de informações de certificação na memória.

• Threads adicionais em segundo plano executam tarefas de gerenciamento de grupo.

Em instâncias com menos de 8 GB de memória, cargas de trabalho pesadas (como grandes picos de consultas paralelas) podem exaurir a memória disponível e gerar um erro de out-of-memory (OOM).

Devo escolher uma instância de uso geral ou dedicada para o MGR?

• Memória de 8 a 16 GB: Utilize uma instância de uso geral. Os recursos físicos compartilhados oferecem aos processos do MGR mais flexibilidade para usar memória que outros locatários não estão consumindo.

• 32 GB ou mais: Opte por uma instância dedicada para obter isolamento de recursos mais forte e desempenho de pico mais previsível.

Referência da API

Próximos passos

• Introdução ao modo MGR — como o MGR funciona internamente

• Impactos de um switchover de instância — o que acontece com as conexões e os dados durante um switchover