Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aoERc-0001L6-2K for pgsql-admin@arkaria.postgresql.org; Thu, 07 Apr 2016 18:14:16 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1aoERb-0001R4-8x for pgsql-admin@arkaria.postgresql.org; Thu, 07 Apr 2016 18:14:15 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1aoERa-0001QW-FT for pgsql-admin@postgresql.org; Thu, 07 Apr 2016 18:14:14 +0000 Received: from gw-mail1.roc.in.bccnetworks.net ([184.12.4.101]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1aoERX-0008FM-9D for pgsql-admin@postgresql.org; Thu, 07 Apr 2016 18:14:13 +0000 Received: from localhost (localhost [127.0.0.1]) by gw-mail1.roc.in.bccnetworks.net (Postfix) with ESMTP id 8077844F3DB4 for ; Thu, 7 Apr 2016 14:14:09 -0400 (EDT) Received: from gw-mail1.roc.in.bccnetworks.net ([127.0.0.1]) by localhost (gw-mail1.roc.in.bccnetworks.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Kd85BKCLdOUj for ; Thu, 7 Apr 2016 14:14:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by gw-mail1.roc.in.bccnetworks.net (Postfix) with ESMTP id 7BD8A44F3DB9 for ; Thu, 7 Apr 2016 14:14:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at bccglobal.com Received: from gw-mail1.roc.in.bccnetworks.net ([127.0.0.1]) by localhost (gw-mail1.roc.in.bccnetworks.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9_maqdAAJKe4 for ; Thu, 7 Apr 2016 14:14:07 -0400 (EDT) Received: from gw-mail1.roc.in.bccnetworks.net (localhost [127.0.0.1]) by gw-mail1.roc.in.bccnetworks.net (Postfix) with ESMTP id 61A2B44F3DB4 for ; Thu, 7 Apr 2016 14:14:07 -0400 (EDT) Date: Thu, 7 Apr 2016 14:14:07 -0400 (EDT) From: Peter =?utf-8?Q?Brunnengr=C3=A4ber?= Reply-To: Peter =?utf-8?Q?Brunnengr=C3=A4ber?= To: pgsql-admin@postgresql.org Message-ID: <2112705921.1067.1460052846289.JavaMail.pbrunnen@Station8.local> In-Reply-To: <1469200611.1054.1460051752072.JavaMail.pbrunnen@Station8.local> Subject: postgres wal sender replication timeout during pg_basebackup MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.6.0_GA_1194 (Zimbra Desktop/7.2.7_12059_Mac) Thread-Topic: postgres wal sender replication timeout during pg_basebackup Thread-Index: GSABVlQwmx3iG2U3/uH9HXggBsBY3g== X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org Hello all, I had posted this to dba.stackexchange but haven't gotten any responses, so I thought the list here may be more focused and have a better shot to post this. I'll start by noting that I am still somewhat green with Postgres... One of our applications requires it, so I have been learning as I go... Right now I am working on a postgres 9.2 Active/Standby cluster on Debian wheezy to make the application more fault tolerent, based off of the ClusterLabs pgsql cluster documentation [http://clusterlabs.org/wiki/PgSQL_Replicated_Cluster]. In the lab, I am able to get this setup and working without a problem; But on the pre-production cluster, I keep running into a wal sync error. I brought the database files over from the current single production postgres server. By this I mean I shutdown postgres and tar-ed up the data directory and copied it over the the cluster's Master node. I put the files in place, set the permissions, and was able to start-up postgres on the Master via corosync just fine. In preparing the slave, I used the pg_basebackup tool to bring the database over from the Master and this is where I keep having issues. As it is transferring, at about 57% I see the error: > $ pg_basebackup -h db-master -U u_repl -D /db/data/postgresql/9.2/main/ -X stream -P > pg_basebackup: could not receive data from WAL stream: SSL connection has been closed unexpectedly > 176472/176472 kB (100%), 1/1 tablespace > pg_basebackup: child process exited with error 1` And on the server, I see: > 2016-04-06 21:05:31 UTC LOG: terminating walsender process due to replication timeout But the transfer doesn't stop and keeps going to completion. I found this [http://dba.stackexchange.com/questions/59916/streaming-replication-log-is-puzzling-me] question on stackexchange about setting "ssl_renegotiation_limit" to 0, but this didn't make much difference. Anyone have any ideas? I didn't find any reference to this problem in the mailing list archives. I am completely baffled as to why this would error, but keep on going. Maybe this isn't a problem at all? It is the same procedure I used in the lab setup... the only difference is that the production database is much bigger in size. Any thoughts?? -With kind regards, Peter. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin