Re: PG Sharding
On Wed, Jan 31, 2018 at 7:48 PM, Steven Lembark wrote: > On Mon, 29 Jan 2018 15:34:18 +0100 > Matej wrote: > > > Hi Everyone. > > > > We are looking at a rather large fin-tech installation. But as > > scalability requirements are high we look at sharding of-course. > > > > I have looked at many sources for Postgresql sharding, but we are a > > little confused as to shared with schema or databases or both. > > Suggest looking at the Xreme Data product. It is a parallel, > shared-nothing implementation of PG that should solve your > needs rather nicely. > > You can see a description of their product at > https://xtremedata.com/ > > Happy scaling :-) > > Having been a production DBA for both the DBX (XtremeData) and the Greenplum MPP database platforms, IMO Greenplum is far superior to DBX. Issues with the GP master node being a single point of failure are solved by a secondary master node and automatic failover technology e.g. keepalived. But, it sounds like the OP is not really looking for the kind of scale that an MPP solution provides, but rather the kind of scale that is typically solved by a service-orchestration suite. I don't think that "a rather large fin-tech installation" with "high scalability requirements" is really enough detail to give a recommendation on orchestration software. -dan
Re: BDR, ERROR: previous init failed, manual cleanup is required
On Wed, Feb 7, 2018 at 9:14 AM, Zhu, Joshua wrote: > > > Here is a BDR problem we ran into recently: > > > > A BDR group with a pair of nodes, N1 and N2, group is created on N1, N2 > joins the group, so far so good > > N2 departs/rejoins the group a couple of times, then ran into an issue, > with the following symptom, after executing bdr.bdr_group_join() on N2 wrt > N1: > > > FWIW, I was never able to successfully join a node with bdr.bdr_group_join. I was only ever able to get it to work by using bdr_init_copy and letting it create the database on the target node for me. Run "SELECT bdr.bdr_node_join_wait_for_ready();" to make sure it bootstrapped properly. I can't access my bdr cluster right now, but off the top of my head: - check the bdr.bdr_connections table in addition to the nodes table. - make sure you run "select bdr.bdr_connections_changed();" after you manually delete from any of the bdr tables.
