Início / dba / Perguntas / 327495
Accepted
Luciano Andress Martini
Asked: 2023-05-25 05:56:08 +0800 CST

Sincronização rsync do Postgresql da réplica usando rsync -u

  • 772

É seguro sincronizar a replicação do PostgreSQL usando o parâmetro rsync -u?

Por exemplo, se minha replicação foi perdida por muito tempo devido a um problema de conexão (arquivo WAL já excluído, por exemplo), sempre preciso rsync todos os arquivos do meu banco de dados novamente do mestre para a réplica.

Então, estou usando algo como (ou quase) isso (escravo interno):

systemctl stop postgresql@11-slave 
psql -h 10.0.0.MASTER -Atc "select pg_start_backup('clone', true);"
rsync -avz [email protected]:/var/lib/postgresql/11/main /var/lib/postgresql/11/  
systemctl start postgresql@11-slave 
psql -h 10.0.0.MASTER -Atc "select pg_stop_backup('clone', true);"

A solução acima está funcionando muito bem e foi testada várias vezes sem perda de dados.

Mas fico tentado a tentar restaurar a replicação usando algo mais rápido (perigoso?) como:

systemctl stop postgresql@11-slave 
psql -h 10.0.0.MASTER -Atc "select pg_start_backup('clone', true);"
rsync -uavz [email protected]:/var/lib/postgresql/11/main/ /var/lib/postgresql/11/  
systemctl start postgresql@11-slave 
psql -h 10.0.0.MASTER -Atc "select pg_stop_backup('clone', true);"

É seguro usar o parâmetro -u no rsync (update) em vez de recopiar todos os arquivos ou devo continuar copiando todos os arquivos quando algo acontecer com minha replicação?

postgresql

1 respostas

  1. Best Answer

    Acho que isso não rsync -ucompraria nada para você. O único arquivo relevante que poderia ter um timestamp posterior no standby seria o arquivo de controle, que é pequeno.

    Acho que este é um caso clássico de otimização prematura. Se alguma coisa, pode prejudicá-lo. Se por acidente alguém ou alguma coisa tocasse em um arquivo no modo de espera, dando a ele um carimbo de data e hora posterior (com ou sem modificação do conteúdo), você não copiaria esse arquivo por engano, o que poderia causar corrupção de dados.

    Você não perguntou sobre isso, mas sua maneira de consertar o servidor standby é datada, já que ele usa a “API de backup exclusiva” e depende de backup_labelser criado no diretório de dados do primário. Este método de backup foi removido no PostgreSQL v15, porque uma falha no primário enquanto o modo de backup está ativo tem uma boa chance de colocar o primário em uma condição em que não pode ser reiniciado sem intervenção manual. Você pode alterar seu procedimento para usar a “API de backup não exclusiva”, mas se tornará um pouco mais complicado.

    Eu recomendo que você tome as medidas usuais que evitam de forma confiável que o servidor em espera “caia fora”: coloque-o restore_commandem espera para permitir que ele se recupere do arquivo WAL ou use um slot de replicação e monitore a replicação.

    • 1

relate perguntas