Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Discussion: picking the writable host based on `read_only` value, failover scenario #789
I'd like to open a discussion about the heuristic by which
As I understand, right now
In a master failover scenario we would either manage to set
However there's one scenario that will not play nice with the above: network partitioning. Suppose the master gets network partitioned from the world. To the world, it seems dead. We promote a new master and set
Is this scenario considered by ProxySQL?
A failover mechanism such as
Worth noting that the "dead" master can come back to life even as promotion takes place, or even before: just as decision to promote a new server takes place.
In ProxySQL there is no concept of what is a write and what is read: you need to define that in
A bit over a year ago, I wrote how it is possible to perform a very quick switchover in less than one second .
At Percona Live Amsterdam Europe 2015 I described this failover mechanism in which a manager (like Orchestrator) would notify all the proxies that a failover is happening, and also when the failover completed.
Following this valid concern, it was suggested to use Consul, and I still believe it is the best way to propagate the information:
Some other mechanism can be introduced to improve fencing, any sort of STOMITH to stop the old master. In EC2 this is relatively easy: you the AWS API to stop the instance.
Note that with all I wrote so far, proxysql does not check
From where it comes the
Orchestrator notifying ProxySQL or ProxySQL automatically detecting the status of the backends: both solutions have pros and cons.