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 1nHKXy-0007l1-AN for pgsql-admin@arkaria.postgresql.org; Tue, 08 Feb 2022 07:04:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nHKXw-0003fV-Qw for pgsql-admin@arkaria.postgresql.org; Tue, 08 Feb 2022 07:04:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nHKXw-0003fD-Fj for pgsql-admin@lists.postgresql.org; Tue, 08 Feb 2022 07:04:16 +0000 Received: from mail-pl1-x635.google.com ([2607:f8b0:4864:20::635]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nHKXt-0005cG-Pw for pgsql-admin@lists.postgresql.org; Tue, 08 Feb 2022 07:04:16 +0000 Received: by mail-pl1-x635.google.com with SMTP id w20so3844957plq.12 for ; Mon, 07 Feb 2022 23:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=MwKUka0KuHaKppKX1kv8Gpc6FuemL9conNizXW1nPc8=; b=HON3BnZ/xsPngK9PK5l+xB//U4O4ImhirxedBjmNzAclvqOeMgK/RbvewTSVIV6qIv NOw18yi3cBLQgom7z27WuiK5gJyNa0MsJKFovc8nHF881zeoABhEKaOLaTQWAY+DbryA I1wErGnio5/jOCI1ZAU5TtRWCsEC5OKNTaFa1whSlXxGrDoIhZkuQ630HkYOU3TIzr5p iq/ygHh2Z1WL0c0G9GtivXRfpB7NeZiCYBXApf7P8gspjUHqkXdQR9u5Z2mFn6J+1S8R bpS3lSKvi/MVPsgKt7T5z+CA3eJoTKzZQebDhIZhQjN7qVZH2H3V3anNYIQc5gem2Ybq Em+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=MwKUka0KuHaKppKX1kv8Gpc6FuemL9conNizXW1nPc8=; b=Mw8jIR4l4NQf5amQWeahbslsrmDyHJtzSucvYzKGVCrtjxLfRkxMNt2Kwpvs1m0pdT j/wnySEQHSjQCZiddDfpYCQ8zQyEwlgnlf/wWfIDvY5Mth+/vFbaFVKXuXWiJmZjjy/v +T2YoRSkxc8i3j6VCvS1PWSWYS5gyNdmTj80xk9KabH8wVkKAyTwR8M9FLBgQX8lL616 /p5Ek6hPLwN5vitKj/3N4/vg8f8/xYRwW205UL/sBVY1aNA/r6nbTtSbkTbc3BCzZywS to/lIbDEtKdaq33X86+Qnd4dU5XwB0FxqsdLyon+ygCNVUP+JkdyQMbYP1r2iCtqCuYi wjOA== X-Gm-Message-State: AOAM53113wp5L+FdeBdNtuT80zA0sutsHDDMsrt5ihmgph31Qy/0aSnn yTMgovi+z3M7/AYvuv4az7M= X-Google-Smtp-Source: ABdhPJyFfe+XEeqGv/Tg/Z8JCtbnCmX2Xthb09HF2YoyeWo6S/jvo9Vstz3zkp0QtCAwmK9vo+ZZLg== X-Received: by 2002:a17:90a:e557:: with SMTP id ei23mr2902228pjb.149.1644303851438; Mon, 07 Feb 2022 23:04:11 -0800 (PST) Received: from jrouhaud (2001-b011-1005-1017-e46d-c4cf-ba2a-3e05.dynamic-ip6.hinet.net. [2001:b011:1005:1017:e46d:c4cf:ba2a:3e05]) by smtp.gmail.com with ESMTPSA id l8sm15019026pfc.187.2022.02.07.23.04.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Feb 2022 23:04:08 -0800 (PST) Date: Tue, 8 Feb 2022 15:04:04 +0800 From: Julien Rouhaud To: Nikhil Shetty Cc: Victor Sudakov , Pgsql-admin , pgsql-admin Subject: Re: Lost replication slots after pg_upgrade. Message-ID: <20220208070404.d2dizlt6nvz2g3og@jrouhaud> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Tue, Feb 08, 2022 at 12:24:56PM +0530, Nikhil Shetty wrote: > > I am doing a major version upgrade from pg 11 to 13. The point is if I lose > the replication slot after upgrade then how will I sync standby from > primary after rsync. > > I can create the slot after upgrading but won't there be dataloss? The replication slots are only there to make sure that the primary server won't remove needed WALs before the standby can retrieve them. Unless you start production activity just after the pg_upgrade and before finishing rebuilding the secondary there shouldn't be enough activity to lead to removing old WALs. But if you do, you can create the needed replication slot(s) manually just after the pg_upgrade. But as already mentioned, I also recommend using pg_basebackup for rebuilding the standby server(s). > pg_basebackup takes time for large databases (> 5TB). I feel rsync should > be faster. Not necessarily. pg_basebackup will do simple sequential read of all the data, which is probably the fastest thing to do. rsync will do some extra processing that isn't required in that scenario, so it's likely to be slower (although probably only marginally slower).