Re: Having trouble configuring a Master with multiple standby Servers in PostgreSQL 9.3.3 - Mailing list pgsql-bugs

=0A=0A-------- Original Message --------=0ASubject: Re: [BUGS] Having trouble configuring a Master with multiple<= br>=0Astandby Servers in PostgreSQL 9.3.3=0AFrom: Michael Paquier <<= a href=3D"mailto:michael.paquier@gmail.com">michael.paquier@gmail.com&g= t;=0ADate: Thu, April 17, 2014 5:28 pm=0ATo: fburgess@radiantblue.com=0ACc: pgsql-bugs@postgresql.org=0A=0AO= n Fri, Apr 18, 2014 at 1:19 AM, <fburgess@radiantblue.com> wrote:=0A> Hi Michael, thanks= for your reply.=0A>=0A> I discussed this my colleague, and w= e decided to change the archive_command=0A> to execute a shell scrip= t.=0AThat's wiser as it allows more flexibility.=0A=0A> This= will copy the archivelogs from the master to both slaves. Will that=0A= > avoid the issue with removing needed WAL files?=0A> slave 1= =0A> archive_cleanup_command =3D 'pg_archivecleanup /mnt/server/slave1_a= rchivedir/=0A> %r'=0A> slaves #2=0A> archive_cleanup_c= ommand =3D 'pg_archivecleanup /mnt/server/slave2_archivedir/=0A> %r'= =0A> Does this look correct?=0ALooks fine. You are copying each = WAL file to a different archive=0Afolder, and pg_archivecleanup will cl= ean only the path it uses for=0Aeach folder, so there is no risk to hav= e a WAL file removed by one=0Aslave and needed by the other.=0A= =0A> I did a pg_clt reload to change the archivelog destination from= =0A> /mnt/server/master_archivedir to be redistributed to slave1 and sla= ve2. Do I=0A> need to redo this backup step?=0ANot if the slaves= have already fetched necessary WAL files from the=0Asingle master arch= ive before you changed the command.=0A=0A> psql -c "select pg_st= art_backup('initial_backup');"=0A> rsync -cvar --inplace --exclude= =3D*pg_xlog*=0A> /u01/fiber/postgreSQL_data/postgres@1.2.3.5:/u01/fi= ber/postgreSQL_data/=0A> psql -c " select pg_stop_backup ();"=0A= >=0A> or can I just copy all of the missing archivelog files from= the=0A> /mnt/server/master_archivedir to the slaves, and then resta= rt the slaves in=0A> recovery mode?=0ATaking a new base backup w= ill be fine. But you actually do not need to=0Ado so if your slaves hav= e already caught up enough. Your slaves are=0Ausing streaming replicati= on and are on the same server as the master=0AAFAIU so they should be f= ine, but there is always a possibility that=0Athey need some WAL from a= rchives if one of them for example was not=0Aable to connect to the mas= ter for a long time and master already=0Adropped the necessary WAL file= s from its pg_xlog.=0A-- =0AMichael=0A=0A=0A-- =0AS= ent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)=0ATo make changes to your subscriptio= n:=0Ahttp://w= ww.postgresql.org/mailpref/pgsql-bugs=0A=0A=0A