PolarDB:Failover com réplica quente

As seguintes tecnologias principais implementam o recurso de failover com réplica quente no PolarDB:

• New high availability module: VDS

  Ao ativar o recurso de failover com réplica quente, o PolarDB ativa o VDS. Com a arquitetura de disco compartilhado do PolarDB, o VDS fornece gerenciamento autônomo, detecção de falhas e seleção de nó primário para os nós do cluster. Detalhes sobre a arquitetura do VDS:

  • Cada nó de computação no VDS possui uma thread independente. As threads do VDS classificam-se em três categorias: Leader, Follower e Observer. Em um cluster PolarDB, as threads Leader executam no nó primário, as threads Follower executam no nó de réplica quente e as threads Observer executam nos nós somente leitura. Um cluster PolarDB pode conter uma thread Leader, uma thread Follower e várias threads Observer.

  • O VDS cria dois módulos de dados no PolarStore: Bloco Compare-and-Swap (CAS) e Registro de Cluster Polar (PCR).

    • O Bloco CAS é um bloco de dados atômico que suporta operações CAS fornecidas pelo PolarStore. O CAS permite bloqueios distribuídos baseados em concessão (lease) no VDS e registra metadados como detentor do bloqueio e tempo de concessão. O nó primário e o nó de réplica quente de um cluster PolarDB usam semânticas de aquisição e renovação de bloqueio para detectar falhas e selecionar o nó primário.

    • O PCR armazena informações de gerenciamento de nós do PolarDB, como o status da topologia de um cluster. Threads Leader têm permissão para gravar dados no PCR, enquanto threads Follower e Observer têm apenas permissão para ler dados do PCR. Quando uma thread Follower é designada como thread Leader, a thread Leader original torna-se uma thread Follower. Somente a thread Leader mais recente tem permissão para gravar dados no PCR. O PCR também reconstrói a topologia.

  

  Geralmente, o nó primário fornece serviços de leitura e gravação, e a thread Leader correspondente renova regularmente seu bloqueio no VDS. Quando o nó primário fica indisponível, um nó de réplica quente assume o controle. O processo ocorre da seguinte forma:

  1. Após a expiração da concessão do nó primário, uma thread Follower é bloqueada e eleita como thread Leader. Nesse momento, o nó de réplica quente torna-se o nó primário.

  2. Quando o nó primário original se recupera, ele falha ao tentar adquirir um bloqueio. Então, o nó primário original é rebaixado para um nó de réplica quente.

  3. Ao concluir o processo de seleção do nó primário, o PCR transmite as novas informações de topologia para todas as threads Observer. Dessa forma, os nós somente leitura conectam-se automaticamente ao novo nó primário e restauram os links de sincronização para números de sequência de log (LSNs) e logs binários.

• Global prefetching system

  Em comparação aos nós somente leitura comuns, o nó standby quente é um tipo especial de nó somente leitura que reserva uma pequena parte dos recursos de CPU e memória para otimizar a velocidade de switchover. O sistema de pré-busca global é o módulo mais importante no failover com réplica quente. Ele sincroniza os metadados do nó primário em tempo real e pré-carrega dados essenciais na memória para aumentar a velocidade do failover. O sistema de pré-busca global consiste em quatro módulos: Buffer Pool, Undo, Redo e Binlog.

  • Buffer Pool

    O módulo Buffer Pool monitora em tempo real a lista vinculada usada para implementar o algoritmo Least Recently Used (LRU) no buffer pool do nó primário e envia dados relevantes para o nó de réplica quente. O nó de réplica quente seleciona páginas acessadas frequentemente e as pré-carrega na memória para evitar degradação de desempenho causada por uma queda significativa na taxa de acertos do buffer pool quando um nó somente leitura é eleito como nó primário.

  • Undo

    O módulo Undo pré-carrega dados no sistema de transações. Durante o failover, o PolarDB localiza as transações pendentes nas páginas undo e reverte essas transações. Nós somente leitura processam apenas requisições de consultas analíticas em larga escala e não acessam transações não confirmadas do nó primário. Isso resulta em longo tempo de espera de I/O para páginas undo. O recurso de failover com réplica quente pré-carrega páginas undo e as reproduz até a versão mais recente usando Runtime Apply para reduzir o tempo de recuperação do sistema de transações.

  • Redo

    O módulo Redo armazena em cache os logs redo da réplica quente e dos nós somente leitura na tabela hash redo da memória em tempo real.

  • Binlog

    Após ativar os logs binários, as transações InnoDB no estado Prepare decidem se devem confirmar ou reverter uma transação com base nesses logs. Quando um grande número de transações é executado, o sistema pode levar vários segundos ou minutos para ler e analisar todos os logs binários. Os nós de réplica quente usam threads em segundo plano para armazenar assincronamente os logs binários mais recentes no cache de I/O e analisá-los antecipadamente, aumentando assim a velocidade do failover.

  O PolarDB suporta conversão dinâmica entre nós de réplica quente e nós standby comuns. Em cenários reais, você pode manter um nó de réplica quente ativado permanentemente ou ativar o recurso de réplica quente apenas por um curto período durante alterações de configuração ou atualizações. O PolarDB permite configurar o nó primário e nós somente leitura com especificações diferentes. No entanto, pelo menos um nó somente leitura deve usar as mesmas especificações do nó primário para recuperação de desastres. Recomendamos configurar esse nó como um nó de réplica quente.

• Persistent connections and transaction status preservation

  No entanto, o failover ou a atualização quente pode afetar seu serviço e causar problemas como conexões transitórias, falhas de conexão e reversão de transações existentes. Isso aumenta a complexidade e os riscos do desenvolvimento de aplicações.

  O PolarDB oferece suporte ao recurso de Conexões persistentes. As conexões persistentes funcionam com o PolarProxy atuando como uma ponte de conexão entre sua aplicação e o PolarDB. Quando o banco de dados executa um failover primário/secundário, o PolarProxy conecta os nós do banco de dados à sua aplicação e restaura a sessão anterior, incluindo as variáveis de sistema originais, variáveis de usuário, codificação de conjunto de caracteres e outras informações.

  O recurso de conexões persistentes aplica-se apenas a conexões ociosas. Se a sessão atual tiver uma transação em execução no momento da troca de nó, o PolarProxy não conseguirá recuperar o contexto original da transação do PolarDB. O novo nó primário reverterá as transações não confirmadas e liberará os bloqueios de linha mantidos por essas transações. Nesse caso, não é possível manter as conexões persistentes. Para resolver esse problema, o PolarDB fornece o recurso de preservação do estado da transação. A preservação do estado da transação, juntamente com o recurso de conexões persistentes, permite um failover rápido para oferecer alta disponibilidade sem interromper seus serviços.

  Diferentemente da replicação lógica baseada em logs binários, a arquitetura de replicação física permite que o PolarDB reconstrua as mesmas transações no nó de réplica quente tal como estão no nó primário.

  Por exemplo, considere que o processo de confirmação de uma transação em uma aplicação seja BEGIN > INSERT > UPDATE > COMMIT e que o recurso de preservação do estado da transação esteja ativado. Após o início da execução da transação, o PolarProxy armazena em cache a instrução SQL executada mais recentemente enquanto encaminha a instrução SQL para o nó primário. Depois que a instrução INSERT é executada no nó primário, o PolarDB salva automaticamente o savepoint da instrução mais recente como parte das informações da transação. O rastreador de sessão retorna as informações atuais da sessão e da transação para o PolarProxy. Em seguida, o PolarProxy salva temporariamente os dados no cache interno. As informações da sessão, como conjuntos de caracteres e variáveis de usuário, servem para manter as conexões. As informações da transação, como trx_id e undo_no, servem para a preservação do estado da transação. Além disso, as informações da transação são sincronizadas continuamente com a réplica quente por meio de um link RDMA separado. Se os logs binários estiverem ativados para o banco de dados backend, o cache de log binário local correspondente a cada transação será sincronizado com o nó de réplica quente.

  

  Suponha que o nó primário fique indisponível durante a execução da instrução UPDATE no PolarDB. O PolarProxy não transmite imediatamente o erro da camada subjacente para a conexão da aplicação, mas retém a requisição por um período. Após o failover, o novo nó primário pode construir todas as transações não confirmadas com base nos logs redo e aguardar assincronamente pelas transações não confirmadas sem revertê-las. Quando o PolarProxy detecta a mensagem de failover bem-sucedido, ele usa as informações de sessão e transação armazenadas em seu próprio cache para reconstruir a transação chamando a API Attach Trx do PolarDB. O PolarDB determina se as informações da transação são válidas com base nas informações do PolarProxy. Se as informações da transação forem válidas, elas serão vinculadas à conexão e revertidas para o savepoint do undo_no correspondente à última instrução (a instrução UPDATE).

  Após a reconstrução da transação, o PolarProxy pode reenviar a instrução UPDATE mais recente, cuja execução falhou, para o novo nó primário a partir do cache de instruções SQL. Durante o processo de failover, nenhum erro de conexão ou transação é reportado na sua aplicação. A única diferença é que a instrução UPDATE pode ser mais lenta que o normal.