On Fri, May 8, 2015 at 2:29 PM James Sewell <james.sew...@lisasoft.com> wrote:
> Hello All, > > I am running 9.4 on Centos. > > I have three servers, one master and two slaves. The slaves have the > following recovery.conf > > standby_mode = 'on' > primary_conninfo = 'user=postgres host=mastervip port=5432' > restore_command = 'scp -o BatchMode=yes postgres@backuphost:/archived_wals/%f > %p' > recovery_target_timeline= 'latest' > > Is there any way to combine following > > - a master switch (ie: if node1 dies and node2 is promoted then node3 > follows node2) > - using a WAL archive, such that if node2 goes down for two days it > will get WALs from the archive if they are no longer on the master > > At the moment the master switch works fine, but if I was to have a WAL > archive with multiple timelines in it then I would end up in the newest > timeline. > The timeline switch would happen whenever do a standby promotion (or PITR) in which case you want the 2nd standby to follow the newly promoted master i.e. it should be following the new timeline. > I suppose what I want is the following: > > If I am a streaming replica only follow streamed timeline switches, not > archive timeline switches. > I am trying to guess when would these two be different (unless there are two different masters writing to the same archive which I suppose is wrong anyways). Can you write down an example for clarity so that others can understand your scenario better? > Obviously if I am not a streaming replica I need to follow archive > timeline switches so I don't break PIT recovery. > > Possible? > > > James Sewell, > PostgreSQL Team Lead / Solutions Architect > ______________________________________ > > > Level 2, 50 Queen St, Melbourne VIC 3000 > > *P *(+61) 3 8370 8000 *W* www.lisasoft.com *F *(+61) 3 8370 8099 > > > ------------------------------ > The contents of this email are confidential and may be subject to legal or > professional privilege and copyright. No representation is made that this > email is free of viruses or other defects. If you have received this > communication in error, you may not copy or distribute any part of it or > otherwise disclose its contents to anyone. Please advise the sender of your > incorrect receipt of this correspondence. > >