On 14-06-2016 11:55, Diógenes Vargas de Bittencourt wrote: > Obrigado Euler, eu dei uma estudada sobre o PITR como indicado, mas o > que entendi, me corrija se estiver errado, é que o PITR serviria como um > backup incremental em tempo real, para que eu possa restaurar o banco em > um momento específico, eu achei bem legal a proposta desta função, mas o > que estamos usando aqui no nosso ambiente é somente streaming, e o que > entendi, é que além do streaming seria feito um backup incremental o > tempo todo no servidor. No meu caso como o servidor slave perde o > sincronismo com o master, essa retomada do estado 100% do slave seria > através do backup incremental que ele está fazendo? Eu ativaria o pitr > no servidor slave, e nele iria realizar a recuperação em caso de falta > de sincronismo? Bah, travou o nintendo! > Na replicação nativa, o PostgreSQL pode alternar entre "streaming" e aplicação do WAL caso restore_command esteja habilitado (é uma das maneiras de trabalhar com replicação). Se o registro do WAL solicitado pelo slave não estiver mais no pg_xlog do servidor principal, o PostgreSQL alterna para aplicação do WAL (via restore_command) até que ele possa voltar para "streaming" novamente. A ideia aqui não é usar PITR; neste caso, *não* deixar "perder" a réplica é a função do restore_command.
Caso queira destacar os arquivos do WAL que não são necessários para replicação, você pode utilizar o archive_cleanup_command no recovery.conf. -- 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
