Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WzVJt-0005pZ-Hh for pgsql-admin@arkaria.postgresql.org; Tue, 24 Jun 2014 18:19:49 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WzVJs-0004Xs-U5 for pgsql-admin@arkaria.postgresql.org; Tue, 24 Jun 2014 18:19:48 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1WzVJq-0004XV-CX for pgsql-admin@postgresql.org; Tue, 24 Jun 2014 18:19:46 +0000 Received: from mail-yk0-x22c.google.com ([2607:f8b0:4002:c07::22c]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1WzVJm-0008Qa-U4 for pgsql-admin@postgresql.org; Tue, 24 Jun 2014 18:19:44 +0000 Received: by mail-yk0-f172.google.com with SMTP id 142so418335ykq.17 for ; Tue, 24 Jun 2014 11:19:41 -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:references :in-reply-to:content-type:content-transfer-encoding; bh=a3vsSLBCsBTHAtwBRIPjHUmLI2oYfvRdlOWVS0H7J+4=; b=xddyD0MfyxeQ8KFovp2En+17AX/4Kn3KDtVL6mahJxCzDywUPBxi0hxnJne4lDarOq 8zaUoN33WGiCp+vHtgj16GIX5f8vWVDAcEUVQRSOZASPsP9/9Nzl4sT9/Di7A2GbAMnu Sv+qnSWYuqAgE+WiV1qHQDyByBYQDTdjONKKHcQ0qpmOD4gBIwPq2Mmg4EMdT+N6uf6c LWlFAWNbdMvqE6/LJovNeaLTZbN4AkithGXRnek8a+pLA02uXlXa8vRWU+l4kRtYBmyC fMVyzdZYFhD5duPvAYtKRWb7tb1w0rya3c4/ZMb7ZlzeYhs7YntIsSu7OXWzHEI92DEu wrBA== X-Received: by 10.236.4.34 with SMTP id 22mr3676035yhi.41.1403633981610; Tue, 24 Jun 2014 11:19:41 -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 d58sm1394800yhf.2.2014.06.24.11.19.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Jun 2014 11:19:41 -0700 (PDT) Message-ID: <53A9C139.2040704@gmail.com> Date: Tue, 24 Jun 2014 14:19:37 -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: Fwd: Re: Wal archive way behind in streaming replication References: <53A9B567.5070301@gmail.com> In-Reply-To: <53A9B567.5070301@gmail.com> X-Forwarded-Message-Id: <53A9B567.5070301@gmail.com> 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 Ok, I did the copy from pg_xlog directory into the restore.conf specifieddirectory. The standby servers seem fine with that, however, just copying does not inform the primary that the copy has happened. The archive_status directory under pg_xlog on the primary still thinks the last WAL sent was *B7 and yet it's now writing *C9. When I did the copy it was only up to *C7 and nothing else has shown in the standby's directory. Now, the *.done files in archive_status are just zero length, but I'm a bit hesitant to just do a touch for the ones I manually copied as I don't know if this is from an in-memory queue or if it Postgresql reads the contents of this regularly in order to decide what to copy. Is that safe to do? On 6/24/2014 9:56 AM, Andrew Krause wrote: > You can copy all of the WAL logs from your gap to the standby. If you place them in the correct location (directory designated for restore) theinstance will automatically apply them all. > > > Andrew Krause > > > > On Jun 23, 2014, at 9:24 AM, John Scalia wrote: > >> 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 primaryand 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 areonly up to *10. Now, like I said prior, with there being 10 minutes (600seconds) 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 > -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin