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

Re: Help with Scaled Cartridges Racing (mariadb galera)



Thanks for the sum up, makes a lot of sense now. I'm leaning towards that method as the cluster would require atleast 3 gears.

On Wed, Feb 26, 2014 at 7:40 AM, Ben Parees <bparees redhat com> wrote:
Seems like Clayton's suggestion is the right way to go.  Assuming you know the initial number of gears (3 in your case), you can wait until you have publications from 3 unique gears, then sort them by id and elect a master by lowest id.  You'll then want to publish that master so additional gears (scale out) know the master.

If you don't know the initial number of gears, things certainly get trickier.  I'm not sure if openshift exposes any information to the cartridge itself, about how many gears exist for that cartridge.


Ben Parees | OpenShift

----- Original Message -----
> From: "Andrew Lau" <andrew andrewklau com>
> To: "John Hawley" <jhawley redhat com>
> Cc: dev lists openshift redhat com
> Sent: Tuesday, February 25, 2014 3:07:30 PM
> Subject: Re: Help with Scaled Cartridges Racing (mariadb galera)
>
> On Wed, Feb 26, 2014 at 5:29 AM, John Hawley < jhawley redhat com > wrote:
>
>
>
> 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.
>
>
> Thanks for the words of warning :)
>
> I've been using MariaDB Galera clusters for quite some time and haven't run
> into any issues, as of yet. *knock on wood*
> If you think the out of sync masters will be a common issue, we can look into
> some sort of logic to force sync the SST procedure every so often (possibly
> with cron?)
>
>
> > *- 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.
>
> I was originally following your master-slave style cartridge, and that's what
> gave me some of the initial inspiration. However, I wasn't a fan of having
> to use two cartridges and the manual intervention required to get it going.
> I want this cartridge to be as simple as deploying any other official
> openshift cartridge.
>
>
>
>
> - 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]