Single point of failuer

[James Wang]

Hi All,

Any update about MaxScale single point of failure please?

The question was asked in the MariaDB road show London in May and also in the MariaDB mailing list.

Thanks a lot in advance

[Martin Brampton]

Hi James

Sorry, I wasn't at the road show, so I don't know the exact question.

MaxScale can be run on multiple machines to avoid it being a single
point of failure. Does that answer your query?

Best regards, Martin

> --
> You received this message because you are subscribed to the Google
> Groups "MaxScale" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to maxscale+u...@googlegroups.com
> <mailto:maxscale+u...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

--
Martin Brampton, Principal Software Engineer
MariaDB Corporation | t: +44 1751-432935 | Skype: blacksheepresearch

[Mudd, Simon]

Hi James,

> On 9 Sep 2015, at 10:26, James Wang <jwang...@gmail.com> wrote:
>
> Any update about MaxScale single point of failure please?

It may not quite answer your question, but I’ve setup MaxScale in a redundant manner for binlog server usage and it seems to work quite well.
It is _very_ simple. I configure the clients to talk to a "virtual host" in DNS which has 2 ip addresses. e.g.

maxscale-virtual IN A 192.168.1.88 # ip of maxscale1
maxscale-virtual IN A 192.168.1.99 # ip of maxscale2

Clients connect to maxscale-virtual which obviously connects to one of the 2 servers. Observation shows
that if the one of the maxscale servers goes down a reconnection happens almost immediately (this is the slave’s I/O thread
reconnecting to a “master” in my case) to the other server and the downtime is measured in milliseconds.

This obviously assumes that the configuration for the 2 maxscale servers is “identical” and given
the usage I mention this simple setup works remarkably well. I would expect that if the client connection
is configured to automatically reconnect then you should see the same behaviour. I haven’t checked if
this behaviour is due to the MySQL library or the tcp layer but the end result in my case is as described.

Hope this helps.

Simon

[James Wang]

Thanks a lot for your replies.

[Dipti Joshi]

James:

Look at this blog on how to setup multiple MaxScale along with corosync/pacemaker for HA: https://mariadb.com/blog/how-make-maxscale-high-available-corosyncpacemaker

Dipti

On Wed, Sep 9, 2015 at 7:23 AM, James Wang <jwang...@gmail.com> wrote:

Thanks a lot for your replies.

--

You received this message because you are subscribed to the Google Groups "MaxScale" group.

To unsubscribe from this group and stop receiving emails from it, send an email to maxscale+u...@googlegroups.com.

[Ivan Zoratti]

Hi James, 

This post may not fit with your specific needs, but it is another way to setup HA for MaxScale:

https://mariadb.com/blog/how-make-maxscale-high-available-corosyncpacemaker

When we designed MaxScale, we tried to make it hot swappable by handling information that could be safely managed by multiple MaxScale servers at the same time. This approach has been considered for all the plugins we had initially published. We also thought about a communication mechanism among a group of MaxScale servers, which has not been implemented yet. You should achieve HA for the current popular plugins following Simon’s advice or with the info in the post linked above.

Hope it helped, 

Regards, 

-ivan

On 9 Sep 2015, at 13:23, James Wang <jwang...@gmail.com> wrote:

Thanks a lot for your replies.