[pgpool-general: 5189] Re: Architecture Questions

[Muhammad Usama]

On Wed, Dec 21, 2016 at 12:09 AM, David Sisk -X (dsisk - TEKSYSTEMS INC at
Cisco) <dsisk at cisco.com> wrote:

> I believe this is unquestionably a valid concern, but I believe there is a
> way to configure around it (those who know watchdog better will provide
> details, I’m sure). However, there’s still the problem that, having only
> one primary, if the corp link is down, half of the app can’t see across
> regions to a primary database…so you have a 50% or so outage instead of a
> full outage.
>

The watchdog in Pgpool-II 3.5 and onward ensures the presence of a quorum
for selecting the Master Pgpool-II node, And if the Pgpool-II watchdog
cluster has an odd number of nodes then it is very unlikely that Watchdog
will go in the split-brain.
But the other part of the problem is a little hard to work around in this
situation. I.e  in case of the network partitioning (when the link between
East and West is not working) how to handle the failover in the region
which does not have the Primary PostgreSQL server.

Best regards!
Muhammad Usama


>
> A
>
gain, I’d take a close look at Postgres-BDR…this is exactly the types of
> scenarios that it’s designed to handle.
>
>
>
> Best of luck!
>
>
>
> [image: banner2]
>
>
>
> *David Sisk*
>
> Engineer - Software
>
> dsisk at cisco.com
>
> Tel:
>
> *Cisco Systems, Inc.*
>
> 7025-6 Kit Creek Road PO Box 14987
> RESEARCH TRIANGLE PARK
> 27709-4987
> United States
> cisco.com
>
>
>
> [image: http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think
> before you print.
>
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
>
> Please click here
> <http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for
> Company Registration Information.
>
>
>
> *From:* pgpool-general-bounces at pgpool.net [mailto:pgpool-general-
> bounces at pgpool.net] *On Behalf Of *Yates, James C. -ND
> *Sent:* Tuesday, December 20, 2016 12:25 PM
> *To:* Muhammad Usama <m.usama at gmail.com>
> *Cc:* Muhammad Usama <muhammad.usama at enterprisedb.com>;
> pgpool-general at pgpool.net
> *Subject:* [pgpool-general: 5186] Re: Architecture Questions
>
>
>
> What I’m concerned about is the corporate network link between the AWS
> regions going down and PgPool doing a failover.  Then I could have the East
> and West region both think they have a master and doing updates/inserts on
> each.  Then when the link comes back up, my databases are out of sync and I
> could lose data.
>
>
>
> On Dec 20, 2016, at 6:27 AM, Muhammad Usama <m.usama at gmail.com> wrote:
>
>
>
> Hi
>
>
>
> Can you please explain a little more about your concerns of the
> split-brain situation you want to avoid?
>
>
>
> As far as I understand from the architecture diagram the proposed
> deployment consists of four PostgreSQL servers (Two in each AWS
> availability zone) and the Pgpool-II servers in front of each PostgreSQL.
> And the Application servers can connect to any of the four available
> Pgpool-II, So this seems like an active-active Pgpool-II configuration.
> Which means you would not be using the floating-IP (delegate IP) with the
> Pgpool-II.
>
>
>
> So if this is correct and you are not planing to use the floating IP and
> master-standby configuration of Pgpool-II, What worries you about the
> split-brain?
>
>
>
> Thanks
>
> Best regards
>
> Muhammad Usama
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20161222/cc0864e2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 121724 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20161222/cc0864e2/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 1469 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20161222/cc0864e2/attachment-0003.png>