Date: Fri, 15 Sep 2017 01:23:45 +0200 (CEST)
From: Andreas Joseph Krogh <andreas@visena.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Michael Paquier <michael.paquier@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
	Stephen Frost <sfrost@snowman.net>
Message-ID: <VisenaEmail.db.e5ceedc56ec1471.15e82123988@tc7-visena>
In-Reply-To: <20170914191356.GC6595@momjian.us>
Subject: Re: Clarification in pg10's pgupgrade.html step 10
 (upgrading standby servers)
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_1022_1199313535.1505431425101"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

------=_Part_1020_291648953.1505431425090
Content-Type: multipart/related; 
	boundary="----=_Part_1021_1005499634.1505431425090"

------=_Part_1021_1005499634.1505431425090
Content-Type: multipart/alternative; 
	boundary="----=_Part_1022_1199313535.1505431425101"

------=_Part_1022_1199313535.1505431425101
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

P=C3=A5 torsdag 14. september 2017 kl. 21:13:56, skrev Bruce Momjian <
bruce@momjian.us <mailto:bruce@momjian.us>>:
On Thu, Sep 14, 2017 at 08:49:24PM +0200, Andreas Joseph Krogh wrote:
 >=C2=A0 =C2=A0 =C2=A0I think the tablespace example is clear enough to mod=
ify for WAL and we
 >=C2=A0 =C2=A0 =C2=A0instruct them right below that example to do WAL.
 >
 > =C2=A0
 > Well, it's not following the exact same structure as there's no
 > "version-directory" in pg_xlog, so the "rsync the version-dirs into it's=
=20
parent
 > on the target"=C2=A0isn't what's happening.
 > =C2=A0
 > That's why I think this makes sense to mention for the sake of a complet=
e
 > example:
 >
 > rsync --archive --delete --hard-links --size-only=20
/vol1/postgres/9.6/pg_xlog \
 >=C2=A0 =C2=A0 =C2=A0 =C2=A0/vol1/postgres/10/pg_wal standby.example.com:/=
vol1/postgres/10/pg_wal

 Well, there is technically no need for version directories in pgdata
 either --- installers just create them.
=C2=A0
=C2=A0
I tested upgrading from 9.6 to 10=C2=A0now, using pg_upgrade, and pg_upgrad=
e=20
creates the new data-dir with pg_wal "in it" (just like regular initdb), so=
=20
pg_upgrade seems not to care about where the old version's pg_xlog was. You=
=20
have to move (by symlinking)=C2=A0pg_wal to a separate location manually *a=
fter*=20
running pg_upgrade on the master. No special handling is needed when rsync'=
ing=20
it over to the standby, so it doesn't need any=C2=A0--hard-links or --size-=
only,=20
correct?
=C2=A0
Given the path,=C2=A0on the upgraded primary,=C2=A0to=C2=A0pg_wal=C2=A0is=
=C2=A0/custom/path/to/pg_wal,=20
the rsync command will be:
=C2=A0
rsync --archive --delete /custom/path/to/pg_wal=20
standby.example.com:/custom/path/to/pg_wal
=C2=A0
I think it's useful to mention this to eliminate any doubt.
=C2=A0
I also think it's worth mentioning that you have to manually move pg_wal to=
 a=20
custom location after running pg_upgrade as it will not preserve/use the ol=
d=20
path.
=C2=A0
Thanks.

 --
 Andreas Joseph Krogh

------=_Part_1022_1199313535.1505431425101
Content-Type: text/html;charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>P=C3=A5 torsdag 14. september 2017 kl. 21:13:56, skrev Bruce Momjian &=
lt;<a href=3D"mailto:bruce@momjian.us">bruce@momjian.us</a>&gt;:</div>

<blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt=
 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=3D"display:inline; font-family: monospace; font-size: 12px;">On =
Thu, Sep 14, 2017 at 08:49:24PM +0200, Andreas Joseph Krogh wrote:<br>
&gt;=C2=A0 =C2=A0 =C2=A0I think the tablespace example is clear enough to m=
odify for WAL and we<br>
&gt;=C2=A0 =C2=A0 =C2=A0instruct them right below that example to do WAL.<b=
r>
&gt;<br>
&gt; =C2=A0<br>
&gt; Well, it's not following the exact same structure as there's no<br>
&gt; &quot;version-directory&quot; in pg_xlog, so the &quot;rsync the versi=
on-dirs into it's parent<br>
&gt; on the target&quot;=C2=A0isn't what's happening.<br>
&gt; =C2=A0<br>
&gt; That's why I think this makes sense to mention for the sake of a compl=
ete<br>
&gt; example:<br>
&gt;<br>
&gt; rsync --archive --delete --hard-links --size-only /vol1/postgres/9.6/p=
g_xlog \<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0/vol1/postgres/10/pg_wal standby.example.com=
:/vol1/postgres/10/pg_wal<br>
<br>
Well, there is technically no need for version directories in pgdata<br>
either --- installers just create them.</div>
</blockquote>

<div>=C2=A0</div>

<div>=C2=A0</div>

<div>I tested upgrading from 9.6 to 10=C2=A0now, using pg_upgrade, and pg_u=
pgrade creates the new data-dir with pg_wal &quot;in it&quot; (just like re=
gular initdb), so pg_upgrade seems not to care about where the old version'=
s pg_xlog was. You have to move (by symlinking)=C2=A0pg_wal to a separate l=
ocation manually *after* running pg_upgrade on the master. No special handl=
ing is needed when rsync'ing it over to the standby, so it doesn't need any=
=C2=A0--hard-links or --size-only, correct?</div>

<div>=C2=A0</div>

<div>Given the path,=C2=A0on the upgraded primary,=C2=A0to=C2=A0pg_wal=C2=
=A0is=C2=A0/custom/path/to/pg_wal, the rsync command will be:</div>

<div>=C2=A0</div>

<div><span style=3D"font-family: monospace;">rsync --archive --delete /cust=
om/path/to/pg_wal standby.example.com:/custom/path/to/pg_wal</span></div>

<div>=C2=A0</div>

<div>I think it's useful to mention this to eliminate any doubt.</div>

<div>=C2=A0</div>

<div>I also think it's worth mentioning that you have to manually move pg_w=
al to a custom location after running pg_upgrade as it will not preserve/us=
e the old path.</div>

<div>=C2=A0</div>

<div>Thanks.</div>

<div><br>
--<br>
Andreas Joseph Krogh</div>
------=_Part_1022_1199313535.1505431425101--

------=_Part_1021_1005499634.1505431425090--

------=_Part_1020_291648953.1505431425090--