Re: Trouble with replication - Mailing list pgsql-general

From David Greco
Subject Re: Trouble with replication
Date
Msg-id 187F6C10D2931A4386EE8E58E13857F63040D28D@BY2PRD0811MB415.namprd08.prod.outlook.com
Whole thread Raw
In response to Re: Trouble with replication  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Trouble with replication  (againstdemons84 <webadmin@vetuk.co.uk>)
List pgsql-general

 

 

From: Michael Paquier [mailto:michael.paquier@gmail.com]
Sent: Thursday, June 06, 2013 7:01 PM
To: David Greco
Cc: John R Pierce; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Trouble with replication

 

 

 

On Thu, Jun 6, 2013 at 9:19 PM, David Greco <David_Greco@harte-hanks.com> wrote:

Then what is the purpose to shipping the archived WAL files to the slave? i.e. if wal_keep_segments has to be high enough to cover any replication lag anyways, then should I even bother shipping them over?

Oh. I just noticed that you set up restore_command on slave, so if streaming replication failed due to a WAL file already removed on master, slave process will try to fetch missing WAL files from the archive.

Could you provide more logs of slave? Are you sure that the missing WAL file was not fetched from the archive after failing to get it through streaming replication?

 

 

The errors continued ad infinitum on the slave. I’ve since redone the replication setup with keep WAL segments set on the master to a rather large number, enough to nearly fill the drive dedicated to XLOG. Replication appears to be working properly now. Best I can figure, it had something to do with the pg_restore used to populate the master? This would be a large 30GB transaction.

 

 

 

 

 

 

pgsql-general by date:

Previous
From: Albe Laurenz
Date:
Subject: Re: Postgresql - Currval Vs Session Pool
Next
From: Merlin Moncure
Date:
Subject: Re: Postgresql - Currval Vs Session Pool