[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Help with Scaled Cartridges Racing (mariadb galera)




----- Original Message -----
> On 02/25/2014 01:47 AM, Andrew Lau wrote:
> > Hi guys,
> > 
> > I've been working on bringing MariaDB Galera [1] to OpenShift and so far
> > I've quite successful with the help from many different people. I'm
> > stuck on a few things though which I'm hoping someone could help me with.
> 
> Just a general word of warning, I found Galera clustering to have some
> rather nasty rough edges, particularly with the possibility of some
> transactions never actually making it out to the other nodes.  I
> confirmed that pathology with Monty, and I don't know if there's been a
> resolution to it yet.  I'm not trying to deter, just trying to make it
> known that Galera is not a solve-all solution.
> 
> > *- Determining a master gear for the database initialization*
> > With the galera cluster, we need to have one gear create the database,
> > drop test user. etc. all the normal stuff, however only one needs to do
> > this. The problem is, starting the cartridge with min 3 gears, they will
> > all race to start, this makes using a hook method not possible because
> > there'll be too many inconsistencies. I'd ideally not want to be
> > creating two separate cartridges just for this.
> 
> You are probably going to have to solve this similarly to the way I
> solved it with the original master/slave stuff and have an explicit
> "init" cartridge that has that logic in it, and then instantiate a your
> "slaves".  The init node obviously shouldn't be scalable, but you can
> make the "slaves" scale at will at that point.  If you make a dependency
> for the slaves to require the init that should prevent anything too
> weird, and prevent a race for the "slaves" to come up before the init
> has completed and settled.
> 
> Not ideal, obviously, but I don't know of anyway to prevent that race
> condition you are describing, and it's not a dissimilar one to what I
> was seeing with the master/slave stuff.

The Redis/select master approach is better when all of your participants are equivalent.  The master/slave maps better to real master-slave relationships.

> 
> - John 'Warthog9' Hawley
> 
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]