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 1uWJH2-00C2lS-8v for pgsql-admin@arkaria.postgresql.org; Mon, 30 Jun 2025 18:30:36 +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 1uWJGz-001Uq4-Ic for pgsql-admin@arkaria.postgresql.org; Mon, 30 Jun 2025 18:30:34 +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 1uWJGz-001Upr-84 for pgsql-admin@lists.postgresql.org; Mon, 30 Jun 2025 18:30:33 +0000 Received: from cc-smtpout3.netcologne.de ([89.1.8.213]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uWJGx-004x8q-1y for pgsql-admin@lists.postgresql.org; Mon, 30 Jun 2025 18:30:33 +0000 Received: from cc-smtpin3.netcologne.de (cc-smtpin3.netcologne.de [89.1.8.203]) by cc-smtpout3.netcologne.de (Postfix) with ESMTP id 2690011EFB for ; Mon, 30 Jun 2025 20:30:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1751308230; bh=wu12oKZK8wbxFPGoHBMr/O0fKYBdO6xBbL41QmNRGXA=; h=Message-ID:Date:Subject:To:References:From:In-Reply-To:From; b=DgE9eCZvEc6Z36THN8SzmsAVzmiB2WOkDG3MxObI3Z+DOrUuFqXP+axNuylDnAusk H6Rp6/z1VWBUhTGSGhx5nTBftMb4RiFGIIuOp78mqZq8EspAyJyfn0cYzgGBLGJslW LOGSMAlAw4StqAJrpB0dbkp4C26F1pgN30l+tmCOYY/mfBMnFljUwAO3cDTw3l2QM2 no+fW9GAOMFZLISvO1AyRQ8pSlgO1skka/9Fy8uv90QvZxOxtaQJxKRFTQ5fH74WGC ZdAb/fAbCdQIpizZuXr15SZontzpas9x8eFc5UpSkDZbqrS3MkEPPCH57xAfBCwenY y7jxdwMkos90w== Received: from [IPV6:2a03:b580:afbb:9101:c452:7d7e:87de:9de9] (unknown [IPv6:2a03:b580:afbb:9101:c452:7d7e:87de:9de9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin3.netcologne.de (Postfix) with ESMTPSA id DE82D11D77 for ; Mon, 30 Jun 2025 20:30:29 +0200 (CEST) Message-ID: <481ee580-ba4b-445d-bf35-7bee976543b4@netcologne.de> Date: Mon, 30 Jun 2025 20:31:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Replication and Switchover To: pgsql-admin@lists.postgresql.org References: Content-Language: en-US From: vrms In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-NetCologne-Spam: L X-Rspamd-Queue-Id: DE82D11D77 X-Spamd-Bar: - X-Rspamd-Action: no action List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk just to remind myself about the 'switchover' process ... in such a case as the on at hand here there is no ambition to actually switch and replicate back to the original main, but rather use replication mechanics the 'clone' the cluster (or in your case part of it), right? In order to 'untie' the cloned cluster you would   1. stop the replica   2. remove the standby.signal file from the replicas $PGDATA   3. delete the postgresql.auto.conf  on the replica   4. start the replica anew ... is that a fair assumption? Or is the above more or less what "SELECT pg_promote() ;" does? I guess #3 might not even be a hard requirement as it is being ignored in absence of a standby.signal On 06.06.25 16:45, Sam Stearns wrote: > Howdy, > > We have 2 databases running out of a single database cluster.  We > would like to set up replication from the existing host to a new host > and then switchover to that new host.  One of the databases is ready > to switchover now while the other database is going to take a bit more > time to be ready for the switchover. > > We would like to switchover the database that is ready now so we can > start performing load testing against it.  Is it possible to > switchover one database in a cluster while not switching over the other? > > Thanks, > > Sam