Vou adicionar algumas informações e referências atualizadas à excelente resposta do @ max-malysh acima.
Em resumo, se você fizer algo no mestre, ele precisará ser replicado no escravo. O Postgres usa registros WAL para isso, que são enviados após cada ação registrada no mestre para o escravo. O escravo então executa a ação e os dois estão novamente sincronizados. Em um dos vários cenários, você pode entrar em conflito com o escravo com o que vem do mestre em uma ação WAL. Na maioria deles, há uma transação acontecendo no escravo que entra em conflito com o que a ação do WAL deseja alterar. Nesse caso, você tem duas opções:
- Atrase um pouco a aplicação da ação WAL, permitindo que o escravo termine sua transação conflitante e aplique a ação.
- Cancele a consulta conflitante no escravo.
Estamos preocupados com o número 1 e dois valores:
max_standby_archive_delay
- este é o atraso usado após uma longa desconexão entre o mestre e o escravo, quando os dados estão sendo lidos de um arquivo WAL, que não são dados atuais.
max_standby_streaming_delay
- atraso usado para cancelar consultas quando entradas WAL são recebidas via replicação de streaming.
Geralmente, se o seu servidor se destina à replicação de alta disponibilidade, você deseja manter esses números curtos. A configuração padrão de 30000
(milissegundos se nenhuma unidade for fornecida) é suficiente para isso. Se, no entanto, você deseja configurar algo como um arquivo, réplica ou réplica de leitura que possa ter consultas muito demoradas, defina isso como algo mais alto para evitar consultas canceladas. A 900s
configuração recomendada acima parece ser um bom ponto de partida. Não concordo com os documentos oficiais sobre como definir um valor infinito-1
como uma boa idéia - que pode mascarar algum código de buggy e causar muitos problemas.
A única ressalva sobre consultas de longa execução e configuração desses valores mais altos é que outras consultas em execução no escravo em paralelo com a de longa execução que está causando o atraso da ação do WAL verão os dados antigos até que a longa consulta seja concluída. Os desenvolvedores precisarão entender isso e serializar consultas que não devem ser executadas simultaneamente.
Para obter uma explicação completa de como max_standby_archive_delay
e como max_standby_streaming_delay
funciona e por que, clique aqui .