Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tVnar-00BXqA-2e for pgsql-admin@arkaria.postgresql.org; Thu, 09 Jan 2025 08:08:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tVnap-00Einf-MJ for pgsql-admin@arkaria.postgresql.org; Thu, 09 Jan 2025 08:08:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tUx0J-00EuAw-UN for pgsql-admin@lists.postgresql.org; Mon, 06 Jan 2025 23:59:27 +0000 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tUx0G-000FWd-2Q for pgsql-admin@postgresql.org; Mon, 06 Jan 2025 23:59:27 +0000 Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-540215984f0so15494559e87.1 for ; Mon, 06 Jan 2025 15:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736207964; x=1736812764; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SeaTjnpcskSZwYji7DPmQayAvz6XMLJWR826mhrRxuE=; b=Sxtfed0bf7wT/EOH++tNu2Rv7acDO52XtO/qSyM9qnB38BpKmfjnWY9Ok/5p6ouZtD V6+bLei9Yj4AJjkJ+JdwLx2R3M7Lge+GsFh1Lx4/eqKyyRVTlUl5FwLbemKuBtlt54QR RWlc94FTpf38I+wKUfXqqDzXs6uyE6HhUNArTEPJOLZ3+E8fFEJBJiohepKVdV2yTKL3 Mq5+2OXZ/BiBtq/6oihUdIUl0Hq8kjPH1Fw4L5BoBd7NqJcru6OeM5RX7UmgYjonnjhQ 9t8CD53indyKdIv3BAUXrCgqlDE2E5T0lM3Fbwucq9sisi7E4q8nXMpPeo2grfkB2OVM /GKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736207964; x=1736812764; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SeaTjnpcskSZwYji7DPmQayAvz6XMLJWR826mhrRxuE=; b=mzz6z7Dr/MlLeQRsdc8NIjY4Ld4s9YygV6bu2N0Ih4SzhcBPVUykmTr/16rXIPXcj+ nCnlaza+c7cupIWh46bZtnkaCXrYlE4KXOXHG8LGOtGxD3N6171da4n0mYrvKZi+BedT +NYLTwW3K94nghHiAOlIoGxAyw+AQ9wdhFBtTp2lAMT1K0sCoQ62TIj8793VXrRgY2xB TlIT/jTVUlWtcV2hcp5aOCBP2HsyS0yR7Kn4zPjVONWnregFwDYMqBdboASXy0/+62UI QtaBZnjRmDgxWonl5m6miFKuYJD1oOKpg0w0J3VAAwRQFfQzy6xhzXTgcGVav9xCPGGJ /2mw== X-Gm-Message-State: AOJu0YzTEjq7M8q1DiHQDUMVAn4bySvNDZQ7Sm1y7XBpWYbfKeEt2Phu 8Qpz//ucA6TpBjgP3tH3ZhAN/yLm+LO3QBAU3IYCYfs3yHw5+P9zLftXJvcdq4IFeSQNK8tM6Rr /jYHCv9bYG6EeVrAAEPiQzgckYF8rpQ== X-Gm-Gg: ASbGnct/bAQ5soHwzaUR8Zr9CkA94Vz0YC7e2u4I/OSUufCZHa/EOjhJff1gGAdlKO6 8GdQwanTbvm2ZNdxn+OfGhFpTtEgLBez5F4MShA== X-Google-Smtp-Source: AGHT+IHdgvtQzWzdXazMEIVEK+1fAYMlUFbzAy/EcY/lIA93t0m/MRs4x6VLiUaAJKcDHq78sllBoevXr3MoBLqg15I= X-Received: by 2002:a05:6512:4026:b0:542:28b4:2732 with SMTP id 2adb3069b0e04-54229539f7amr16008297e87.19.1736207963877; Mon, 06 Jan 2025 15:59:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: kasem adel Date: Tue, 7 Jan 2025 01:59:10 +0200 Message-ID: Subject: Re: Advice Needed: Simultaneous Upgrade of Two-Node PostgreSQL 11 Cluster To: Laurenz Albe Cc: pgsql-admin@postgresql.org Content-Type: multipart/alternative; boundary="000000000000f17b3a062b126ae0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f17b3a062b126ae0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Laurenz Albe Our application for reporting is dependent on the replica node for handling read-only operations. If we proceed with the proposed changes, it would result in a one-month application downtime, which would significantly impact our operations and is not a feasible option for us. We would greatly appreciate your insights and support in identifying alternative solutions to minimize down time (one month)or another solution alternative for rebuild replica from scratch. Your expertise and advice would be invaluable in helping us navigate this challenge effectively. Thank you for your time and assistance. =D9=81=D9=8A =D8=A7=D9=84=D8=A7=D8=AB=D9=86=D9=8A=D9=86=D8=8C =D9=A6 =D9=8A= =D9=86=D8=A7=D9=8A=D8=B1 =D9=A2=D9=A0=D9=A2=D9=A5 =D9=A7:=D9=A1=D9=A3 =D9= =85 Laurenz Albe =D9=83=D8=AA=D8=A8: > On Sun, 2025-01-05 at 19:57 +0200, kasem adel wrote: > > Proposed Upgrade Approach: > > > > Simultaneous Upgrade Process: > > > > Install new PostgreSQL version packages on both nodes > > Run pg_upgrade with --check flag on both nodes > > Execute pg_upgrade with --link option on both nodes simultaneously > > Update Patroni configuration for new version on both nodes > > No, that won't work. > > You have to upgrade the primary, then rebuild the standby with > "patronictl reinit". There is no safe way to upgrade the standby. > > Yours, > Laurenz Albe > --000000000000f17b3a062b126ae0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear=C2=A0Laurenz Albe

Our applicatio= n for reporting=C2=A0 is=C2=A0 dependent on the replica node for handling r= ead-only operations. If we proceed with the proposed changes, it would resu= lt in a one-month application downtime, which would significantly impact ou= r operations and is not a feasible option for us.

We would greatly ap= preciate your insights and support in identifying alternative solutions to = minimize down time (one month)or another solution alternative for rebuild r= eplica from scratch. Your expertise and advice would be invaluable in helpi= ng us navigate this challenge effectively.

Thank you for your time an= d assistance.


=D9=81=D9=8A =D8=A7=D9=84=D8= =A7=D8=AB=D9=86=D9=8A=D9=86=D8=8C =D9=A6 =D9=8A=D9=86=D8=A7=D9=8A=D8=B1 =D9= =A2=D9=A0=D9=A2=D9=A5 =D9=A7:=D9=A1=D9=A3 =D9=85 Laurenz Albe <laurenz.albe@cybertec.at> =D9= =83=D8=AA=D8=A8:
On Sun, 2025-01-05= at 19:57 +0200, kasem adel wrote:
> Proposed Upgrade Approach:
>
> Simultaneous Upgrade Process:
>
> Install new PostgreSQL version packages on both nodes
> Run pg_upgrade with --check flag on both nodes
> Execute pg_upgrade with --link option on both nodes simultaneously
> Update Patroni configuration for new version on both nodes

No, that won't work.

You have to upgrade the primary, then rebuild the standby with
"patronictl reinit".=C2=A0 There is no safe way to upgrade the st= andby.

Yours,
Laurenz Albe
--000000000000f17b3a062b126ae0--