Can find sponsor: Would anyone be interested in patching mha to be MariaDB gtid compatible?
Hello, Would anyone be interested in patching mha to be MariaDB gtid compatible? I think I would be able to find a sponsor to pay a bit for it. reference links) https://github.com/yoshinorim/mha4mysql-manager https://github.com/yoshinorim/mha4mysql-node https://github.com/charlesdirk/MariaDB-MHA -> could not get this to work: if anyone got it to work please let me know how to get it to work. Thank you. Have a nice day.
Hi, I looked a little and MHA is confirmed to be unmaintained by the author - https://github.com/shlomi-noach/awesome-mysql/pull/125#discussion_r162518920... . Alternatives include: * MaxScale; including the recent MaxScales GPL version probably supports the equivalent functionality * https://proxysql.com/documentation/proxysql-cluster/ * Corosync/Pacemaker - this would be the closest to your existing MHA functionality. As there was going to be an intensive test of any MHA developed, I think you'd be better served with one of the above alternatives with slightly longer learning and testing, but better long term stability for your system. I wish you the best in your migration. A post completion experience email would be much appreciated so we can guide the next migration or improve documentation would be appreciated. Daniel On Sat, 14 Dec 2024 at 07:18, highclass99 via developers < developers@lists.mariadb.org> wrote:
Hello,
Would anyone be interested in patching mha to be MariaDB gtid compatible? I think I would be able to find a sponsor to pay a bit for it.
reference links) https://github.com/yoshinorim/mha4mysql-manager https://github.com/yoshinorim/mha4mysql-node
https://github.com/charlesdirk/MariaDB-MHA -> could not get this to work: if anyone got it to work please let me know how to get it to work.
Thank you. Have a nice day. _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
Hello, Thank you for your reply. I do know that a large amount of MariaDB large users still use mha. When I asked DB consulting company this quarter, they said for MariaDB they have a split of 7:3 of users using Maxscale and mha. Of note, mha works fine with MariaDB as long as you patch the version checking, and are ok with it using binlog instead of gtid. My DB consulting company told me that they never seen it not work yet.
I looked a little and MHA is confirmed to be unmaintained by the author - https://github.com/shlomi-noach/awesome-mysql/pull/125#discussion_r162518920... . Hence, I was looking to sponsor MariaDB gtid patches for it.
MaxScale; including the recent MaxScales GPL version probably supports the equivalent functionality I did look into this, and MariaDB specialized DB consulting company that supports Maxscale(and sells it) did not recommend this to us unless we send all our traffic to MaxScale too, which we do not wish to do. They recommend MaxScale only when traffic is being sent to Maxscale as a proxy.
https://proxysql.com/documentation/proxysql-cluster/ Probably a better idea to use Maxscale if going down the proxy route.
Corosync/Pacemaker This is basically I think making mha all over manually, so too complex and not a good idea.
Thank you. Have a nice day. On Fri, Dec 20, 2024 at 8:05 AM Daniel Black <daniel@mariadb.org> wrote:
Hi,
I looked a little and MHA is confirmed to be unmaintained by the author - https://github.com/shlomi-noach/awesome-mysql/pull/125#discussion_r162518920... .
Alternatives include: * MaxScale; including the recent MaxScales GPL version probably supports the equivalent functionality
* https://proxysql.com/documentation/proxysql-cluster/
* Corosync/Pacemaker - this would be the closest to your existing MHA functionality.
As there was going to be an intensive test of any MHA developed, I think you'd be better served with one of the above alternatives with slightly longer learning and testing, but better long term stability for your system. I wish you the best in your migration. A post completion experience email would be much appreciated so we can guide the next migration or improve documentation would be appreciated.
Daniel
On Sat, 14 Dec 2024 at 07:18, highclass99 via developers < developers@lists.mariadb.org> wrote:
Hello,
Would anyone be interested in patching mha to be MariaDB gtid compatible? I think I would be able to find a sponsor to pay a bit for it.
reference links) https://github.com/yoshinorim/mha4mysql-manager https://github.com/yoshinorim/mha4mysql-node
https://github.com/charlesdirk/MariaDB-MHA -> could not get this to work: if anyone got it to work please let me know how to get it to work.
Thank you. Have a nice day. _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
Hi, On 12/22/24 10:54, highclass99 via developers wrote:
MaxScale; including the recent MaxScales GPL version probably supports the equivalent functionality I did look into this, and MariaDB specialized DB consulting company that supports Maxscale(and sells it) did not recommend this to us unless we send all our traffic to MaxScale too, which we do not wish to do. They recommend MaxScale only when traffic is being sent to Maxscale as a proxy.
This is true for MaxScale but it's also true for all other applications that manage replication automatically and that don't use a VIP. The VIP is there to control where writes are sent. Without it, the applications themselves must be able to determine where to connect to perform writes. In some deployments, VIPs are not an option or the complexity of setting them up is too great which is why the usual recommendation that is given is to use a "replication-aware" proxy like MaxScale: if the application that routes client traffic and manages replication is done in the same program, there's no possibility of a "split-brain" where the clients continue writing to the old primary while a switchover or a failover is in progress. This also eliminates the need for the application to be explicitly aware of the replication or what is a write and what isn't and all of this avoids a lot of complexity. You could use MaxScale without routing any client traffic through it and it should work just fine, you'd just have to manage the VIP through the scripting mechanism <https://mariadb.com/kb/en/mariadb-maxscale-2106-maxscale-2106-common-monitor-parameters/#script> in MaxScale. I haven't used MHA much and the last time I did was a long time ago but reading the wiki and some blog posts I believe that it also manages the VIP through scripts. Another benefit of MaxScale is that you don't need SSH access to the servers, everything is done over SQL connections and thus the setup is a lot simpler. Personally, I'd recommend just routing all the traffic through MaxScale as it greatly simplifies the deployment and with the cooperative monitoring <https://mariadb.com/kb/en/mariadb-maxscale-2106-maxscale-2106-mariadb-monitor/#cooperative-monitoring> mechanism, even MaxScale itself can be made highly available. Disclaimer: I work on MaxScale :) Markus -- Markus Mäkelä, Senior Software Engineer MariaDB Corporation
participants (3)
-
Daniel Black -
highclass99 -
Markus Mäkelä