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 1tkjVw-006L7o-9a for pgsql-admin@arkaria.postgresql.org; Wed, 19 Feb 2025 12:49:21 +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 1tkjVu-0089Bs-RA for pgsql-admin@arkaria.postgresql.org; Wed, 19 Feb 2025 12:49:19 +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 1tkjVu-0089A9-Ad for pgsql-admin@lists.postgresql.org; Wed, 19 Feb 2025 12:49:18 +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 1tkjVr-001lI6-2W for pgsql-admin@lists.postgresql.org; Wed, 19 Feb 2025 12:49:18 +0000 Received: from webmail.srv.kwebs.cloud (172-16-36-102.prometheus-node-exporter.monitoring.svc.cluster.local [172.16.36.102]) (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 011B3B583 for ; Wed, 19 Feb 2025 12:49:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kojedz.in; s=s02; t=1739969353; bh=hvypVVUZr9qYBFVR7Gt8bOlhY+uuDPVtFoFD9nIXPGY=; h=Date:From:To:Subject:In-Reply-To:References; b=UGQKONnLtQ4hipBZT0OQScFe5ROHTWFlcxy8qSw77q2rzxGpsB4mNm3ejMRMO5HNi DQ1oR0xSNvX46NDnPBuv0TzvIQgF+Zedf5KgzWyLxxP70Mvvf7V6eZYlgiAhhyxYCX 9s5ZnxRYj8l1wQpXAmEoGSBtP2orWHw9W9z8DgVtmnR+W+osMRayVH4FfTLJSNKG8P Gd6AwGlPjCb0sx9xdJGfdmI3WFX4ooo0f3UCS3Xvj+QA14VlKBMBvUXyXzt8mUzMJU t2J+uLzvZ3xvyrAzdy8t0tGpOudqThS+IbzZEpRbBIjqF1Q2jUSCf+dJIDEnNKj4IR O2GmZScefVvCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kojedz.in; s=s01; t=1739969353; bh=hvypVVUZr9qYBFVR7Gt8bOlhY+uuDPVtFoFD9nIXPGY=; h=Date:From:To:Subject:In-Reply-To:References; b=pQb4vaycg0e5xQxfKGbmXGhZPeYrhb0oJUX2r8+GLqvbZ9nq4qcIb2ClORDU5eC0S UcZVDHW2ZArtKrk9fJ7oQwtRrmgOKs/t5J32Mx7j/SA49HPfXBuB++vcYMhoc5fdq7 3ullvYD0H+Jk2huLtbHiq/YTNGL7HACx3qRnRHOsxJ/TTtAOZRWyGQbz1RPHXRKtk2 c4fXo3GVbdZC9fIHUFHj74ycy1RLaewZ14518ldGwsL5a47CfbBQ7/rmVkm05GTUgW T10P19Ix9VUWdOV99enqke9Gk8ZtoglpC+K4/NJ6uyYZAdXw4vFLhTBWudZE242ZnO HpzQNC/DD6nUZ4RS+hqED6Qf3wtPD0ycfp9W8kYmPjjoTyUirhXW0URGuU+RGzNiw5 MXJcAPWeq3wo9uGeA4469biZlsaBveJJYpSzKLQzkkYQQ21Qk49QfpA/HlVIRG5hg2 cYIYBcBl4AVIgUOGHA+/4CpFqgSaPjnALFFenbEO2c7tjM7NDeO MIME-Version: 1.0 Date: Wed, 19 Feb 2025 13:49:12 +0100 From: richard@kojedz.in To: pgsql-admin@lists.postgresql.org Subject: In-place upgrade with streaming replicas In-Reply-To: <12ebc478cd4dac5357c61b93d53ef8a4@kojedz.in> References: <12ebc478cd4dac5357c61b93d53ef8a4@kojedz.in> Message-ID: 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