PolarDB:Três data centers em duas regiões

Mecanismo de eleição ponderada

O PolarDB-X aplica um mecanismo de eleição ponderada para que as reeleições de líder prefiram réplicas no mesmo data center e evitem latência desnecessária entre regiões.

Pesos de eleição das réplicas:

Esse mecanismo tem duas partes:

• Eleição ponderada otimista: Cada nó aguarda um atraso calculado antes de iniciar uma eleição de líder. O atraso é inversamente proporcional ao peso do nó; portanto, nós com maior peso iniciam as eleições primeiro.

• Eleição ponderada obrigatória: Quando um novo líder detecta que não possui o maior peso entre todos os nós, ele entra em uma fase de abdicação em vez de aceitar gravações imediatamente. Durante essa fase, o nó envia sinais de heartbeat (por exemplo, a cada 1 ou 2 segundos). Se um nó com peso maior responder antes do fim da fase de abdicação, a liderança será transferida para esse nó.

Por exemplo, se o líder no Data Center Primário 1 falhar, o follower no mesmo data center (peso 7) terá prioridade sobre todos os outros e manterá o tráfego local.

Ajuste dinâmico da quantidade de réplicas

Quando um data center primário falha e restam apenas três réplicas, a sincronização por maioria deve incluir a réplica do data center secundário, o que adiciona aproximadamente 30 milissegundos de latência entre regiões. Utilize os comandos a seguir para ajustar a quantidade de réplicas e gerenciar essa compensação:

Inicialização forçada de réplica única

Se ambos os data centers primários falharem, a única réplica restante no data center secundário não conseguirá atender sozinha ao requisito de consenso majoritário. Execute force_single_mode para forçar o sistema a entrar no modo de réplica única e colocar todas as réplicas follower em segundo plano, permitindo que a réplica restante atenda às solicitações.

Após a recuperação dos data centers primários, o PolarDB-X reconstrói o sistema distribuído de forma incremental:

1. Adicione réplicas de uma para três: execute add_follower.

2. Adicione réplicas de três para cinco: execute upgrade_learner.

Instância secundária remota

Em sistemas de banco de dados distribuídos, o progresso da replicação pode variar entre grupos Paxos durante uma transação distribuída. Sem coordenação, dados de uma transação parcialmente replicada poderiam aparecer na instância secundária e causar inconsistência transacional.

O PolarDB-X resolve isso usando nós de log de Change Data Capture (CDC) implantados na região remota. Esses nós classificam e reorganizam as transações distribuídas para garantir replicação atômica: nenhuma transação é confirmada parcialmente quando os dados são movidos da instância primária para a secundária. Essa garantia vale tanto para testes rotineiros de recuperação de desastres quanto para failovers reais.

Dois pontos de projeto regem o funcionamento da replicação e do failover:

• Replicação da instância primária: A instância primária usa o protocolo Paxos entre regiões e exige respostas de pelo menos três réplicas. Como quatro réplicas estão nos data centers primários, a sincronização por maioria normalmente é concluída localmente. A réplica remota no data center secundário responde de forma assíncrona; portanto, a latência entre regiões não afeta o desempenho de gravação da instância primária.

• Replicação da instância secundária: A instância secundária está na região remota. Os nós de log CDC replicam dados quase em tempo real entre as regiões. Pode haver latência de replicação, mas a replicação atômica de transações garante que a instância secundária nunca reflita uma transação parcialmente confirmada.

Referência rápida: cenário para comando

Crie uma instância com esta topologia

Ao criar uma instância do PolarDB-X, defina o parâmetro Topology como Three Data Centers Across Two Regions.

Visualize a topologia da instância

Na página Basic Information da instância, localize a seção Topology Information para ver os detalhes de zona de todos os recursos.

Executar um failover