Múltiplas réplicas Paxos - PolarDB: Central de Documentação do Alibaba Cloud

As configurações tradicionais de alta disponibilidade (HA) ativa/standby exigem intervenção manual durante failovers e não garantem perda zero de dados. O PolarDB-X Standard Edition substitui esse modelo por uma arquitetura de múltiplas réplicas baseada em Paxos, que oferece Recovery Point Objective (RPO) zero e alternância automática de HA em todos os modos de implantação.

Modos de implantação

O PolarDB-X oferece três modos de implantação para atender a diferentes requisitos de disponibilidade e recuperação de desastres.

Modo de implantação	Descrição
Zona única	Implante todos os nós em uma única zona. Adequado para desenvolvimento, testes ou cargas de trabalho que toleram interrupções no nível da zona.
Três zonas	Distribua os nós por três zonas dentro de uma região. Adequado para cargas de produção que exigem redundância no nível da zona.
Três data centers em duas regiões	Distribua os nós por três data centers em duas regiões. Adequado para sistemas críticos que exigem recuperação de desastres entre regiões.

Os três modos utilizam o consenso Paxos para garantir RPO zero. Escolha o modo com base no escopo de recuperação de desastres e na topologia de rede.

Como funciona

p7947931

Quando um nó falha em um cluster de banco de dados com vários nós, surgem dois problemas: as operações de escrita em andamento podem ser perdidas e o cluster precisa eleger um novo líder sem intervenção humana. O Paxos, algoritmo de consenso, resolve ambas as questões ao exigir que a maioria dos nós confirme cada operação de escrita antes do commit e ao automatizar a eleição do líder por meio de um mecanismo de heartbeat e timeout.

Um cluster do PolarDB-X Standard Edition opera no modelo de líder único:

Nó líder: Único nó que aceita operações de escrita. Adiciona eventos de consenso ao protocolo de log binário antes de propagar as entradas de log para os seguidores.
Nós seguidores: Participam da votação por maioria e sincronizam os dados. Em vez de usar o relay log tradicional do MySQL, utilizam logs de consenso Paxos, que integram o conteúdo do log binário do MySQL. A thread SQL reproduz esses logs nos arquivos de dados.

Eleição de líder: Quando os nós seguidores detectam a indisponibilidade do líder, elegem automaticamente um novo líder. O novo líder não atende ao tráfego até que a thread SQL termine de reproduzir todos os logs existentes nos arquivos de dados, garantindo a consistência antes de retomar as escritas.

Benefícios

Benefício	Como funciona
RPO zero	O mecanismo de sincronização baseado em maioria garante que cada escrita confirmada seja reconhecida por um quórum de nós antes da conclusão bem-sucedida. Nenhum dado confirmado é perdido durante o failover.
HA automática	Os nós seguidores monitoram continuamente o líder via heartbeat. Em caso de falha, elegem um novo líder sem intervenção manual, substituindo o modelo tradicional de HA ativa/standby.
Alto desempenho	O modelo de escrita com líder único oferece desempenho comparável à replicação semissíncrona do MySQL, com a garantia adicional de perda zero de dados.

Dica: Para melhorar a eficiência da eleição de líder durante um failover entre data centers, defina valores mais altos de ELECTION_WEIGHT para as réplicas no mesmo data center e aumente suas chances de vencer a eleição.

Monitorar status das réplicas

Três views do sistema permitem inspecionar o cluster Paxos com diferentes níveis de detalhe.

Consultar informações globais das réplicas

Retorna o status de todas as réplicas no cluster. Apenas o nó líder retorna resultados; os demais nós não retornam linhas.

SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_GLOBAL;

Exemplo de saída:

+-----------+------------------+-------------+------------+----------+-----------+------------+-----------------+----------------+---------------+------------+--------------+
| SERVER_ID | IP_PORT          | MATCH_INDEX | NEXT_INDEX | ROLE     | HAS_VOTED | FORCE_SYNC | ELECTION_WEIGHT | LEARNER_SOURCE | APPLIED_INDEX | PIPELINING | SEND_APPLIED |
+-----------+------------------+-------------+------------+----------+-----------+------------+-----------------+----------------+---------------+------------+--------------+
|         1 | 10.0.3.244:14886 |           1 |          0 | Leader   | Yes       | No         |               5 |              0 |             0 | No         | No           |
|         2 | 10.0.3.245:14886 |           1 |          2 | Follower | Yes       | No         |               5 |              0 |             1 | Yes        | No           |
|         3 | 10.0.3.246:14886 |           1 |          2 | Follower | No        | No         |               5 |              0 |             1 | Yes        | No           |
+-----------+------------------+-------------+------------+----------+-----------+------------+-----------------+----------------+---------------+------------+--------------+
3 rows in set (0.00 sec)

Colunas principais:

Coluna	Descrição
`IP_PORT`	Endereço IP e porta da réplica
`ROLE`	Função da réplica: `Leader`, `Follower` ou `Learner`
`ELECTION_WEIGHT`	Peso de eleição. Aplicável a cenários de recuperação de desastres entre data centers. Defina valores mais altos para réplicas no mesmo data center e aumente suas chances de vencer a eleição.
`MATCH_INDEX` / `NEXT_INDEX` / `APPLIED_INDEX`	Índice de um log de consenso

Consultar status do nó local

Retorna o estado Paxos do sistema local.

SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_LOCAL\G

Exemplo de saída:

*************************** 1. row ***************************
          SERVER_ID: 1
       CURRENT_TERM: 6
     CURRENT_LEADER: 10.0.3.244:14886
       COMMIT_INDEX: 1
      LAST_LOG_TERM: 6
     LAST_LOG_INDEX: 1
               ROLE: Leader
          VOTED_FOR: 1
   LAST_APPLY_INDEX: 0
SERVER_READY_FOR_RW: Yes
      INSTANCE_TYPE: Normal

Colunas principais:

Coluna	Descrição
`CURRENT_LEADER`	Endereço IP e porta do nó líder atual
`ROLE`	Função deste nó: `Leader`, `Follower` ou `Learner`
`SERVER_READY_FOR_RW`	Indica se este nó está pronto para atender tráfego de leitura/escrita. Durante a eleição de líder, o novo líder retorna `No` até concluir a reprodução do log.
`INSTANCE_TYPE`	Tipo da réplica. Valores válidos: `Normal` e `Log`

Consultar integridade da replicação

Retorna o status de sincronização entre o líder e cada seguidor. Apenas o nó líder retorna resultados.

SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_HEALTH;

Exemplo de saída:

+-----------+------------------+----------+-----------+---------------+-----------------+
| SERVER_ID | IP_PORT          | ROLE     | CONNECTED | LOG_DELAY_NUM | APPLY_DELAY_NUM |
+-----------+------------------+----------+-----------+---------------+-----------------+
|         1 | 10.0.3.244:14886 | Follower | YES       |             0 |              22 |
|         2 | 10.0.3.245:14886 | Leader   | YES       |             0 |               0 |
|         3 | 10.0.3.246:14886 | Follower | YES       |             0 |              11 |
+-----------+------------------+----------+-----------+---------------+-----------------+

Colunas principais:

Coluna	Descrição
`CONNECTED`	Indica se o nó está acessível e operando normalmente
`LOG_DELAY_NUM`	Latência da sincronização do log de consenso no Paxos, semelhante à latência de sincronização do relay log no MySQL
`APPLY_DELAY_NUM`	Atraso de reprodução dos logs de consenso Paxos no nó seguidor, semelhante ao atraso de reprodução da thread SQL relay no MySQL