MySQL InnoDB Cluster is an Oracle High Availability solution that can be easily installed over MySQL to provide high availability with multi-master capabilities and automatic failover. In the previous post we presented the first component of InnoDB Cluster, group replication. Now we will go through the second component, MySQL Router. We will address MySQL Shell in a final installment of this three-part series. By then, you should have a good overview of the features offered by MySQL InnoDB Cluster.
This component is responsible for distributing the traffic between members of the cluster. It is a proxy-like solution to hide cluster topology from applications, so applications don’t need to know which member of a cluster is the primary node and which are secondaries.
The tool is capable of performing read/write splitting by exposing different interfaces. A common setup is to have one read-write interface and one read-only interface. This is default behavior that also exposes 2 similar interfaces to use x-protocol (i.e. used for CRUD operations and async calls).
The read and write split is done using a concept of roles: Primary for writes and Secondary for read-only. This is analogous to how members of cluster are named. Additionally, each interface is exposed via a TCP port so applications only need to know the IP:port combination used for writes and the one used for reads. Then, MySQL Router will take care of connections to cluster members depending on the type of traffic to server.
MySQL Router is a very simple tool, maybe too simple as it is a layer four load balance and lacks some of the advanced features that some of it’s competitors have (e.g.. ProxySQL).
Here is a short list of the most important features of MySQL Router:
An important thing to mention is the routing_strategy algorithms that are available, as they are assigned by default depending on the routing mode:
Additional routing_strategy algorithms :
For performance purposes it’s recommended to setup MySQL Router in the same place as the application, considering an instance per application server.
Here you can see a sample configuration file auto-generated by --bootstrap functionality:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
$ cat /etc/mysqlrouter/mysqlrouter.conf # File automatically generated during MySQL Router bootstrap [DEFAULT] name=system user=mysqlrouter keyring_path=/var/lib/mysqlrouter/keyring master_key_path=/etc/mysqlrouter/mysqlrouter.key connect_timeout=30 read_timeout=30 [logger] level = INFO [metadata_cache:percona] router_id=4 bootstrap_server_addresses=mysql://192.168.70.4:3306,mysql://192.168.70.3:3306,mysql://192.168.70.2:3306 user=mysql_router4_56igr8pxhz0m metadata_cluster=percona ttl=5 [routing:percona_default_rw] bind_address=0.0.0.0 bind_port=6446 destinations=metadata-cache://percona/default?role=PRIMARY routing_strategy=round-robin protocol=classic [routing:percona_default_ro] bind_address=0.0.0.0 bind_port=6447 destinations=metadata-cache://percona/default?role=SECONDARY routing_strategy=round-robin protocol=classic [routing:percona_default_x_rw] bind_address=0.0.0.0 bind_port=64460 destinations=metadata-cache://percona/default?role=PRIMARY routing_strategy=round-robin protocol=x [routing:percona_default_x_ro] bind_address=0.0.0.0 bind_port=64470 destinations=metadata-cache://percona/default?role=SECONDARY routing_strategy=round-robin protocol=x |
We are almost done now, only one post left. The final post is about our third component MySQL Shell, so please keep reading.
Percona is synonymous with optimized MySQL performance. Watch our webinar on MySQL scaling and high availability for insight on how to make your database run faster and how to make it more optimized than before. Percona CEO Peter Zaitsev hosts the webinar.
Percona XtraDB Cluster (PXC) is a high availability MySQL clustering solution. It is open source and has multi-master capabilities. Percona has integrated PXC with ProxySQL to further meet your high availability and clustering needs. Watch our webinar to learn more and click here to learn how to perform schema upgrades using PXC.
Resources
RELATED POSTS
Hi Francisco,
thank you for your interest in MySQL InnoDB Cluster, however, I would like to comment on 2 points:
X Protocol is not for JSON, you can perform JSON operations also in SQL in the standard protocol. X Protocol is used for CRUD operations and for example asynchronous call.
The second point it related to the router, when the primary comes back it doesn’t go back at the end of the list as it may become the next PRIMARY and therefore used again. So when PRIMARY is used, the router send the traffic to the Primary-Master of the Group and only the Group decide which one it is.
Lefred,
Thanks for your comments, I’ve updated the post to reflect them.
If we have 10 app servers, will router on only 1 app server will be used ? Or all 10 routers on all app servers be used?
Krish, it mostly depends on the app configuration, basically each router will expose it’s one read/write interfaces but all of them will point to the same cluster so you will need to configure each app server to connect to local router so you’ll end up using the 10 instances.
Here you have a graphic with typical deployment https://dev.mysql.com/doc/mysql-router/8.0/en/mysql-router-general-using-deploying.html