Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Xoa9l-0000yH-J1 for pgsql-admin@arkaria.postgresql.org; Wed, 12 Nov 2014 15:48:29 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Xoa9l-0002Mc-0Z for pgsql-admin@arkaria.postgresql.org; Wed, 12 Nov 2014 15:48: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 1Xoa9j-0002KY-KI for pgsql-admin@postgresql.org; Wed, 12 Nov 2014 15:48:27 +0000 Received: from mail-yk0-x235.google.com ([2607:f8b0:4002:c07::235]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Xoa9f-0002Jm-4u for pgsql-admin@postgresql.org; Wed, 12 Nov 2014 15:48:25 +0000 Received: by mail-yk0-f181.google.com with SMTP id 142so1139038ykq.12 for ; Wed, 12 Nov 2014 07:48:21 -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 :content-type:content-transfer-encoding; bh=4JpNPrMqdrLkemjPOEBl6II37Lh9K9WYf9rscsuFZT4=; b=zodD10+ljJd9Cro0m4ZyskCs5S/6hnXR7LTm8K0YLcBLn2vuSlcsi5IigWNaUs+UuO HguooRQmdZ/kSdts4qfSZrON08GSvzf3pcVA9qZG2g5x5oKI578ZUNiiEqXb2+8jILE8 jzGtxoSqvwWwST4mQWNCyLOG/oY+57Syu4RUtE5zSfjaE7M8/qMVKEoyPKE9d+hDeqQf dXjDCcgPR28RSU3MFpKBLWKf5j+4cYLE9PRQtpilD3VddZl/sV5bUWBVSLMeFSJNrz7k 7Te054EVD62fpvC63Pqri39tzvGJllJZDJV9xsL0IiaMtxPx3A2DYltN4TVnVYOXs3e2 8o1g== X-Received: by 10.170.52.6 with SMTP id 6mr2357644yku.127.1415807300880; Wed, 12 Nov 2014 07:48:20 -0800 (PST) Received: from [192.168.254.6] (h77.89.102.166.static.ip.windstream.net. [166.102.89.77]) by mx.google.com with ESMTPSA id e35sm7486587yhq.45.2014.11.12.07.48.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Nov 2014 07:48:20 -0800 (PST) Message-ID: <54638146.3030307@gmail.com> Date: Wed, 12 Nov 2014 10:48:22 -0500 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: Performance degradation after loss of one standby Content-Type: text/plain; charset=ISO-8859-1; 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 Hi all, Our staging area has 3 PostgreSQL servers running streaming replication with WAL archiving in a primary with 2 standbys arrangement. All of these are running on VMs with CentOS 6.5. Things were running fine until this morning when our QA folks ran a code update, and during the update, one of the standby servers died (I don't know why yet). The other 2 systems were fine so the primary could continue to stream to the remaining standby. but now some of the code is intermittently failing due to timeouts. Yes, I've asked the developer to modify his code to allow some additional time for completion. I've asked QA if they know whether a replication connection from the dead standby was active when it died, but they haven't answered me yet. I also reminded them that had this been a single standby, the system would now be completely unresponsive and not just slow. But my question really is, why is the performance degraded in this event? Seems to me that it should be behaving as a primary with one standby and running normally. Ideas? -- Jay -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin