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 1tYguR-00D7kC-9Y for pgsql-general@arkaria.postgresql.org; Fri, 17 Jan 2025 07:36:53 +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 1tYguP-00AMez-Or for pgsql-general@arkaria.postgresql.org; Fri, 17 Jan 2025 07:36:50 +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 1tYguP-00AMeq-9w for pgsql-general@lists.postgresql.org; Fri, 17 Jan 2025 07:36:49 +0000 Received: from fw.sz-a.kwebs.cloud ([109.61.102.40]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tYguM-000u30-2w for pgsql-general@lists.postgresql.org; Fri, 17 Jan 2025 07:36:49 +0000 Received: from webmail.srv.kwebs.cloud (172-16-36-105.prometheus-node-exporter.monitoring.svc.cluster.local [172.16.36.105]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) (Authenticated sender: richard@kojedz.in) by mx.kwebs.cloud (Postfix) with ESMTPSA id CD5A8E97F for ; Fri, 17 Jan 2025 07:36:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kojedz.in; s=s02; t=1737099404; bh=hvypVVUZr9qYBFVR7Gt8bOlhY+uuDPVtFoFD9nIXPGY=; h=Date:From:To:Subject; b=s/vAJHL35gI/Z3ZuiDj5yXJikr8C5wDgGD98FX3LQQHTLD32SS8xIgd/Qtqhr2ADU CDhKIpY7CQc70245+Zt42xU9cuEH7li9hkJYjWNbjdoRedbYJloX1Qi2s/JIcCjxrG cY2PUUsDJsUTlAVHcbHmJsakKO08CZyebyMZkG1Zoc6PsSbxqO5916kPLK7ZpsJH/F uhhUHQvCV7eTSpIlnLI+dlMOfqZ/L2xV+/XWpHAOIcljUGV2So1tCFOCEDmbSooVta rXQH/3sDdDBADNJQnvVsHQfZ8o+e7Und8x6/baFO4h0VUliOp5JR5yieFAT3turjdG eGP55lGkHCadg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kojedz.in; s=s01; t=1737099404; bh=hvypVVUZr9qYBFVR7Gt8bOlhY+uuDPVtFoFD9nIXPGY=; h=Date:From:To:Subject; b=YBBHyC9FKrT45swLlA8vqfz8OZsBC65FiWRVUeHp2LZhwAInUCuQYSCoI813KXxPI pGxiiKvXNK0GMJA7T/DFGW5hyqO+lEH+RA2mr+RnSSN06MuCjSwjgpO0T7FE96a0d0 ILQwZeAk7Aa1qWHeeG/V7EATEFsc/TLlFizAvND6W9rhXVAEjk13T+qCIDhsxBSwHG 50y04sQoqreR2pWtH1m+EcQHcIgK+n5BtZL9H3EtTzUQjTaLK9OdE7y9cAOX8YGrbh +GCy1M5YOJTw+kee2FwgC1PMfk4MNEYZsj/2jVMvqQD0HYGILRJnAnnOdX3DoJh//6 CHdD1OiDZ9tQWnjsfz2D/Fext2LKEBHdU1TL/9fQHe5tvM1lRizGqwujgR04XljWcY yamb8EdHZ1g+7eZiWnMWr34L+j27r5YMOad64u0ZDS8vcUnAJ9Rc1L3wunUIUJDuiA XdHIYIxvPHhXYsc9N2ox79XcQu6oKza4FCoASQmUt19FbZbdD7z MIME-Version: 1.0 Date: Fri, 17 Jan 2025 08:36:44 +0100 From: richard@kojedz.in To: pgsql-general@lists.postgresql.org Subject: In-place upgrade with streaming replicas Message-ID: <12ebc478cd4dac5357c61b93d53ef8a4@kojedz.in> X-Sender: richard@kojedz.in Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Dear All, I am trying to follow instructions regarding in-place upgrade with streaming replica servers. The documentation here: https://www.postgresql.org/docs/13/pgupgrade.html#:~:text=Prepare%20for%20standby%20server%20upgrades says that I should check 'Latest checkpoint location' in primary and replica servers. Now, I want to make this process automatic, so I would like to know a reliable way to make checkpoint locations match surely. During the automated upgrade procedure, I restart all servers on a different tcp ports, thus no legitim clients connect to primary, and thus they dont make any changes. Then, I issue CHECKPOINT on primary, retrieve pg_current_wal_lsn() on primary, and wait until all replicas report the same value in pg_last_wal_replay_lsn(), then I issue a CHECKPOINT on replicas. According to documentation this creates a RESTOREPOINT on replicas. Then, I repeat until pg_current_wal_lsn() does not change on primary. Then, if I shut down cluster in a way that first the primary is shut down, and just after the replicas, then, checkpoint locations will match. Howewer, if I accidentally shut down a replica before primary is shut down, the checkpoint locations wont match. With this, I have the question, that after the shutdown of primary, what is the guarantee for replicas having the same checkpoint location? Why does the order of shutting down the servers matter? What would be the really exact and reliable way to ensure that replicas will have the same checkpoint location as the primary? Thanks in advance, Richard