Então não tem jeito mesmo, tem que ser feito, no meu caso, o pg_basebackup novamente.Perguntei isso porque o processo do pg_basebackup leva quase 2 horas... Imaginando nas possíveis transações que podem ocorrer nesse período, o parâmetro wal_keep_segments pode me ajudar a não *perder* essas transações durante o processo, correto? O problema é que no momento da queda pode acontecer do servidor primário estar um pouco a frente do secundário, daí como o você promoveu o secundário, eles estão em pontos diferentes e não há como mais fazer o antigo-primário seguir o novo. E nesse caso o wal_keep_segments não vai te ajudar em nada. Logo, a melhor e mais confiável solução é mesmo fazer um backup base novamente. Uma ferramenta que talvez ajude é a pg_rewind [1], mas admito que nunca a usei (achei arriscado demais). Ela foi feita para voltar um secundário à sincronia com o primário após o primeiro ter sido promovido. Não sei dizer ao certo se ela também pode fazer o contrário. De qualquer forma, no caso de failback, eu não acho que 2 horas seja um valor alto. Afinal, um failover não é algo que deve acontecer com frequência. [1] https://github.com/vmware/pg_rewind
Essa ferramenta pode ser uma dádiva do failback e bastante discussão foi colocada em cima dela.
Como ela está sendo desenvolvida em cima do 9.4, tudo é muito beta ainda, tanto o PostgreSQL quanto a própria ferramenta, mas acho que ela tem tudo para emplacar e entrar na árvore contrib oficial em uma ou duas versões.
Num banco de dados de vários gigabytes, aplicar as modificações a partir do WAL é algo bastante interessante para recolocar rapidamente as coisas em estado de alta disponibilidade novamente. Note que a ferramenta exige que a nova funcionalidade de checksums esteja habilitada ou wal_hint_bits, logo, a restauração deve ser bastante segura em termos de confiabilidade.
Testemos! []s Flavio Gurgel _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
