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 1tFFm2-00C8Xv-7r for pgsql-general@arkaria.postgresql.org; Sun, 24 Nov 2024 16:47:50 +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 1tFFm0-008TaA-MZ for pgsql-general@arkaria.postgresql.org; Sun, 24 Nov 2024 16:47:48 +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 1tFFm0-008Ta2-9h for pgsql-general@lists.postgresql.org; Sun, 24 Nov 2024 16:47:48 +0000 Received: from mail-ot1-x332.google.com ([2607:f8b0:4864:20::332]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tFFly-003cjL-2h for pgsql-general@postgresql.org; Sun, 24 Nov 2024 16:47:47 +0000 Received: by mail-ot1-x332.google.com with SMTP id 46e09a7af769-71a6b13bbceso1436496a34.1 for ; Sun, 24 Nov 2024 08:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732466863; x=1733071663; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=GUpWUISZ+kyCNlrcQtN7o550vHDiB3FjCW5pAv9Rh4Q=; b=g4DGA2YPSfOa+2g6MXOZ1E00MIMJwwvQdLtsfj3AjQuQn3DNWCj7TRwsb5IMzqQlbu u5iGcDooAhO+Zu39/Zf+XUjs9Pru/jmkPDQev3C8zRVFmqeK+JtykqHSOihF/UeNfEwK iQzqNgKQ3TCNHNQx06aBmoST/KGhCw/HjUXntX5Hy7ShY/a10a6yf2Ioh8QuZxX6DeE8 XU4b6LRDZJmtUNFPFleCloTakngYvqA+Bmu6vtEV3jvClVRiHtySP+0ocG6qsinal4MK TPvKUNb6AbBLJXHHe6xsMVp+itOytcSz/adBgrQE6PwqXZ5DCM8fzgmZqXSHCXmHBAHI 50/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732466863; x=1733071663; h=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=GUpWUISZ+kyCNlrcQtN7o550vHDiB3FjCW5pAv9Rh4Q=; b=dNVr423fOlYpm2anjOBSEbRyvRoyktOBtWSShT4xwbEy6wlUJkvsEPFhpriEt7Mzdl IuHF2rEDuP/je7FwB5PQuGGYHi0gARWqaG5umL4pxJO7651tUdjaYpSRJBQOwxPU7qy+ kukdMcdJh8pBzysjxaBDAy0y5icU7/kEV9QCvFIDSAu+rX8NmnSvlWo1ufxUbdxiQehy 5mGN8QJYxEH3X3IITjdN/axhlxkwl0hVJT+0ATYKX8p6fmLG5mZbyscP/p2VJHtLT/Vm /ob/jdipQ9T9u4+zDrMOObmtxrSW3OmBXJ8Pxh2fZv2LHfK2luv7SD1SNRxClFlr8xFG e2Mw== X-Gm-Message-State: AOJu0YyrvpXzmgbRyhUVUpqaPd08M07BTgm/1TmkYYppxOCa8CM1YyD0 QpCmOXmk3U83gYSpepG3oyPWopz65gWT+liEmifF22XZo62qublQWF537iPZilZ/U7Dk68kIxAf rAIiF/ZK+IoTl6VSwwJ1ycmhx+n6EOg== X-Gm-Gg: ASbGncsTDR6n6cjx+fCf7fvrVi5ncK/s6WEJcffqXdXpf90NiJ4aNd2Nn1ftGdgYQlT QW3k5bC2pVzJOy1XFsxcv7q03l1T6OzFxOcAkVXFDYFpFEPIThVlWcdWENy0ZeG96cg== X-Google-Smtp-Source: AGHT+IFN0YIqCFZSG+rGg5rGEDIUQmIcmNncFCNgWKlW/fP+XoWysmM5xSJfL1tfx7v7gky8O4GLyILCDob9afhE6CE= X-Received: by 2002:a05:6830:65c6:b0:71d:4150:9e5e with SMTP id 46e09a7af769-71d4150a358mr2425278a34.2.1732466863389; Sun, 24 Nov 2024 08:47:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Sun, 24 Nov 2024 11:47:32 -0500 Message-ID: Subject: Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000fa401d0627ab5f4c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000fa401d0627ab5f4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 24, 2024 at 11:05=E2=80=AFAM Subhash Udata wrote: > Dear PostgreSQL Community, > > I have a production database setup with a primary server and a standby > server. The database is currently running on *PostgreSQL 15.0*, and I > plan to upgrade both servers to *15.9*. > > I have the following questions regarding the upgrade and replication > process: > > 1. > > *Upgrade and Replication Compatibility*: > - My plan is to perform a failover, promote the standby server > (currently 15.0) to primary, and then upgrade the old primary serve= r to > version 15.9. > > Try to replicate from old->new version, because bug fixes in newer versions might have broken something in new->old replication. If you really can't tolerate any downtime, then shutdown and upgrade the Secondary server from 15.0 to 15.10. Once you start it back up, replication from the still-15.0 primary will catch back up to the now-patched Secondary. Fail over to the Secondary (now new-Primary), and then patch old-Primary to 15.10. > > 1. > - After upgrading the old primary server to version 15.9, I want to > configure it as a standby server and set up streaming replication w= ith the > new primary server, which will still be running version 15.0. > - Is it possible to establish streaming replication between these > two versions (*15.0* as primary and *15.9* as standby)? > 2. > > *Efficient Replication Setup*: > - The production database is around *1TB in size*, and creating > replication using pg_basebackup is taking more than 2=E2=80=933 hou= rs to > complete. > - Is there an alternative method to set up replication without > taking a full backup of the entire cluster but instead using only t= he WAL > files that have changed on both servers? > > pg_rewind is probably what you want. I've never used it, though. --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000fa401d0627ab5f4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Nov 24, 2024 at 11:05=E2=80=AFAM = Subhash Udata <subhashudata@gm= ail.com> wrote:

Dear PostgreSQL Community= ,

I have a production database setup with a primary server and a stan= dby server. The database is currently running on PostgreSQL 15.0, and I plan to upgrade both servers to 15.9.

= I have the following questions regarding the upgrade and replication proces= s:

  1. Upgrade and Replication Compatibility:

    • My plan is to perform a failover, promote the standby server (curr= ently 15.0) to primary, and then upgrade the old primary server to version = 15.9.

Try to repl= icate from old->new version, because bug fixes in newer versions might h= ave broken something in new->old replication.

I= f you really can't tolerate any downtime, then shutdown and upgrade the= Secondary server from 15.0 to 15.10.=C2=A0 Once you start it back up, repl= ication from the still-15.0 primary will catch back up to the now-patched S= econdary.

Fail over to the Secondary (now new-Prim= ary), and then=C2=A0patch old-Primary to 15.10.
=C2=A0
    • <= li>After upgrading the old primary server to version 15.9, I want to config= ure it as a standby server and set up streaming replication with the new pr= imary server, which will still be running version 15.0.
    • Is it possi= ble to establish streaming replication between these two versions (= 15.0 as primary and 15.9 as standby)?
  1. Efficient Replication Setup:

    • The prod= uction database is around 1TB in size, and creating replic= ation using pg_basebackup is taking more than 2=E2=80=933 hour= s to complete.
    • Is there an alternative method to set up replication= without taking a full backup of the entire cluster but instead using only = the WAL files that have changed on both servers?
<= /blockquote>

pg_rewind is probably what you want.=C2=A0 = I've never used it, though.

--
Death to <Redacted>, and butter sauce.
Don&#= 39;t boil me, I'm still alive.
<Redacted> lobster!
--000000000000fa401d0627ab5f4c--