Re: pg_upgrade and rsync - Mailing list pgsql-hackers

From David Steele
Subject Re: pg_upgrade and rsync
Date
Msg-id 54CAC4AB.5060407@pgmasters.net
Whole thread Raw
In response to Re: pg_upgrade and rsync  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
<div class="moz-text-plain" graphical-quote="true" lang="x-western" style="font-family: -moz-fixed; font-size: 12px;"
wrap="true"><prewrap="">On 1/29/15 11:34 AM, Bruce Momjian wrote: 
</pre><blockquote style="color: #000000;" type="cite"><pre wrap="">3. Check that the replica is not very lagged.  If it
is,wait for 
traffic to die down and for it to catch up.
</pre></blockquote><pre wrap="">I think I'd want a something a bit more specific here.  When the primary
shuts down it will kick out one last WAL.  The filename should be recorded.

</pre><blockquote style="color: #000000;" type="cite"><pre wrap="">7. shut down postgres on the replica.
</pre></blockquote><pre wrap="">Before the shutdown make sure that the replicas are waiting on the
subsequent log file to appear (note that versions prior to 9.3 skip
00).  That means all WAL has been consumed and the primary and
replica(s) are in the same state.

This is a bit more complex if streaming replication is being used
<b class="moz-txt-star"><span class="moz-txt-tag">*</span>without<span class="moz-txt-tag">*</span></b> good old
fashionedlog shipping to a backup server and I'm not 
sure exactly how to go about it.  I suppose you could start Postgres in
single user mode, commit a transaction, and make sure that transaction
gets to the replicas.

OTOH, streaming replication (unless it is synchronous) would be crazy
without doing WAL backup.  Maybe that's just me.

<div class="moz-txt-sig">--
- David Steele
<a class="moz-txt-link-abbreviated" href="mailto:david@pgmasters.net">david@pgmasters.net</a>


</div></pre></div>

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0
Next
From: Jim Nasby
Date:
Subject: Re: TABLESAMPLE patch