From: | Oleksii Kliukin <alexk(at)hintbits(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | BDR: cascading setup |
Date: | 2016-01-11 10:55:44 |
Message-ID: | 147EB703-5E82-476F-9920-E8163506EE47@hintbits.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
We are evaluating BDR for a multi-master cross-datacenter replication, with 2 masters actually communicating across datacenter, supplemented by a local in-datacenter replicas to provide HA.
Basically, something like
M <——> M
| |
S S
I could run all nodes as multi-masters, but I don’t want many-to-many cross-datacenter communications, primary because of the latency issues, and also to avoid locking too many nodes on DDL changes.
As far as I see, I cannot make a promoted physical replica a member of the multi-master group without re-joining the group after promotion (which leads to re-transfering the whole database over the network from the surviving master), see https://github.com/2ndQuadrant/bdr/issues/98, so running multi-master with physical datacenter-local replicas is tough, but is there a better alternative at the moment, i.e:
- BDR multi-master being part of more than one replication group (I could create one group for cross-DS multi-masters, and another for DS-local communications)?
- BDR multi-master being also master with several UDR replicas attached (so that DS-local nodes will be running as UDR replicas of a master, that at the same time communicates via BDR to another master in another DS), and allowing the UDR replica to join the BDR group if the master dies.
Kind regards,
--
Oleksii
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-01-11 11:14:10 | Re: Request - repeat value of \pset title during \watch interations |
Previous Message | Karsten Hilbert | 2016-01-11 10:20:17 | Re: Japanese, was: Re: Code of Conduct: Is it time? |