Re: Having trouble configuring a Master with multiple standby Servers in PostgreSQL 9.3.3

From: <fburgess(at)radiantblue(dot)com>
To: "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Having trouble configuring a Master with multiple standby Servers in PostgreSQL 9.3.3
Date: 2014-04-18 15:24:52
Message-ID: 20140418082452.5a830134ae84016b0174832fdc1a3173.8430ba0028.wbe@email11.secureserver.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

<html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;"><div>I started the recovery yesterday and it ran overnight and is still running. Is the problem that the master is still producing new archivelogs that the slave is trying to recover, so that I am currently in a perpetual recovery mode?</div><div>I can see that the most recent archivelog being processed on the master is also being recovered on the slave. Do I need to suspend copying the archivelogs to the /mnt/server/slave1_archivedir/ directory, or should I wait?</div><div><br></div><div>thanks</div><div><br></div><div>Freddie<br></div><div><br></div><div><br></div>
<blockquote id="replyBlockquote" webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:10pt; color:black; font-family:verdana;">
<div id="wmQuoteWrapper">
-------- Original Message --------<br>
Subject: Re: [BUGS] Having trouble configuring a Master with multiple<br>
standby Servers in PostgreSQL 9.3.3<br>
From: Michael Paquier &lt;<a href="mailto:michael(dot)paquier(at)gmail(dot)com">michael(dot)paquier(at)gmail(dot)com</a>&gt;<br>
Date: Thu, April 17, 2014 5:28 pm<br>
To: <a href="mailto:fburgess(at)radiantblue(dot)com">fburgess(at)radiantblue(dot)com</a><br>
Cc: <a href="mailto:pgsql-bugs(at)postgresql(dot)org">pgsql-bugs(at)postgresql(dot)org</a><br>
<br>
On Fri, Apr 18, 2014 at 1:19 AM, &lt;<a href="mailto:fburgess(at)radiantblue(dot)com">fburgess(at)radiantblue(dot)com</a>&gt; wrote:<br>
&gt; Hi Michael, thanks for your reply.<br>
&gt;<br>
&gt; I discussed this my colleague, and we decided to change the archive_command<br>
&gt; to execute a shell script.<br>
That's wiser as it allows more flexibility.<br>
<br>
&gt; This will copy the archivelogs from the master to both slaves. Will that<br>
&gt; avoid the issue with removing needed WAL files?<br>
&gt; slave 1<br>
&gt; archive_cleanup_command = 'pg_archivecleanup /mnt/server/slave1_archivedir/<br>
&gt; %r'<br>
&gt; slaves #2<br>
&gt; archive_cleanup_command = 'pg_archivecleanup /mnt/server/slave2_archivedir/<br>
&gt; %r'<br>
&gt; Does this look correct?<br>
Looks fine. You are copying each WAL file to a different archive<br>
folder, and pg_archivecleanup will clean only the path it uses for<br>
each folder, so there is no risk to have a WAL file removed by one<br>
slave and needed by the other.<br>
<br>
&gt; I did a pg_clt reload to change the archivelog destination from<br>
&gt; /mnt/server/master_archivedir to be redistributed to slave1 and slave2. Do I<br>
&gt; need to redo this backup step?<br>
Not if the slaves have already fetched necessary WAL files from the<br>
single master archive before you changed the command.<br>
<br>
&gt; psql -c "select pg_start_backup('initial_backup');"<br>
&gt; rsync -cvar --inplace --exclude=*pg_xlog*<br>
&gt; /u01/fiber/postgreSQL_data/postgres(at)1(dot)2(dot)3(dot)5:/u01/fiber/postgreSQL_data/<br>
&gt; psql -c " select pg_stop_backup ();"<br>
&gt;<br>
&gt; or can I just copy all of the missing archivelog files from the<br>
&gt; /mnt/server/master_archivedir to the slaves, and then restart the slaves in<br>
&gt; recovery mode?<br>
Taking a new base backup will be fine. But you actually do not need to<br>
do so if your slaves have already caught up enough. Your slaves are<br>
using streaming replication and are on the same server as the master<br>
AFAIU so they should be fine, but there is always a possibility that<br>
they need some WAL from archives if one of them for example was not<br>
able to connect to the master for a long time and master already<br>
dropped the necessary WAL files from its pg_xlog.<br>
-- <br>
Michael<br>
<br>
<br>
-- <br>
Sent via pgsql-bugs mailing list (<a href="mailto:pgsql-bugs(at)postgresql(dot)org">pgsql-bugs(at)postgresql(dot)org</a>)<br>
To make changes to your subscription:<br>
<a href="http://www.postgresql.org/mailpref/pgsql-bugs">http://www.postgresql.org/mailpref/pgsql-bugs</a><br>

</div>
</blockquote></span></body></html>

Attachment Content-Type Size
unknown_filename text/html 3.8 KB

Browse pgsql-bugs by date

  From Date Subject
Next Message Matheus de Oliveira 2014-04-18 15:47:35 Re: BUG #9136: pg_is_xlog_replay_paused() should not need Superuser
Previous Message Bruce Momjian 2014-04-18 14:53:23 Re: BUG #9136: pg_is_xlog_replay_paused() should not need Superuser