Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YR0yJ-0002L5-E5 for pgsql-admin@arkaria.postgresql.org; Thu, 26 Feb 2015 16:07:31 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YR0yH-0003Bx-OC for pgsql-admin@arkaria.postgresql.org; Thu, 26 Feb 2015 16:07: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 1YR0xt-0002aa-Sw for pgsql-admin@postgresql.org; Thu, 26 Feb 2015 16:07:05 +0000 Received: from mail-yh0-x22c.google.com ([2607:f8b0:4002:c01::22c]) by magus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YR0xm-0005mu-Gq for pgsql-admin@postgresql.org; Thu, 26 Feb 2015 16:07:01 +0000 Received: by yhai57 with SMTP id i57so4958975yha.1 for ; Thu, 26 Feb 2015 08:06:56 -0800 (PST) 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=NeWkBMYif+hB97WFeNyyVl81Kg0OzYj8DJyroSZODRs=; b=V+y6C/oZ63MzpETld6dEZ1kUon3rK6wrUVanjZcqlrklWvVADB8hE7Gfn3bmW54B+u VNJWjsn3cMmTV5NISGnMN2OMYslhjMqSAQG8XskqjZSDwBC9TY9Tj8XY0u9jBeVAHvYR HwtbN/m8NZfL+vhtoMANDomo1bKuAbEoV0mKXmJGmk8pShspLzM4EdKS5feuDlJo+ElL 87hP26DTsJccnggUhmbRhaMFT/JZM0vIQM5bHqfCd52CVvoUAo+yCy0ajlumirUGbTDQ 77sb9kbtYkMNQET0GcVaSRsatu0hu8yiCFqpxJBTwdRXWYMfLlIidzbp+XQKDVV7000B izXg== X-Received: by 10.170.84.134 with SMTP id b128mr8495315yka.82.1424966816538; Thu, 26 Feb 2015 08:06:56 -0800 (PST) Received: from [192.168.254.3] (h77.89.102.166.static.ip.windstream.net. [166.102.89.77]) by mx.google.com with ESMTPSA id f68sm835515yhc.54.2015.02.26.08.06.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Feb 2015 08:06:55 -0800 (PST) Message-ID: <54EF449A.9030407@gmail.com> Date: Thu, 26 Feb 2015 11:06:50 -0500 From: John Scalia User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "David F. Skoll" , pgsql-admin@postgresql.org Subject: Re: Weird spikes in delay for async streaming replication on 9.1 References: <20150214110050.2f032f05@ollie.roaringpenguin.com> <20150226094428.34531376@hydrogen.roaringpenguin.com> <54EF3E6F.60403@gmail.com> <20150226104433.1b0df1db@hydrogen.roaringpenguin.com> <54EF411B.80202@gmail.com> <20150226110007.09bb1551@hydrogen.roaringpenguin.com> In-Reply-To: <20150226110007.09bb1551@hydrogen.roaringpenguin.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.7 (--) 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 On 2/26/2015 11:00 AM, David F. Skoll wrote: > On Thu, 26 Feb 2015 10:51:55 -0500 > John Scalia wrote: > >> OK, if it's asynchronous, is your script checking that primary isn't >> holding up closing out and transmitting the latest WAL segment during >> these times? > No. The checking script is dead simple. It's a perl script that does > more-or-less the equivalent of this. $master_dbi is a DBI handle > pointing to the master database server and $standby_dbi is one pointing > to the standby. Pseudocode is shown below (the real code actually measures > the duration in much finer increments than 1s, but you get the idea...) > > my $time = time(); > > # There's one row in the table with key column 'Timestamp' > $master_dbi->do("UPDATE table SET value = ? WHERE key = 'Timestamp'", undef, $time); > > my $start = time(); > while(..) { > $row = $standby_dbi->fetchrow_arrayref("SELECT * FROM table WHERE key = 'Timestamp'"); > # Check that we got back the same $time we put in and if so, > # break out of the while loop; otherwise pause for a bit. > } > # See how long that took > my $duration = time() - $start; > >> And if the Standby really needs to be up to date, why >> not try synchronous replication? > It doesn't need to be totally up-to-date. It can lag by up to 30s without > impacting our application. And we don't use synchronous replication because > then a network problem would stall all the write transactions on the primary > and that would be fatal. Possibly, but that's why WE use a pair of standby servers, not a single one, so that all transactions get committed in a timely manner. The odds of both standbys failing at the same time are really small. Maybe your script should check which is latest WAL segment on each system first? That might show that you have a timedelay with getting the info to the standby. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin