Official Mafiree Blogs

Keeping you informed about Databases

Access Control & Account Management In MySQL 8
By Sukan   |   June 08, 2023   |   Posted in : MySQL
Discover how MySQL 8 enhances security through features like password expiry, password validation, account lock/unlock, privilege management, and dual passwords. Safeguard your valuable data and streamline access control in your MySQL environment.

Significance of using Invisible Primary key (GIPK) with MySQL 8.0
By Sukan   |   February 21, 2023   |   Posted in : MySQL
How Generated Invisible Primary Keys (GIPK) Can Boost Your Database Efficiency

Achieving High Availability Using Log Shipping
By Sujith   |   February 21, 2018   |   Posted in : SQL Server
Here we will get the detailed explanation of how we can achieve HA using Log Shipping.

SQL Server On Linux
By Sujith   |   March 30, 2019   |   Posted in : SQL Server
SQL Server 2017 brings the best features of the Microsoft relational database engine to the enterprise Linux ecosystem, including SQL Server Agent, Azure Active Directory (Azure AD) authentication, best-in-class high availability/ disaster recovery, and unparalleled data security.

Types of SQL Server Replication
By Sujith   |   February 19, 2018   |   Posted in : SQL Server
Understanding on the types of replication in SQL Server and the type apt for your traffic pattern.

 Home  /  MySQL  
High Availability for MySQL using Orchestrator and ProxySQL
By Sukan   |   August 02, 2019   |   Posted in : MySQL

        In a typical production environment, setting up high availability is one of the most crucial tasks. Having said that most of the setups do not have a HA solution. This is because a traditional MySQL setup doesn’t have an inbuilt failover solution. Luckily we have few options to go for HA.
 

HA based on synchronous replication

    Cluster based solution would always provide HA. MySQL Cluster, Galera Cluster, InnoDB Cluster compromises of 2 or more servers (nodes) which can act as a HA. There are setups where implementing cluster would bring a lot of issues like deadlocks, increased transaction time as data volume goes up. These setup would have higher transactions flowing between the nodes which would cause a negative performance impact . 
 

HA based on asynchronous replication

    For a traditional MySQL setups one can use a replication manager / load balancer with failover support and achieve high availability. MHA, orchestrator are some of the replication managers. Orchestrator has lot of support and advanced features comparted to MHA.

In this blog, let us see how we have achieved HA using Orchestrator and ProxySQL

Background of the setup

  • 3 MySQL servers, 1 master and 2 replicas

  • 3 servers running with Orchestrator/raft  and ProxySQL
     

How orchestrator works?

Orchestrator has three different phases namely, 

  • Discovery

  • Refactoring

  • Recovery

Discovery phase of orchestrator detects the topology and understands the configuration of backend servers. It reads the replication status, configuration and understands the topology.

 

 

Refactoring phase will take care of replication rules, it will understand the binary log ordinates, GTID position and it initiates a recovery process.

Recovery phase of orchestrator will pick the ideal candidate as a master and will apply the promotion rules such as disabling read_only mode and repointing the available replica’s beneath the newly promoted master server.  


 


 

Broadcasting the topology changes

    Orchestrator can successfully detect the master failure and promoted a new master. Now application has to identify the changes and send the traffic to the current master. We have few options to notify the application about the changes.

  1. By using VIP we can detach the machine from the old master and attach to the new master.
  2. By using a Load balancer like ProxySQL.

Problem with VIP’s are bound to be plenty, we are not covering about this in the blog. So we have chosen another approach to use the Load balancer to broadcast the changes.

Orchestrator have lot of hooks which can help the DBA’s to execute sequentials commands whenever there are topology changes. Most importantly couple of hooks we can play with is to broadcast the changes.
 

Prefailover  - This hook will be initiated before the failover which will put the current master server to OFFLINE_SOFT thus avoid sending the new connection.

UPDATE MYSQL_SERVERS SET STATUS=’OFFLINE_SOFT’ WHERE IP=$ORC_FAILED_HOST

Postfailover  - This hook will be initiated after the failover which would remove the current master from the ProxySQL config and insert the new master as a writer group

DELETE FROM MYSQL_SERVERS WHERE HOSTNAME=$ORC_FAILED_HOST

INSERT INTO MYSQL_SERVERS(HOSTGROUP_ID,HOSTNAME,PORT,STATUS) VALUES (10, "'"$ORC_FAILED_HOST"'", '$ORC_SUCCESSOR_PORT', "ONLINE");
 

Note : ORC_SUCCESSOR_PORT and ORC_FAILED_HOST are variables exported by orchestrator.

We had simulated the test by running sysbench and forcefully killed the master node. As expected orchestrator detects the topology change and it updates the load balancer about the new master. 

With our configured hooks, all these topology changes are  updated by ProxySQL and application continues to connect the database without any issues.

sysbench 1.0.17 (using system LuaJIT 2.0.4)

 

Running the test with following options:

Number of threads: 1

Report intermediate results every 1 second(s)

Initializing random number generator from current time

 

Initializing worker threads...

 

Threads started!

 

[ 1s ] thds: 1 tps: 97.76 qps: 1974.19 (r/w/o: 1382.63/395.04/196.52) lat (ms,95%): 12.98 err/s: 0.00 reconn/s: 0.00
[ 2s ] thds: 1 tps: 107.06 qps: 2137.26 (r/w/o: 1498.89/424.25/214.13) lat (ms,95%): 10.27 err/s: 0.00 reconn/s: 0.00
[ 3s ] thds: 1 tps: 104.00 qps: 2079.04 (r/w/o: 1455.03/416.01/208.00) lat (ms,95%): 10.46 err/s: 0.00 reconn/s: 0.00
[ 4s ] thds: 1 tps: 103.00 qps: 2060.00 (r/w/o: 1442.00/412.00/206.00) lat (ms,95%): 10.65 err/s: 0.00 reconn/s: 0.00
[ 5s ] thds: 1 tps: 105.00 qps: 2101.06 (r/w/o: 1471.04/420.01/210.01) lat (ms,95%): 10.46 err/s: 0.00 reconn/s: 0.00
[ 6s ] thds: 1 tps: 51.00 qps: 1007.04 (r/w/o: 701.03/204.01/102.00) lat (ms,95%): 12.30 err/s: 0.00 reconn/s: 1.00

[ 7s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00
[ 8s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00
[ 9s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00
[ 10s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00
[ 11s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00
[ 12s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00
[ 13s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00

[ 14s ] thds: 1 tps: 49.04 qps: 984.72 (r/w/o: 689.50/196.14/99.07) lat (ms,95%): 21.50 err/s: 0.00 reconn/s: 0.00
[ 15s ] thds: 1 tps: 103.00 qps: 2058.00 (r/w/o: 1440.00/412.00/206.00) lat (ms,95%): 11.45 err/s: 0.00 reconn/s: 0.00
[ 16s ] thds: 1 tps: 99.00 qps: 1997.00 (r/w/o: 1399.00/400.00/198.00) lat (ms,95%): 11.45 err/s: 0.00 reconn/s: 0.00


All this failover happened within 8 seconds which sounds very impressive. If you are looking for a HA solution without going for synchronous replication or Aws RDS then Orchestrator with ProxySQL is a great choice.
 



0 Comments


Leave a Comment

Name *

Email *

Comment *



Search All Blogs



Need Support?


Solutions      Services      Resources      About Mafiree

More than 3000 servers monitored

Certified database Administrators

24X7X365 Support

Happy Clients


ENQUIRE NOW
For Sales Related Queries, Please Call Our Sales Experts at

 +91-80-41155993


Meet Mafiree on social networks!

     

PCI Certificate

Copyright © 2019 - All Rights Reserved - Mafiree