Hi @bricklen. Thanks for your reply. I've been working on it for 20h =( So....
The master is currently shipping the WALs to the slave. When pg_basebackup has done, I got a successful log: postgres(iostreams)[10037]: 2016-01-09 00:07:26.604 UTC|10085|LOG: database system is ready to accept read only connections The problem happens when, after pg_basebackup, I change the recovery.conf to replicate from live, changing these 2 lines: standby_mode = on primary_conninfo = 'host=IP_TO_THE_OTHER_SLAVE port=5432 user=replicator application_name=replication_slave02' I read the link you have sent: http://dba.stackexchange.com/a/53546/24393 I'm doing all exactly the same, but only one parameter is different: time pg_basebackup --pgdata=$PGDATA --host=IP_OF_MASTER --port=5432 --username=replication --password --xlog-method=stream --format=plain --progress --verbose I'm not using --xlog-method=strem I'm using: ssh postgres@slave1 'pg_basebackup --pgdata=- --format=tar --label=bb_master --progress --host=localhost --port=5432 --username=replicator *--xlog* | pv --quiet --rate-limit 100M' | tar -x --no-same-owner on http://www.postgresql.org/docs/9.2/static/app-pgbasebackup.html is: -xlog Using this option is equivalent of using -X with method fetch. So... I have 2 TB of data. I wouldn't like to run the pg_basebackup again with the option: --xlog-method=stream without have sure that is going to work.... Do you have any other ideia? Do you know if --xlog it's the problem and I should re-run the pg_basebackup again with the *--xlog-method=stream* option? Thank you Lucas Possamai kinghost.co.nz <http://forum.kinghost.co.nz/memberlist.php?mode=viewprofile&u=2&sid=e999f8370385657a65d41d5ff60b0b38> On 10 January 2016 at 06:06, bricklen <brick...@gmail.com> wrote: > On Fri, Jan 8, 2016 at 8:44 PM, drum.lu...@gmail.com <drum.lu...@gmail.com > > wrote: > > Hi, I'm a bit too lazy to try suss out the exact reasons for your failure, > but here is a reasonably thorough guide to set up replication: > http://dba.stackexchange.com/a/53546/24393 > > A few tips: > - Having the master ship WALs to the slaves is handy if you can pull it > off. If you are doing it over the wire and using rsync, "-z" for > compression is recommended. If you are doing the tar format of the > pg_basebackup, you *must* have the master ship the WALs to the slave > otherwise it won't be able to synchronize (the "stream" method ships WALs > over the wire so the end result is a synchronized system. > > - I always run pg_basebackup from the slave I am building, for simplicity. > - I create new slaves almost every day (we have thousands of databases) > using a bash script and it almost much never fails. In essence it is a big > wrapper around the pg_basebackup command (though we are using pg93 mostly). > > The base backup command that I run from the slave I am building: > pg_basebackup --pgdata=$PGDATA --host=$MASTER_IP --port=$PGPORT > --username=replication --no-password --xlog-method=stream --format=plain > --progress --verbose > > The recovery.conf: > standby_mode = 'on' > primary_conninfo = 'user=replication host=$IP_OF_UPSTREAM_SLAVE_OR_MASTER > port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres' > recovery_target_timeline = 'latest' > archive_cleanup_command = '/usr/pgsql-9.3/bin/pg_archivecleanup > /path/to/WALs %r' > restore_command = 'cp /path/to/WALs/%f "%p" 2>> > /your/PGDATA/path/pg_log/standby.log' >
