Evitar problemas de desempenho com REPLICA IDENTITY FULL no RDS para PostgreSQL

A replicação lógica do PostgreSQL exige que cada tabela publicada tenha uma identidade de réplica para que o assinante possa localizar a linha correta a ser atualizada ou excluída. Por padrão, a chave primária serve como identidade de réplica. Quando uma tabela não tem chave primária ou índice exclusivo adequado, é possível definir a identidade da réplica como FULL, o que faz com que o PostgreSQL use a linha inteira como chave.

Embora a configuração REPLICA IDENTITY FULL resolva o problema imediato de replicar tabelas sem chaves primárias, ela pode causar sérios problemas de desempenho tanto para o publicador quanto para o assinante. Entender esses impactos é importante para qualquer pessoa que use a replicação lógica com o RDS para PostgreSQL, bem como recursos que dependem da replicação lógica interna, como implantações azuis/verdes.

Por que a configuração REPLICA IDENTITY FULL causa problemas

Aumento do volume de WAL no publicador

A configuração REPLICA IDENTITY controla quais informações o PostgreSQL grava no log de gravação antecipada (WAL) para identificar linhas atualizadas ou excluídas. Com a identidade de réplica padrão (chave primária), somente as colunas de chave são registradas em log como a identidade de linha antiga. Com FULL, o PostgreSQL registra os valores antigos de cada coluna para cada UPDATE e DELETE. Isso tem várias consequências:

Pesquisas lentas de linha no assinante

Quando o assinante recebe um registro de log UPDATE ou DELETE, ele precisa encontrar a linha correspondente na respectiva cópia local da tabela. Com REPLICA IDENTITY FULL, o assinante procura uma linha que corresponda a todos os valores de coluna da imagem de linha antiga.

A forma como o PostgreSQL realiza essa pesquisa difere de acordo com a versão principal do PostgreSQL:

Como REPLICA IDENTITY FULL causa atraso na replicação

Ambos os problemas descritos acima (WAL maior no publicador e pesquisas de linha mais lentas no assinante) se unem para causar atraso na replicação.

Por padrão, a replicação lógica do PostgreSQL usa um único processo de aplicação de operador por assinatura para receber alterações do publicador e aplicá-las às tabelas do assinante. Os processos do operador de aplicação são alterados em série, uma linha por vez, na ordem de confirmação. Isso significa que o throughput do assinante é limitado pela rapidez com que ele consegue aplicar cada alteração.

Quando REPLICA IDENTITY FULL está definida em uma tabela sem um índice apropriado, todas as operações UPDATE e DELETE requerem uma verificação sequencial da tabela completa para encontrar a linha correspondente. Se a tabela tiver milhões de linhas, cada uma dessas operações poderá levar segundos ou mais. O resultado é um problema em cascata:

Esse problema é especialmente grave para tabelas que recebem operações UPDATE ou DELETE frequentes. As operações INSERT não são afetadas porque não exigem pesquisa de linha no assinante.

Impacto nas implantações azuis/verdes

No Amazon RDS, as implantações azuis/verdes usam a replicação lógica internamente para manter o ambiente verde sincronizado com o azul, configurando uma única assinatura por banco de dados. O processo de aplicação da replicação lógica no ambiente verde é de thread único. Um único processo de operador de aplicação recebe todas as alterações do ambiente azul e as aplica uma de cada vez, na ordem de confirmação. Não há aplicação paralela no caminho de replicação azul/verde.

Esse design de thread único significa que a capacidade do ambiente verde de acompanhar o ambiente azul depende inteiramente da rapidez com que um operador de aplicação consegue processar cada alteração. Quando as tabelas usam REPLICA IDENTITY FULL sem uma chave primária ou um índice adequado, o impacto no operador de aplicação depende da versão do PostgreSQL. Nas versões anteriores à 16, todas as operações UPDATE e DELETE nessas tabelas forçam o operador de aplicação a realizar uma verificação sequencial da tabela completa para encontrar a linha correspondente. Nas versões 16 e posteriores, o PostgreSQL usará um índice adequado, se houver um disponível, mas, se não houver nenhum índice qualificado, o operador de aplicação continuará a recorrer a uma verificação sequencial. Enquanto o operador de aplicação busca uma linha em uma tabela grande, todas as outras alterações pendentes em todas as tabelas entram na fila e ficam aguardando.

As consequências das implantações azuis/verdes são significativas:

Para evitar esses problemas, garanta que todas as tabelas tenham uma chave primária ou um índice exclusivo adequado configurado explicitamente como a identidade de réplica usando ALTER TABLE ... REPLICA IDENTITY USING INDEX antes de criar uma implantação azul/verde. Não recorra à configuração REPLICA IDENTITY FULL com seleção implícita de índice no PostgreSQL 16 e posterior, pois o assinante pode escolher um índice pouco seletivo ou recorrer a verificações sequenciais. Teste a implantação com uma workload de gravação representativa para confirmar se o ambiente verde consegue se ajustar.

Para ter mais informações sobre as limitações das implantações azuis/verdes, consulte Limitações e considerações relativas às implantações azul/verde do Amazon RDS. Para ver as práticas recomendadas, consulte Práticas recomendadas do RDS para PostgreSQL para implantações azuis/verdes.

Como identificar tabelas que usam REPLICA IDENTITY FULL

Execute a seguinte consulta para encontrar todas as tabelas com REPLICA IDENTITY FULL:

SELECT n.nspname AS schema, c.relname AS table_name, c.relreplident
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind = 'r'
  AND c.relreplident = 'f'
  AND n.nspname NOT IN ('pg_catalog', 'information_schema')
ORDER BY n.nspname, c.relname;

Os valores da coluna relreplident são:

Soluções alternativas e práticas recomendadas

Adicione uma chave primária sempre que possível

A solução mais eficaz é adicionar uma chave primária às tabelas que não têm uma. Quando existe uma chave primária, o PostgreSQL a utiliza como a identidade de réplica padrão, o que oferece pesquisas de linha eficientes no assinante e minimiza a sobrecarga do WAL no publicador.

ALTER TABLE my_table ADD COLUMN id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY;

Se a adição de uma chave primária não for viável devido a restrições da aplicação, considere a possibilidade de adicionar um índice exclusivo em um conjunto de colunas NOT NULL e defini-lo como a identidade de réplica:

CREATE UNIQUE INDEX my_table_replica_idx ON my_table (col1, col2);
ALTER TABLE my_table REPLICA IDENTITY USING INDEX my_table_replica_idx;

Não recorra à seleção implícita de índice (PostgreSQL 16 e posterior)

A partir do PostgreSQL 16, o operador de aplicação do assinante pode usar índices btree ou de hash para pesquisas de linha quando a identidade de réplica está definida como FULL, mesmo que esses índices não estejam explicitamente configurados como a identidade de réplica. Embora isso evite verificações sequenciais em alguns casos, recorrer a esse comportamento implícito é um antipadrão pelos seguintes motivos:

Em vez disso, configure explicitamente a identidade de réplica para cada tabela replicada:

Reserve REPLICA IDENTITY FULL somente para tabelas em que nenhuma das opções seja viável e entenda que o desempenho depende de fatores que estão fora de seu controle direto.

Monitorar o atraso na replicação

Ao usar REPLICA IDENTITY FULL, monitore atentamente o atraso na replicação para detectar lentidões de aplicação no assinante antes que elas se tornem graves.

No publicador, verifique a defasagem entre a posição atual do WAL e o que o assinante confirmou:

SELECT slot_name, confirmed_flush_lsn, pg_current_wal_lsn(),
       (pg_current_wal_lsn() - confirmed_flush_lsn) AS lag_bytes
FROM pg_replication_slots
WHERE slot_type = 'logical';

Um valor lag_bytes que não para de aumentar indica que o assinante está se atrasando. A visualização pg_stat_replication_slots apresenta estatísticas adicionais sobre o uso de cada slot de replicação.

No assinante, a visualização pg_stat_subscription mostra o estado de cada operador de aplicação, inclusive a última localização do WAL recebida e relatada:

SELECT subname, received_lsn, latest_end_lsn,
       last_msg_send_time, last_msg_receipt_time
FROM pg_stat_subscription;

Uma grande defasagem entre received_lsn e latest_end_lsn, ou carimbos de data/hora obsoletos em last_msg_send_time, pode indicar que o operador de aplicação está tendo dificuldades para acompanhar. A visualização pg_stat_subscription_stats também rastreia erros e conflitos de aplicação que podem contribuir para o atraso.

Para o RDS para PostgreSQL, também é possível monitorar a métrica OldestReplicationSlotLag do CloudWatch, que rastreia o atraso em bytes do slot de replicação mais atrasado. Um valor crescente é um aviso antecipado de atraso na replicação.

Verificar quais tabelas podem estar usando um índice abaixo do ideal durante a aplicação

No assinante, é possível identificar tabelas nas quais o operador de aplicação está realizando leituras excessivas de pilha, o que pode indicar que a tabela não tem um índice eficiente para pesquisas de linha durante a aplicação. Execute a seguinte consulta no assinante:

SELECT relname, heap_blks_read, heap_blks_hit,
       idx_blks_read, idx_blks_hit,
       heap_blks_read + heap_blks_hit AS total_heap_access
FROM pg_statio_user_tables
WHERE heap_blks_read > 0
ORDER BY heap_blks_read DESC
LIMIT 10;

Uma tabela com um valor heap_blks_read alto em relação a idx_blks_read pode indicar que o operador de aplicação não está usando um índice eficiente para localizar linhas para as operações UPDATE e DELETE. Esse é um motivo comum de atraso na replicação quando se usa REPLICA IDENTITY FULL.

Avalie se a configuração REPLICA IDENTITY FULL é necessária

Antes de configurar REPLICA IDENTITY FULL, considere se você realmente precisa dessa configuração. Alguns dos motivos comuns para usá-la são:

Se o único motivo for a falta de uma chave primária, adicionar uma é quase sempre a melhor solução. Se você precisar de imagens anteriores completas para a CDC, considere se seu consumidor de CDC consegue reconstruir linhas completas mantendo o estado externamente, o que evita a sobrecarga do WAL e do assinante da configuração REPLICA IDENTITY FULL.

Resumo das recomendações