Re: New Slave - timeline ERROR - Mailing list pgsql-general
| From | drum.lucas@gmail.com |
|---|---|
| Subject | Re: New Slave - timeline ERROR |
| Date | |
| Msg-id | CAE_gQfXEC8=koWh=TL-CxU_GM0XPbK=F9S3yiEyqKECbpu+RFQ@mail.gmail.com Whole thread Raw |
| In response to | Re: New Slave - timeline ERROR (bricklen <bricklen@gmail.com>) |
| Responses |
Re: New Slave - timeline ERROR
(bricklen <bricklen@gmail.com>)
|
| List | pgsql-general |
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 connectionsThe problem happens when, after pg_basebackup, I change the recovery.conf to replicate from live, changing these 2 lines:
standby_mode = onprimary_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 --verboseI'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
On 10 January 2016 at 06:06, bricklen <bricklen@gmail.com> wrote:
On Fri, Jan 8, 2016 at 8:44 PM, drum.lucas@gmail.com <drum.lucas@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/24393A 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 --verboseThe 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'
pgsql-general by date: