Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wz5Ac-00016W-57 for pgsql-admin@arkaria.postgresql.org; Mon, 23 Jun 2014 14:24:30 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Wz5Ab-0007NZ-KC for pgsql-admin@arkaria.postgresql.org; Mon, 23 Jun 2014 14:24:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Wz5Aa-0007NR-Ho for pgsql-admin@postgresql.org; Mon, 23 Jun 2014 14:24:28 +0000 Received: from mail-yh0-x22e.google.com ([2607:f8b0:4002:c01::22e]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Wz5AT-0004ol-Ca for pgsql-admin@postgresql.org; Mon, 23 Jun 2014 14:24:27 +0000 Received: by mail-yh0-f46.google.com with SMTP id c41so5069613yho.19 for ; Mon, 23 Jun 2014 07:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=TX8QXRLUJ18QyI8SzPEO4hzBbQ8WEbFRyvKM4GjLMm0=; b=yk2oDX1FYiyQhIC6iLTy81yZflfhuU27A17rfMN0kqVn3DaK02EFb2nYJffYBBuGlP BRWRSr9hJMOYcVaG6rLdseUxsqL2Zk6Jjl+n/BvqNItSI8syo1n8KbaL6x3L4Q7/+qkg 9DEqQ4M6jAMe8cvkR0gBZLelf8Scm4HNlb65JYw5ufvgTpa8oSzAJJyPzkujZfXS293R rWjxCiGDJOprMARCo9952xLo3R00zZXaglqTNlRFbj6H7lmSdmJULJSRvclSsxMXuqGT BPzmgnRE7o0sMWWwbOMLyxIX5+fudqyQ5DTfDJer3t37zoIbc+GQRZJ7W7WZYnjph76y jmdg== X-Received: by 10.236.62.130 with SMTP id y2mr3107031yhc.158.1403533459092; Mon, 23 Jun 2014 07:24:19 -0700 (PDT) Received: from [192.168.254.2] (h77.89.102.166.static.ip.windstream.net. [166.102.89.77]) by mx.google.com with ESMTPSA id j21sm30093619yhj.29.2014.06.23.07.24.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Jun 2014 07:24:18 -0700 (PDT) Message-ID: <53A8388E.5000705@gmail.com> Date: Mon, 23 Jun 2014 10:24:14 -0400 From: John Scalia User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "pgsql-admin@postgresql.org" Subject: Wal archive way behind in streaming replication Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.0 (--) 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 Came in this morning to numerous complaints from pgpool about the standby servers being behind from the primary. Looking into it, no WAL files had been transferred since late Friday. All I did was restart the primary and the WAL archving resumed, however, looking at the WAL files on the standby servers, this is never going to catch up. Now, I've got the archive_timeout on the primary = 600 or 10 minutes and I see WAL files in pg_xlog every 10 minutes. As they show up on the standby servers, they're also 10 minutes apart, but the primary is writing *21 and the standby's are only up to *10. Now, like I said prior, with there being 10 minutes (600 seconds) between transfers (the same pace as the WALs are generated) it will never catch up. Is this really the intended behavior? How would I get the additional WAL files over to the standbys without waiting 10 minutes to copy them one at a time? -- Jay -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin