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 1jkmvb-0007cV-C4 for pgsql-novice@arkaria.postgresql.org; Mon, 15 Jun 2020 11:05:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jkmva-0005Or-4M for pgsql-novice@arkaria.postgresql.org; Mon, 15 Jun 2020 11:05:22 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jkmvZ-0005Ok-Hb for pgsql-novice@lists.postgresql.org; Mon, 15 Jun 2020 11:05:21 +0000 Received: from sender4-op-o12.zoho.com ([136.143.188.12]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jkmvT-0000vL-3Y for pgsql-novice@postgresql.org; Mon, 15 Jun 2020 11:05:20 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1592219112; cv=none; d=zohomail.com; s=zohoarc; b=LYvEs2Lo7ll8GNf5LtXmYO9x07Nrn9yZ6ZNtbv9iqGPP1oBSlyk7yLUxmFvbzLoqzjbkWKPgPeprH0N2oe5ZNt8D2o7aS4nyvEkqefMJ0SMBZySUut6VPGBQQ+UgAe3kaLOWP2nOe8X+6U03vv9FBVKD+DkLQwF+qdTnegtDHyg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1592219112; h=Content-Type:Cc:Date:From:MIME-Version:Message-ID:Subject:To; bh=GoJYABNGFWUUruVenPiQbIuARIP2/vqETZ+Uq/hcn4M=; b=ePbyc+5LW8OzfvEswTX7CXgkH2VXRG3yVwudtY0+qr/+Ofk+Ae7LBqgXZiBhkZAE7zO9jkYcV4PXqJkGmCcF036GgzgJXIna9eeVacn4MnaZuGRhRv4NyubA6V4fhN9VI51nHNB2DohocBt07RPxmzd7+jaLvxARsV5uzJFzu20= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=zohocorp.com; spf=pass smtp.mailfrom=manojkumar.krishnamurthy@zohocorp.com; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1592219112; s=admin; d=zohocorp.com; i=manojkumar.krishnamurthy@zohocorp.com; h=Date:From:To:Cc:Message-Id:In-Reply-To:Subject:MIME-Version:Content-Type; bh=GoJYABNGFWUUruVenPiQbIuARIP2/vqETZ+Uq/hcn4M=; b=SI3TbCuf4+DYW9/ocIP2OdPPu82xJoz7XxXPp4U0wTiw12THtfxhi4S7IymtnUiW SWjVsfzM5dKpOBSdbAgm76++x3lMguyFycHnPWrIJAAuw/vZpCmCgJuEJ4nP6kAxSU8 Rj/y5VgQMLSl9aE/dv9VOSv6nHNqQLKfimU4HJJw= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1592219111879265.4966750837143; Mon, 15 Jun 2020 04:05:11 -0700 (PDT) Date: Mon, 15 Jun 2020 16:35:11 +0530 From: Manojkumar S To: "pgsql-novice" Cc: "Srivathson KK" Message-Id: <172b7a791bd.121388bfb22150.5969883832378040935@zohocorp.com> In-Reply-To: Subject: ".partial" WAL file missing while promoting database in streaming replication. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_78693_1816060714.1592219111870" Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------=_Part_78693_1816060714.1592219111870 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hello, OS : Windows and Linux Version : 10.7 and 11.7 Topic : Streaming Replication I use streaming replication in async mode. When master gets down, slave will be promoted using a trigger file. During this process, a ".partial" file will be created and a WAL file with the same ID will be created in a different timeline in slave (to be promoted as master). When master comes back as slave, it will be synced to the current master. This is the normal procedure as far as I understood. But in some cases, ".partial" file is not getting created and peer DB which comes back as slave is unable to sync whenever this happens.. So, basically databases go out of sync when the ".partial" file is not created . Please suggest if this happens in any scenario and how to overcome this. Thanks and Regards, Manoj Kumar. ------=_Part_78693_1816060714.1592219111870 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit
Hello,

OS : Windows and Linux
Version : 10.7 and 11.7
Topic : Streaming Replication

I use streaming replication in async mode. When master gets down, slave will be promoted using a trigger file. During this process, a ".partial" file will be created and a WAL file with the same ID will be created in a different timeline in slave (to be promoted as master). When master comes back as slave, it will be synced to the current master. This is the normal procedure as far as I understood.

But in some cases, ".partial" file is not getting created and peer DB which comes back as slave is unable to sync whenever this happens.. So, basically databases go out of sync when the ".partial" file is not created . Please suggest if this happens in any scenario and how to overcome this.

Thanks and Regards,
Manoj Kumar.




------=_Part_78693_1816060714.1592219111870--