Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1du3SD-0001Wl-Bp for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Sep 2017 21:19:45 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1du3SC-0005NM-Ud for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Sep 2017 21:19:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1du3Qb-0000u0-Vl for pgsql-hackers@postgresql.org; Mon, 18 Sep 2017 21:18:06 +0000 Received: from post.visena.com ([46.226.10.50]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1du3QY-0000Ao-Kn for pgsql-hackers@postgresql.org; Mon, 18 Sep 2017 21:18:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=visena.com; s=20141101.wh; h=Content-Type:MIME-Version:Subject:In-Reply-To:Message-ID:Cc:To:From:Date; bh=WLv7VVhQdrZtrYt6RlTDsLYkTWt2aRB+z3phW54oXo0=; b=GEJPA3rHUWqr5zAYKRtOXJWO7oWI3T04VnIH/uCGdhuhUznIplvTwLeWE2xoVfHyaTOJh88YgjGzRxoxWdJMSoWa9mU1WAKC6bihlPAkXBiIMs17CfzQfEnBHJdayNEG0HIcZUZ2eHhAW6iXq8BxCNkF2WlODWUJNxxkhxSDisI=; Received: from [10.0.1.10] (helo=tc7-visena.wh.internal.visena.com) by post.visena.com with esmtp (Exim 4.82) (envelope-from ) id 1du3QT-0007br-Ft; Mon, 18 Sep 2017 23:17:59 +0200 Received: from localhost ([127.0.0.1] helo=tc7-visena.wh.internal.visena.com) by tc7-visena.wh.internal.visena.com with esmtp (Exim 4.86_2) (envelope-from ) id 1du3QP-0008Dj-3Y; Mon, 18 Sep 2017 23:17:53 +0200 Date: Mon, 18 Sep 2017 23:17:52 +0200 (CEST) From: Andreas Joseph Krogh To: Bruce Momjian Cc: Michael Paquier , Robert Haas , "pgsql-hackers@postgresql.org" , Stephen Frost Message-ID: In-Reply-To: <20170918142807.GA16992@momjian.us> Subject: Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers) MIME-Version: 1.0 X-Mailer: Visena Mail 2.1.0-SNAPSHOT X-Spam-Score: -1.0 X-Spam-Report: SpamAssasin (score=-1.0, required 5.0 ALL_TRUSTED=-1,HTML_MESSAGE=0.001) Content-Type: multipart/alternative; boundary="----=_Part_1722_1920904510.1505769472963" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org ------=_Part_1720_1642176197.1505769472948 Content-Type: multipart/related; boundary="----=_Part_1721_412450970.1505769472948" ------=_Part_1721_412450970.1505769472948 Content-Type: multipart/alternative; boundary="----=_Part_1722_1920904510.1505769472963" ------=_Part_1722_1920904510.1505769472963 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable P=C3=A5 mandag 18. september 2017 kl. 16:28:07, skrev Bruce Momjian >: On Sat, Sep 16, 2017 at 11:36:40PM +0200, Andreas Joseph Krogh wrote: > P=C3=A5 l=C3=B8rdag 16. september 2017 kl. 18:34:51, skrev Bruce Momjian= < > bruce@momjian.us>: >=C2=A0 =C2=A0 =C2=A0No.=C2=A0 If you ran initdb with --waldir on the new = primary, you will create >=C2=A0 =C2=A0 =C2=A0a symbolic link in the PGDATA directory, and a direct= ory outside of >=C2=A0 =C2=A0 =C2=A0PGDATA for storing the WAL.=C2=A0 When you run rsync = on the new primary >=C2=A0 =C2=A0 =C2=A0PGDATA directory, you will copy the symlink in the PG= DATA directory, but >=C2=A0 =C2=A0 =C2=A0it will point to probably nothing on the standby. > > =C2=A0 > =C2=A0 > The misunderstanding here comes from the fact that I used pg_upgradeclus= ter > like this: > pg_upgradecluster --method=3Dupgrade --link 9.6 main > =C2=A0 > and it didn't issue initdb with=C2=A0--waldir on the new cluster (becaus= e > pg_upgradecluster issues initdb for you), so pg_wal ended up in $PGDIR= =20 because > pg_upgradecluster didn't figure out the old cluster was initialized with > --xlogdir. This is why I thought i made sense mentioning that one had to= =20 move > pg_wal manually. > =C2=A0 > I know it's debian-stuff, but maybe it's worth mentioning pg_upgradeclus= ter > somewhere and recommend not using it? It seems to start the new cluster > automatically and when upgrading standbys section 10 tells you not to do= =20 that. So you didn't really follow the instructions, but instead are trying to use the standby part of the instructions and found a problem with the way pg_upgradecluster handled it.=C2=A0 We really can't document this. It would be good to report the bug to pg_upgradecluster developers though. Yes, I can see rsync not working that case. =C2=A0 =C2=A0 =C2=A0 Actually I didn't know about --waldir switch of initdb and have always move= d=20 pg_xlog manually then symlinking.=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> should be clearly pointed out that copying pg_wal is= only needed in=20 those >=C2=A0 =C2=A0 =C2=A0> cases, and that it can be done with whatever networ= k-copying procedure >=C2=A0 =C2=A0 =C2=A0you're >=C2=A0 =C2=A0 =C2=A0> familiar with, ie. scp/rsync. This step is not simi= lar to the steps >=C2=A0 =C2=A0 =C2=A0required >=C2=A0 =C2=A0 =C2=A0> for copying tablespaces outside $PGDATA, so it's wo= rth documenting >=C2=A0 =C2=A0 =C2=A0explicitly. >=C2=A0 =C2=A0 =C2=A0> Maybe also telling users to ensure the synlink (in = $PGDATA) to pg_wal=20 on >=C2=A0 =C2=A0 =C2=A0> standby points to pg_wal. > >=C2=A0 =C2=A0 =C2=A0Why tell them new instructions when the rsync instruc= tions work fine? >=C2=A0 =C2=A0 =C2=A0What is the value? > > =C2=A0 > The rsync instructions mentioned in 10.F all address the --link scenario= and > use "--delete --hard-links --size-only", and "merge 2 source-dirs into o= ne", > which isn't relevant when copying pg_wal. > =C2=A0 > This sentence: > "If you have relocated=C2=A0pg_wal=C2=A0outside the data directories,=C2= =A0rsync=C2=A0must be=20 run > on those directories too." > implies one must follow the rsync pattern elsewhere in 10.F, which isn't= =20 really > true. Maybe re-wording it to: > "If you have relocated=C2=A0pg_wal=C2=A0outside the data directories you= must copy it > over to the new standby,=C2=A0and ensure the symlink from $PGDATA points= to it" > helps? We can't document every possible configuration, especially if a secondary tool is used in the middle. =C2=A0 =C2=A0 But we're not talking about many different configurations, we're addressing= =20 when pg_wal is located outside $PGDATA. So it basically boils down to the last sentence in 10.F: =C2=A0 If you have relocated=C2=A0pg_wal=C2=A0outside the data directories,=C2=A0r= sync=C2=A0must be run=20 on those directories too. =C2=A0 the word "must" here isn't correct. The point is that you have to copy the= =20 waldir manually from the primary to the standby and ensure the symlink poin= ts=20 to this new location on the standby. So I still think something like this i= s=20 better:=C2=A0"If you have relocated pg_wal outside the data directories you= must=20 copy it=C2=A0over to the new standby, and ensure the symlink from=20 $PGDATA/pg_wal=C2=A0points to it". I think it eliminates any doubt and make= s the=20 instructions complete and easy to follow. =C2=A0 Thanks. -- Andreas Joseph Krogh ------=_Part_1722_1920904510.1505769472963 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable
P=C3=A5 mandag 18. september 2017 kl. 16:28:07, skrev Bruce Momjian &l= t;bruce@momjian.us>:
On = Sat, Sep 16, 2017 at 11:36:40PM +0200, Andreas Joseph Krogh wrote:
> P=C3=A5 l=C3=B8rdag 16. september 2017 kl. 18:34:51, skrev Bruce Momji= an <
> bruce@momjian.us>:
>=C2=A0 =C2=A0 =C2=A0No.=C2=A0 If you ran initdb with --waldir on the ne= w primary, you will create
>=C2=A0 =C2=A0 =C2=A0a symbolic link in the PGDATA directory, and a dire= ctory outside of
>=C2=A0 =C2=A0 =C2=A0PGDATA for storing the WAL.=C2=A0 When you run rsyn= c on the new primary
>=C2=A0 =C2=A0 =C2=A0PGDATA directory, you will copy the symlink in the = PGDATA directory, but
>=C2=A0 =C2=A0 =C2=A0it will point to probably nothing on the standby. >
> =C2=A0
> =C2=A0
> The misunderstanding here comes from the fact that I used pg_upgradecl= uster
> like this:
> pg_upgradecluster --method=3Dupgrade --link 9.6 main
> =C2=A0
> and it didn't issue initdb with=C2=A0--waldir on the new cluster (beca= use
> pg_upgradecluster issues initdb for you), so pg_wal ended up in $PGDIR= because
> pg_upgradecluster didn't figure out the old cluster was initialized wi= th
> --xlogdir. This is why I thought i made sense mentioning that one had = to move
> pg_wal manually.
> =C2=A0
> I know it's debian-stuff, but maybe it's worth mentioning pg_upgradecl= uster
> somewhere and recommend not using it? It seems to start the new cluste= r
> automatically and when upgrading standbys section 10 tells you not to = do that.

So you didn't really follow the instructions, but instead are trying to
use the standby part of the instructions and found a problem with the
way pg_upgradecluster handled it.=C2=A0 We really can't document this.

It would be good to report the bug to pg_upgradecluster developers
though.

Yes, I can see rsync not working that case.
=C2= =A0
=C2= =A0
=C2= =A0
Act= ually I didn't know about --waldir switch of initdb and have always moved p= g_xlog manually then symlinking.=C2=A0
=C2= =A0
=C2= =A0
=C2= =A0
>= ;=C2=A0 =C2=A0 =C2=A0> should be clearly pointed out that copying pg_wal= is only needed in those
>=C2=A0 =C2=A0 =C2=A0> cases, and that it can be done with whatever n= etwork-copying procedure
>=C2=A0 =C2=A0 =C2=A0you're
>=C2=A0 =C2=A0 =C2=A0> familiar with, ie. scp/rsync. This step is not= similar to the steps
>=C2=A0 =C2=A0 =C2=A0required
>=C2=A0 =C2=A0 =C2=A0> for copying tablespaces outside $PGDATA, so it= 's worth documenting
>=C2=A0 =C2=A0 =C2=A0explicitly.
>=C2=A0 =C2=A0 =C2=A0> Maybe also telling users to ensure the synlink= (in $PGDATA) to pg_wal on
>=C2=A0 =C2=A0 =C2=A0> standby points to pg_wal.
>
>=C2=A0 =C2=A0 =C2=A0Why tell them new instructions when the rsync instr= uctions work fine?
>=C2=A0 =C2=A0 =C2=A0What is the value?
>
> =C2=A0
> The rsync instructions mentioned in 10.F all address the --link scenar= io and
> use "--delete --hard-links --size-only", and "merge 2 s= ource-dirs into one",
> which isn't relevant when copying pg_wal.
> =C2=A0
> This sentence:
> "If you have relocated=C2=A0pg_wal=C2=A0outside the data director= ies,=C2=A0rsync=C2=A0must be run
> on those directories too."
> implies one must follow the rsync pattern elsewhere in 10.F, which isn= 't really
> true. Maybe re-wording it to:
> "If you have relocated=C2=A0pg_wal=C2=A0outside the data director= ies you must copy it
> over to the new standby,=C2=A0and ensure the symlink from $PGDATA poin= ts to it"
> helps?

We can't document every possible configuration, especially if a
secondary tool is used in the middle.
=C2=A0
=C2=A0
But we're not talking about many different configurations, we're addre= ssing when pg_wal is located outside $PGDATA.
So it basically boils down to the last sentence in 10.F:
=C2=A0
If you have relocated=C2=A0pg_wal=C2=A0outsid= e the data directories,=C2=A0rs= ync=C2=A0must be run on those directories too.=
=C2=A0
the word "must" here isn't correct. The point is that you ha= ve to copy the waldir manually from the primary to the standby and ensure t= he symlink points to this new location on the standby. So I still think som= ething like this is better:=C2=A0"If you have relocated pg_wal outside= the data directories you must copy it=C2=A0over to the new standby, and en= sure the symlink from $PGDATA/pg_wal=C2=A0points to it". I think it el= iminates any doubt and makes the instructions complete and easy to follow.<= /div>
=C2=A0
Thanks.

--
Andreas Joseph Krogh
------=_Part_1722_1920904510.1505769472963-- ------=_Part_1721_412450970.1505769472948-- ------=_Part_1720_1642176197.1505769472948--