Tenho dois bancos de dados Postgres 13 no AWS RDS.
- Um é mestre, o outro é escravo e usa replicação lógica.
- A replicação ficou para trás em cerca de 350 Gb.
- O escravo ficou com a CPU no limite nos últimos quatro dias por causa de alguns trabalhos em andamento, então não tenho certeza de qual replicação lógica conseguiu replicar durante esse tempo.
- Eu matei esses trabalhos e agora a CPU no mestre e no escravo está baixa.
- Olho para o assinante via
select * from pg_stat_subscription;e vejo quelatest_end_lsnestá avançando, embora muito lentamente. - O editor diz que os atrasos de gravação/liberação/reprodução estão todos 13 minutos atrasados, mas tem sido assim durante a maior parte do dia.
- Não vejo erros nos logs do publicador ou do assinante, além de alguns erros simples de SQL que os usuários têm cometido.
Há algo que eu possa fazer aqui? Anteriormente, eu defini wal_receiver_timeouto timeout como 0 porque tive problemas de replicação, e isso ajudou. Gostaria de ter alguma visibilidade aqui para ter algum tipo de confiança de que ele vai funcionar, mas além desses lsnvalores e logs do banco de dados, não tenho certeza do que verificar.
Descobri qual era o meu problema: gatilhos no assinante.
Eu vi
pg_locksque uma tabela estava sendo constantemente atingida. Havia um bloqueio exclusivo na tabela, e nenhuma outra consulta queria usá-lo, o que era bom. Ela estava ocupada o tempo todo.De alguma forma, descobri
pg_stat_user_functionsque diz quanto tempo uma função (como uma função de gatilho) executa. Havia um par de funções que tinham uma quantidade extremamente grande de tempo em execução e ela continuava aumentando.Fiz um
alter table foo disable trigger x, e uma vez feito isso, a replicação imediatamente começou a fluir. Meus dados agora estavam desatualizados porque o gatilho não estava em execução, mas tudo bem, desde que meu publicador não trave devido à falta de espaço. Depois que a replicação foi recuperada, reativei os gatilhos, e as coisas estão funcionando bem.