PolarDB:Níveis de consistência

Aplicabilidade

O cluster deve conter pelo menos um nó somente leitura (RO) antes que você possa configurar os níveis de consistência no console. Se o cluster não tiver nenhum nó somente leitura, as configurações de nível de consistência não serão exibidas na configuração do endpoint do cluster no console.

Problemas e soluções

O proxy de leitura/gravação do MySQL simula um servidor MySQL para estabelecer conexões com as aplicações. O proxy interpreta cada instrução SQL recebida. As operações de escrita, como UPDATE, DELETE, INSERT e CREATE, são encaminhadas para o nó primário, e as instruções SELECT são enviadas para os nós somente leitura. Isso implementa a divisão de leitura e escrita. No entanto, quando a carga do banco de dados é alta, por exemplo, ao executar instruções DDL como adição de colunas em tabelas grandes ou inserção de grandes volumes de dados, podem ocorrer atrasos significativos, o que impede os nós somente leitura de retornarem os dados mais recentes. O proxy de leitura/gravação do MySQL não consegue resolver inconsistências de consulta causadas por atrasos de replicação.

PolarDB usa replicação física assíncrona para sincronizar dados entre o nó primário e os nós somente leitura. Após a atualização dos dados no nó primário, as alterações são aplicadas nos nós somente leitura. O atraso de replicação depende da carga de escrita e geralmente fica no nível de milissegundos. A replicação assíncrona garante a consistência eventual entre o nó primário e os nós somente leitura. PolarDB oferece os quatro níveis de consistência a seguir para atender aos seus requisitos em diferentes cenários:

• Consistência eventual

• Consistência de sessão

• Consistência global

• Consistência global (modo de alto desempenho)

Consistência eventual

• Visão geral

  PolarDB utiliza uma arquitetura de divisão de leitura e escrita. A divisão de leitura e escrita tradicional oferece apenas consistência eventual. Atrasos de replicação entre o nó primário e os nós somente leitura podem causar resultados de consulta diferentes em diferentes nós. Por exemplo, se você executar as seguintes consultas consecutivamente dentro de uma sessão, o resultado final do SELECT pode ser diferente. O resultado real depende do atraso de replicação.

  INSERT INTO t1(id, price) VALUES(111, 96);
  UPDATE t1 SET price = 100 WHERE id=111;
  SELECT price FROM t1;

• Cenários aplicáveis

  Se você deseja reduzir a carga no nó primário e encaminhar o máximo possível de solicitações de leitura para os nós somente leitura, escolha a consistência eventual.

Consistência de sessão

• Visão geral

  Para resolver o problema de resultados de consulta inconsistentes causados pela consistência eventual, geralmente é necessário dividir as cargas de trabalho: encaminhar as solicitações que exigem alta consistência diretamente para o nó primário e encaminhar as solicitações que toleram consistência eventual para os nós somente leitura por meio da divisão de leitura e escrita. Isso aumenta a carga no nó primário, reduz a eficácia da divisão de leitura e escrita e adiciona complexidade ao desenvolvimento da aplicação.

  Para resolver esse problema, o PolarDB oferece a consistência de sessão, também conhecida como consistência causal. A consistência de sessão garante que, dentro da mesma sessão, uma solicitação de leitura sempre retorna dados atualizados antes da execução da leitura, assegurando a monotonicidade dos dados.

  Enquanto o PolarDB realiza a divisão de leitura e escrita na camada do proxy, o proxy rastreia as posições do log Redo aplicadas em cada nó, conhecidas como Log Sequence Number (LSN). Cada vez que os dados são atualizados, o PolarDB registra a posição da atualização como o Session LSN. Quando uma nova solicitação chega, o PolarDB compara o Session LSN com o LSN atual de cada nó. Se o LSN de um nó somente leitura não atender ao requisito, o proxy aguarda o nó somente leitura sincronizar com os dados mais recentes com base no tempo limite configurado e envia a solicitação apenas para os nós cujo LSN seja maior ou igual ao Session LSN. Isso garante a consistência de sessão. Embora essa abordagem pareça aumentar a carga no nó primário, o PolarDB usa replicação física, que é extremamente rápida.

  

  No cenário anterior, após a conclusão de uma atualização e o retorno do resultado ao cliente, a replicação já está em andamento. Quando a próxima solicitação de leitura chega, a replicação entre o nó primário e os nós somente leitura muito provavelmente já foi concluída. A maioria dos cenários de aplicação é intensiva em leitura com poucas escritas. Os testes mostram que esse mecanismo garante a consistência de sessão e o balanceamento de carga eficaz da divisão de leitura e escrita.

• Cenários aplicáveis

  Quanto maior o nível de consistência do PolarDB, maior a carga no nó primário e menor o desempenho do cluster. Recomendamos o uso da consistência de sessão, que tem impacto mínimo no desempenho e atende aos requisitos da maioria dos cenários de aplicação.

Consistência global

• Visão geral

  Em alguns cenários de aplicação, as dependências existem não apenas dentro de uma sessão, mas também entre sessões diferentes. Por exemplo, ao usar um pool de conexões, as solicitações do mesmo thread podem ser enviadas por conexões diferentes. Para o banco de dados, essas solicitações pertencem a sessões diferentes, mas possuem dependências sequenciais na lógica de negócio. Nesse caso, a consistência de sessão não consegue garantir a consistência da consulta. Portanto, o PolarDB oferece a consistência global para resolver esse problema.

  

  Quando cada solicitação de leitura chega ao proxy do PolarDB, o proxy verifica primeiro o LSN mais recente no nó primário, supondo que seja LSN0. Para reduzir a sobrecarga de buscar o LSN mais recente do nó primário a cada solicitação de leitura, é usada uma otimização interna em lote. O proxy então aguarda até que pelo menos um nó somente leitura atualize seu LSN para LSN0 e roteia a solicitação de leitura para esse nó somente leitura. Isso garante que a solicitação de leitura possa ler todos os dados atualizados até o momento em que a solicitação foi iniciada.

  A consistência global fornece os dois parâmetros de configuração a seguir:

  Parâmetro	Descrição
  ConsistTimeout	Global Consistency Timeout: o tempo máximo que uma solicitação de leitura aguarda um nó somente leitura sincronizar seu LSN. Se esse tempo for excedido, o proxy do PolarDB executa a operação especificada pelo parâmetro ConsistTimeoutAction. Valores válidos: 0 a 60000. Valor padrão: 20. Unidade: milissegundos.
  ConsistTimeoutAction	Global Consistency Timeout Policy: se o LSN do nó somente leitura não for atualizado para o LSN mais recente do nó primário dentro do tempo especificado pelo parâmetro ConsistTimeout, o proxy do PolarDB executa a operação especificada pelo parâmetro ConsistTimeoutAction. Valores válidos: 0 (padrão): enviar a solicitação de leitura para o nó primário. 1: o proxy retorna uma mensagem de erro wait replication complete timeout, please retry para a aplicação.

  Nota

  Para obter informações sobre como modificar o Global Consistency Timeout e a Global Consistency Timeout Policy, consulte Configurar o proxy do banco de dados.

• Cenários aplicáveis

  Quando o atraso de replicação entre o nó primário e os nós somente leitura é alto, o uso da consistência global pode fazer com que mais solicitações sejam roteadas para o nó primário, aumentando a carga no nó primário e possivelmente aumentando a latência do negócio. Portanto, recomendamos a escolha da consistência global em cenários intensivos em leitura com poucas escritas.

Consistência global (modo de alto desempenho)

PolarDB for MySQL oferece o serviço de consistência global (modo de alto desempenho). A consistência global (modo de alto desempenho) fornece uma consistência forte mais rigorosa do que a consistência global.

O sistema de transações PolarTrans usa o Commit Timestamp Store (CTS) e redes RDMA para fornecer leituras fortemente consistentes nos nós RO no nível do kernel. Isso garante que as leituras sempre retornem os dados mais recentes tanto dos nós RW quanto dos nós RO, fornecendo capacidade de leitura com consistência forte no nível do cluster. As solicitações de leitura enviadas para qualquer réplica no cluster retornam resultados fortemente consistentes.

Para mais detalhes sobre a consistência global (modo de alto desempenho), como limites de uso, princípios técnicos, como ativá-la e dados de desempenho, consulte Consistência global (modo de alto desempenho).

Como escolher um nível de consistência

• Quanto maior o nível de consistência do PolarDB, menor o desempenho do cluster.

  Recomendamos a consistência de sessão, que tem impacto mínimo no desempenho e atende aos requisitos da maioria dos cenários de aplicação.

• Se você tem requisitos de consistência alta entre sessões diferentes, escolha uma das seguintes opções:

  • Escolha a consistência global (modo de alto desempenho) ou a consistência global.

    Nota

    • Para o PolarDB for MySQL 5.7, 8.0.1 e 8.0.2, se você necessita de consistência forte estrita, a consistência global (modo de alto desempenho) é recomendada.

    • Para o PolarDB for MySQL 5.6, se você necessita de consistência forte estrita, escolha a consistência global, pois o modo de alto desempenho não é suportado nesta versão.

  • Use um HINT para forçar uma consulta específica ao nó primário.

    /*FORCE_MASTER*/ select * from user;

    Nota

    • Se você precisa executar a instrução de hint anterior por meio do cliente de linha de comando MySQL, adicione o parâmetro -c. Caso contrário, o hint pode ser filtrado pelo cliente de linha de comando MySQL, fazendo com que o hint falhe. Para mais informações, consulte cliente de linha de comando MySQL.

    • Os hints têm a prioridade de roteamento mais alta e não estão sujeitos às restrições de nível de consistência ou divisão de transações. Avalie o impacto antes de usar hints.

    • Não inclua instruções que alterem variáveis de ambiente nas instruções de hint, como /*FORCE_SLAVE*/ set names utf8;. Essas instruções podem causar erros nas operações subsequentes.

Como definir o nível de consistência

• Para definir o nível de consistência como consistência global (modo de alto desempenho), consulte Ativar SCC.

• Para definir o nível de consistência como consistência eventual, consistência de sessão ou consistência global, consulte Configurar o proxy do banco de dados.

FAQ

Por que não consigo ver as configurações de consistência no console?

As configurações de consistência são exibidas apenas quando o cluster contém pelo menos um nó somente leitura (RO). Se o seu cluster não tiver nenhum nó somente leitura, as configurações de consistência não serão exibidas na configuração do endpoint do cluster no console. Adicione pelo menos um nó somente leitura ao cluster primeiro. Depois disso, você poderá ver as configurações de consistência na configuração do endpoint do cluster. Para obter informações sobre como adicionar um nó somente leitura, consulte Adicionar ou remover nós.