Quando a divisão de leitura e gravação encaminha instruções SELECT para nós somente leitura, esses nós podem ficar atrasados em relação ao nó primário devido à replicação assíncrona. O PolarDB for PostgreSQL oferece dois níveis de consistência — consistência eventual e consistência de sessão (também chamada de consistência de leitura no nível de transação) — para controlar como sua aplicação lida com essa defasagem de replicação.
Como funciona
O PolarDB opera em uma arquitetura de cluster. Cada cluster contém um nó primário e um ou mais nós somente leitura. Conecte-se ao cluster usando dois tipos de endpoint:
Cluster endpoint (recomendado): distribui o tráfego entre todos os nós e ativa a divisão de leitura e gravação automaticamente.
Primary endpoint: direciona todo o tráfego exclusivamente para o nó primário.
A camada de proxy integrada gerencia a divisão de leitura e gravação. Ela analisa cada instrução SQL e encaminha operações de escrita (INSERT, UPDATE, DELETE, CREATE) para o nó primário e operações de leitura (SELECT) para os nós somente leitura.
A replicação de dados do nó primário para os nós somente leitura utiliza replicação física assíncrona baseada em write-ahead logging (WAL). Sob carga normal, a replicação é concluída em poucos milissegundos. Com carga leve, a latência de sincronização pode ser reduzida para menos de cinco segundos. Já sob carga intensa — como operações DDL em tabelas grandes ou inserções em massa — a latência de sincronização pode aumentar significativamente.
Como a replicação é assíncrona, um SELECT encaminhado a um nó somente leitura pode retornar dados que ainda não refletem as escritas mais recentes no nó primário. Os dois níveis de consistência determinam como o PolarDB gerencia essa defasagem.
Níveis de consistência
|
Eventual consistency |
Session consistency |
|
|
Comportamento de leitura |
O SELECT é encaminhado imediatamente a qualquer nó somente leitura disponível, sem aguardar a replicação. |
O SELECT é enviado a um nó somente leitura que já concluiu a replicação das escritas da sessão atual. |
|
Leituras desatualizadas |
Possível — o nó pode não ter os dados mais recentes. |
Impossível dentro de uma sessão — as leituras sempre refletem as escritas da mesma sessão. |
|
Desempenho |
Throughput ligeiramente maior; sem tempo de espera. |
Sobrecarga mínima na maioria das cargas de trabalho. |
|
Mais indicado para |
Análises, relatórios e cargas de trabalho com muitas leituras, nas quais um pequeno atraso de replicação é aceitável. |
Cargas de trabalho transacionais em que as leituras precisam refletir escritas recentes da mesma sessão. |
Consistência eventual
Na consistência eventual, o proxy encaminha cada SELECT para qualquer nó somente leitura disponível, sem verificar se esse nó possui os dados mais recentes. O nó retorna os resultados imediatamente.
Isso significa que uma leitura após uma escrita na mesma sessão pode retornar dados desatualizados:
INSERT INTO t1(id, price) VALUES(111, 96);
UPDATE t1 SET price = 100 WHERE id=111;
SELECT price FROM t1;
-- May return 96 or NULL if the read-only node hasn't replicated the write yetUtilize a consistência eventual para cargas de trabalho em que um pequeno atraso de replicação é aceitável: jobs agendados, consultas analíticas, relatórios agregados ou acesso somente leitura por usuários que não gravam dados.
Consistência de sessão
Com a consistência de sessão, o proxy garante que, após uma escrita em uma sessão, as leituras subsequentes na mesma sessão sejam encaminhadas apenas para nós somente leitura que já aplicaram essas escritas. O SELECT é enviado a um nó qualificado e retorna resultados atualizados.
O mesmo exemplo comporta-se de maneira previsível:
INSERT INTO t1(id, price) VALUES(111, 96);
UPDATE t1 SET price = 100 WHERE id=111;
SELECT price FROM t1;
-- Returns 100, guaranteedA consistência de sessão adiciona uma sobrecarga mínima à maioria das cargas de trabalho e atende à grande maioria dos casos de uso transacional. Defina-a como padrão para aplicações em que os usuários leem suas próprias escritas recentes.
Funcionamento da consistência de sessão
O proxy rastreia o progresso do log de redo em cada nó usando um número de sequência de log (LSN). Quando uma escrita é confirmada no nó primário, o proxy registra o LSN dessa escrita como o LSN da sessão.
Ao receber a próxima leitura na mesma sessão, o proxy compara o LSN da sessão com o LSN de cada nó somente leitura. Ele encaminha a leitura para um nó cujo LSN seja maior ou igual ao LSN da sessão, garantindo que o nó tenha aplicado a escrita. Enquanto o nó selecionado retorna os resultados ao cliente, os demais nós continuam replicando em segundo plano.
Esse mecanismo fornece consistência de sessão, divisão de leitura e gravação e balanceamento de carga simultaneamente.
Melhores práticas
Use a consistência de sessão na maioria das cargas de trabalho. Ela tem impacto mínimo no desempenho do cluster e resolve o cenário comum em que a aplicação lê dados que acabou de gravar.
Para consultas que precisam ler os dados absolutamente mais recentes — independentemente dos limites da sessão — redirecione-as para o nó primário usando a dica FORCE_MASTER:
/*FORCE_MASTER*/ select * from user;Reserve o FORCE_MASTER para consultas específicas, em vez de usá-lo amplamente. Encaminhar todas as leituras para o nó primário elimina o benefício da divisão de leitura e gravação e aumenta a carga sobre o nó primário.