On 03-02-2017 16:06, Luiz Carlos L. Nogueira Jr. wrote: > Você pode simplesmente ajustar o parâmetro wal_keep_segments, caso > vc tenha espaço em disco para isso claro, e manter mais WALs, assim > mesmo em momentos em que o volume de WAL gerado é grande, você não > perderá a replicação. > > > Meu wal_keep_segments = 64 > Não use wal_keep_segments. Ao invés disso, utilize arquivamento (< 9.4) ou slots (>= 9.4).
> No meu archive_command eu copio também para outra pasta, fora a que faço > o backup, mas só que terão ficarão muitos archives lá. > Se você está usando arquivamento basta configurar o parâmetro restore_command no recovery.conf do servidor secundário. O comando a ser informado deve buscar onde você está arquivando os logs de transação. Ex.: restore_command = 'scp postgres@primario:/archives/%f %p' Quando o postgres perde o sincronismo no streaming ele tenta via restauração de arquivos (se o parâmetro restore_command existir). Assim, mesmo que houver um atraso de 10 GB, ele vai aplicando até conseguir voltar para streaming novamente. Vale ressaltar que se você apagar logs de transação necessários para tal operação antes que o servidor secundário aplique-os, não há como reaver a réplica. > Qual a versão do seu PostgreSQL? > > > 9.3.12 > Atualize para 9.3.15. Portanto, se você simplesmente tivesse colocado o restore_command na replicação "quebrada" (e tivesse os logs para aplicar) e em seguida reiniciasse o serviço, você conseguiria reaver a réplica sem precisar refazê-la. PS> fazer VF? Existe tanto inchaço assim nessas duas tabelas? 99% das execuções de VF, são feitas sem necessidade. Inchaço é inerente ao MVCC, portanto, a ideia é contê-lo e não removê-lo. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
