> > Eu não usuária o -h, melhor ir via Unix domain sockets (não deve ter > *grandes* ganhos, mas creio que seja um pouquinho melhor). > > O seu split seria pra poder fazer o upload em paralelo, certo? Tem uma > ferramenta que promete fazer um basebackup em paralelo e super eficiente, > se chama pgBackRest [1]. Eu particularmente (ainda) não usei, mas ouvi > falar muito bem (de pessoas bem "fodas" no PG, no caso o principal foi o > Stephen Frost, um commiter do PG). > > Não.... na verdade, como o meu atual servidor se encontra na Austrália, e o servidor da AMAZON ficará nos EUA, irei rodar o pg_basebackup junto com o SPLIT, para que eu tenha vários arquivos de tantos GB. Facilitando assim o envio depois.
Pois se eu realizar o pg_basebackup do novo servidor, como a DB é grande, pode haver problemas de rede e eu perder tudo.. tendo que começar tudo novamente. Então a ideia é realizar o pg_basebackup ao mesmo tempo com o SPLIT. Criando assim vários arquivos de 50GB, por exemplo. E depois enviar estes arquivos para o novo servidor via rsync. > Outra opção que tem, se tiver uma conexão confiável entre esses servidores > (creio que tenha, já que quer fazer replicação), seria usar o pg_basebackup > direto do novo servidor (da AWS) com o parâmetro --xlog-method=stream. > Talvez criar um túnel pra comprimir os pacotes. > > >> Os passos seriam: >> >>> 1 - Configurar o arquivamento dos wal_files dentro do servidor novo >>> (archive_command no slave) >>> >> > Qual versão você está usando? Apenas a partir da 9.4 é possível fazer > archive de um slave. > Putz!!!! Sério que é só da 9.4??? Eu estou usando o 9.2 (Sim, iremos atualizar mas vai demorar um pouco :P) Então o archive vai ter que ser do master? Mas eu consigo fazer replicação cascade né? Fazer um servidor slave replicar de outro slave? Só o archive que não? > > Veja o pg_receivexlog também, pode ser mais fácil já deixar coletando. > > >> 2 - rodar o pg_basebackup no slave >>> 3 - Uma vez que o passo 2 terminar, copiar os arquivos que foram >>> divididos para dentro do servidor novo >>> 4 - juntar os arquivos com o comando JOIN >>> >> > OK. > > >> 5 - Restaurar a DB (pg_restore) >>> >> > Não é via pg_restore, esse só é usado para backups feitos via pg_dump, > você teria que usar o tar mesmo. Eu nem faria o join num arquivo, dá pra ir > direto: > > $ join arquivo1 arquivo2 ... | tar xvfz - -C /path/to/pgdata/ > Sim.. exatamente! Após eu ter mandado este e-mail eu fiz testes aqui, e é isso aí...... na verdade sobrescreve toda a pasta /data no novo servidor, e depois disso recuperar com o wal_file > > > > >> 6 - Configurar o restore_command para restaurar a DB usando os wal_files >>> que foram configurados ainda no passo 1 >>> >> > Lembre-se de já configurar o standby_mode=on, se não vai se tornar > primário ao finalizar de pegar os xlogs. > pode deixar! > > >> 7 - Habilitar a streaming replication. >> >> > OK. > > Dá pra juntar o passo 6 e 7 numa configuração só, colocando tanto > restore_command quanto primary_conninfo no recovery.conf, quando ele não > tem mais arquivos pra restaurar via restore_command irá conectar via > primary_conninfo sozinho. > > Bem. Está algumas opções pra você, qualquer dúvida avisa aí. > > [1] https://github.com/pgbackrest/pgbackrest > > obrigado! Patrick
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
