Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pFX0F-0006Tp-5Y for pgsql-admin@arkaria.postgresql.org; Wed, 11 Jan 2023 09:02:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pFX0D-0003VG-Qb for pgsql-admin@arkaria.postgresql.org; Wed, 11 Jan 2023 09:02:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pFX0D-0003Um-5r for pgsql-admin@lists.postgresql.org; Wed, 11 Jan 2023 09:02:33 +0000 Received: from sonic306-19.consmr.mail.gq1.yahoo.com ([98.137.68.82]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pFX0A-0002GQ-6H for pgsql-admin@lists.postgresql.org; Wed, 11 Jan 2023 09:02:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673427745; bh=/t7GGykPVCyc0xIm/P4UuGJsDgvNsdoy7B/ep4E8kkQ=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=T6eDnUk7ubjOtUmjj8HRFbE1lxHa8elYIHDHdse/GuCxCpXiNRDcK/hBGY1R70bjTrwdV0d7ItmWlvgPN6WTlJ5kybhvR5snUrlDkfsT5SjZDNuZMAhwComdPopMl3GZa2P0lZeVx2+N5h+ExcCuooTGd3T6omDO7PwnZuZ8DeZ+hzi8905lE6lbRvB1o4pjP/smFyuZjbgGuH3/EB9gdjmPhZ4EljlfyPY3/TU+BefGUfSTrXxJT/VU8ClYO0SSD+7aOcrayvySNxOzB7PcKuJXcKMgOiUqax2nozsjsuQ0tfTTtjXhl/OVCy1di2CzQj3hDRJK5XP1l39YfPzYhA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673427745; bh=MmILfxF537Zf8+5yL9jOGmYACbvIaw7EmDBtA30v/LQ=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=ORIYv8giqt9eJMG+huydm5Xou7remr/Mo9j2wW1AjoytglG8aWsGEOUjTfOsoHTpxife+BcFWaFmi8b9o8/wyInVP4hp085r781LdYl/I6NqpvECDIekE0Gw+Y3pEgH8Y1Pr2i18ZkvmO/biNl9W32Jl1L1UCKjhXwqxMFlAjx71vT763HHGWPuu5Y98JO4Gat6xWNnwf64PLXPRo+4Kyvj68Wr6rMA7woC9VNi3lnL10DDQsQ17M44CiuwiGO45JXiadaSsuPt58loC/Qav+Ol9iYfJ/r1YuQi2Renaq7+vbKxPkW1Qr2P0aUkT0GaDJ47d1OJrB8cwoF4/dF+ogA== X-YMail-OSG: qKKpvxYVM1leY8E15aBcOV4hcFuvAM0WE.jePUcsCk5U4lIgHJqkGKgXi5pV1Gc 95EMm3lCYaX06xtoY4D7UClIsNascHFioNHKbf4tvLHKakOUoYFlcOUsQCuWzy_f4U3w06CORDhm MX9YNuiSLxmQ4diJkCZ9HkSCvp3x_ppvIB_JqaoACyXu0vyfLQOJWWuKzgKNWoTEbp922390_doh 8YLjsRIbit0EaZG0vOjL0N6ZNWxlguVBHDGzkLEVKWGzKUu5QkD8VcSz0GPD2ks1goeCyF0hm3vk pNQmphYskddSF8RjK6ptY1yVy8Khqg968SrzunAxfDTmhA9DjrvLHiT3TAaspTwv.r08h6opH1QE 01bu3fNoSy3J3YlxYqjOVByiAN80xCVY_IRRd6IlN96sNPlkp2M2GYPVt5stux2G1JTCAtjFGxaP 5R2k.6RdZUllyXDvt1ZRl.NkxdI.UY.Ibes6.qAK4I4rQDO6UIRbZR198qXo8l8KnbFMszMwEatS Dt1x.a1iKSaleWyZ7GvxJ.CYqfTqTO9eL5Ba8rCGVQuXxxtdG5mQfJ1azXrI3vpnvGScLT.hHOB7 I0T1uP9upz3mMl.rks7SAelVCUZeQWC1er1xVybKlCMeGciCKTFGJPdBpvHt0Azgm_OR.4GblXWa EgovoPg0KANhTwa5erma8Fp_fftkvIg5R.jwW0g0xXKIV_pfnZEjNaj8E6kNAf_9f57VAnPGNOAf e1QQePXCyaYecLp4zCBVOlJA46Hy7J_hcFSrtFsZRm9YsLXD0YhyC3PneAXFCliWQ6bcmqmLaRyq W7JtKF44ge5nR9Eov_lt5rHC3sG6taF5ICZyiUvmpB.3lSU0pw.joszLroYC1QG_DAu6wxEOWwiA YJ6r7ofKdkrv2SPfPGS8bdZYFj_KxmMxbk3IeLpeFE2ByR..KXHHkNi5Pw0yhBKhHeLreQibl3ZY 4IzmyJT6e1u14z0zC8b_QuO8.aN8kAB95A4M2_YN8BHgzt7kXTQybl0glBBtBBvNURSEBmMOvPo0 bt.PD.dAf3v5Ew657UYzs0Bp7SgjcMFZC9oAWRg43uE5z_0BUje7Qt8HGikSd22ntmQMamfcNIWX 42_4rOQ1qTrdE3EhXfgD6Vs65kBvcmTYTDiKR485Aw_RbBDZpOuZBIvxEFXDL.coeYMF8d0HkxAd tYs5.5ufMWoPgQvVGZVRd1CUCpFmU2CDC2tRcT5wzUhgHKi6gsuDnDOLqIUWtaoswgK6qeN4WGEE 9KgX8zd_pBCSeXOrX5iCvS2OJd_EkJ41gDOd2sqsB6pYIb7X9Ss2h_O1_t39zKQxWg8DiHN7OAW7 JocZaDljWYavCf1_I0Xu1zy0DbfQ8TF5r4pCA1.ucgk3MBkS5Jlsccu0vx7qatqpidf96oroKyho JYSk30SlZd7KTSuPVv5JFzWaRAfK1vXW5uzZ10z.uKJuE8fblqlN5NHHt9DgqUFe0Jni4cM0EXfA fvaBrvgUMmMz._TfXFRg9zh.z6n2EYRE8fwgb5lqjeRy5rdnKyeL48Qlls5UIHfsVUpgNy7oJary Dke8H.7_D5jS0f9Iwz8ruRMbGXtVvnMm0GJJ2Nus54iVTjVjXJYYwnznHMDtOrKBhHGZ2LDPhTOT 829lxDo5VROi.B1td_2iuYMQ4J82jBl1Y3cOOhf7ubJuPFhV6pVmxjhcfQXICseYm3BJRmSb4.TG lkEGuS3MckHXhfOhTUV3i4Hi.ZkZNwkuXLnS0_4Tx4noVPLp06ko.35VxSgsrunwLIX3XNWXqrjv rG4DP478LzQjwmrBiMuGU8cF.uVIqFjuRWhfsCoKkpAJHN.ztnWFYGUM0YwtqatXZtgwNfXNH.Kp PNU89bArF1LenKdy2yQNSwF7v5IBCieKMpnTX0OS0mEzNRf25zJ.s_qNKIHW8zEdSosrhIElq1Dk 60rw72rwpGsISx_LPbUMFbnSXgSIRmo5bByUKD3ULVPvJ.YMnRjvF0b4t.ONQZWFS1rYcHBsEFQY gC1zOgYEufruPeZIEBMkAbArll4rnpD1MDNPFBcuG3m75k07Sz8r5xW3.WTqlYeGpF2ogr.rPLaz ws4Si3lyQb3tytoBpBn0s20SvWVfYFfwUieZh9ZQuVcC_WyExtHSQTyo6DI5DseklmbwODTlXR0I h9JuFdKW3DNR7X3SofDajBt3EM_qO4VUtYmT1ay5qKLTpfRHSy9sSF0BXgWobNwoKn_6Y7r.vEHG y8udn3P81 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 11 Jan 2023 09:02:25 +0000 Date: Wed, 11 Jan 2023 09:02:24 +0000 (UTC) From: Alexander Pogodin To: "pgsql-admin@lists.postgresql.org" Message-ID: <1672715584.229208.1673427744060@mail.yahoo.com> In-Reply-To: <1254601719.7524472.1673277867599@mail.yahoo.com> References: <1254601719.7524472.1673277867599.ref@mail.yahoo.com> <1254601719.7524472.1673277867599@mail.yahoo.com> Subject: Re: Cascaded Replication question MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_229207_220967260.1673427744058" X-Mailer: WebService/1.1.20982 YMailNorrin Content-Length: 6447 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_229207_220967260.1673427744058 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So here are the results of my experiments done yesterday. On absolutely ide= ntical configs, the scheme given by me *does not* work on versions 10 and 1= 1, but it works fine from version 12 to 15. Important lines from the C serv= er log: - for version 10-11: postgresql-postgres-3-1 | 2023-01-10 15:42:15.922 GMT [32] LOG: restarted W= AL streaming at 0/3000000 on timeline 1 postgresql-postgres-3-1 | 2023-01-10 15:42:15.926 GMT [32] LOG: replication= terminated by primary server postgresql-postgres-3-1 | 2023-01-10 15:42:15.926 GMT [32] DETAIL: End of W= AL reached on timeline 1 at 0/3000060. - for versions starting from 12th: postgresql-postgres-3-1 | 2023-01-10 15:47:29.016 GMT [32] DETAIL: End of W= AL reached on timeline 1 at 0/3000060. postgresql-postgres-3-1 | 2023-01-10 15:47:29.016 GMT [32] LOG: fetching ti= meline history file for timeline 2 from primary server postgresql-postgres-3-1 | 2023-01-10 15:47:29.032 GMT [28] LOG: new target = timeline is 2 postgresql-postgres-3-1 | 2023-01-10 15:47:29.034 GMT [32] LOG: restarted W= AL streaming at 0/3000000 on timeline 2 Experiments were held in Docker Compose environment, hence such logs. Probably earlier versions require some additional setting adjusted, but at = the moment I don't have any idea. Best regards, Alex Pogodin.=20 On Monday, January 9, 2023 at 05:24:27 PM GMT+2, Alexander Pogodin wrote: =20 =20 Hello, guys! I have a setup with 3 PgSQL instances connected with streaming replication = as such: +---+=C2=A0=C2=A0=C2=A0=C2=A0 +---+=C2=A0=C2=A0=C2=A0=C2=A0 +---+ | A | <-- | B | <-- | C | +---+=C2=A0=C2=A0=C2=A0=C2=A0 +---+=C2=A0=C2=A0=C2=A0=C2=A0 +---+ When the link to A is broken, I manually promote server B and expect server= C to follow new timeline: I have recovery_target_timeline set to latest. B= ut that's not the case. To follow new timeline I have to restart server C. = Is it the designed behavior or am I missing something? I am using the latest 10.x version.=20 Could you, please, advise? Best regards, Alex Pogodin. =20 ------=_Part_229207_220967260.1673427744058 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So here are the results of m= y experiments done yesterday. On absolutely identical configs, the scheme g= iven by me *does not* work on versions 10 and 11, but it works fine from ve= rsion 12 to 15. Important lines from the C server log:

- for version= 10-11:
postgresql-postgres-3-1 | 2023-01-10 15:42:15.922 GMT [32] LOG: restarte= d WAL streaming at 0/3000000 on timeline 1
postgresql-postgres-3-1 | 202= 3-01-10 15:42:15.926 GMT [32] LOG: replication terminated by primary server=
postgresql-postgres-3-1 | 2023-01-10 15:42:15.926 GMT [32] DETAIL: End = of WAL reached on timeline 1 at 0/3000060.

- for versions sta= rting from 12th:
postgresql-postgres-3-1 | 2023-01-10 15:47:29.016 GMT [32] DETA= IL: End of WAL reached on timeline 1 at 0/3000060.
postgresql-postgres-3= -1 | 2023-01-10 15:47:29.016 GMT [32] LOG: fetching timeline history file f= or timeline 2 from primary server
postgresql-postgres-3-1 | 2023-01-10 1= 5:47:29.032 GMT [28] LOG: new target timeline is 2
postgresql-postgres-3= -1 | 2023-01-10 15:47:29.034 GMT [32] LOG: restarted WAL streaming at 0/300= 0000 on timeline 2

Experiments were held in Docker Compose environment, hence such = logs.

Probably earlier versions require some additional s= etting adjusted, but at the moment I don't have any idea.

Be= st regards, Alex Pogodin.


=20
=20
On Monday, January 9, 2023 at 05:24:27 PM GMT+2, Alexan= der Pogodin <alex_pogodin@yahoo.com> wrote:


Hello, guys!

I have a setup wit= h 3 PgSQL instances connected with streaming replication as such:

+---+=      +---+     +---+
|= A | <-- | B | <-- | C |
+---+     += ---+     +---+

When the link to A is broken, I manually promote server B and= expect server C to follow new timeline: I have recovery_target_timeline set to l= atest. But that's not the case. To follow new timeline I have to res= tart server C. Is it the designed behavior or am I missing something?

I am using the latest 1= 0.x version.

Could yo= u, please, advise?


Best regards, Alex Pog= odin.
------=_Part_229207_220967260.1673427744058--