With MariaDB MaxScale 2.2 (currently in beta) the monitor for MariaDB instances can detect a Binlog server setup and SQL statements can be properly routed among Master and Slave servers.
The “identity” of the binlog server layer from the slave server’s point of view is something that could be modified in order to provide all slaves such common parameters for all MariaDB MaxScale server they could replicate from.
Today, I’m excited to announce the general availability of MariaDB MaxScale 2.0, our next generation database proxy. This new version includes important new functionality that integrates data streaming with Kafka and other data sources, as well as significant development work for better security and high availability.
MariaDB MaxScale team has designed a modular solution to stream binlog events coming from the Master database to the data lake via messaging systems such as Kafka’s distributed broker. The binlog events for inserts, updates and deletes are converted in AVRO or JSON format before it’s forwarded to the data lake. Kafka is used as a data ingestion pipeline for distributed data process environment.
The MaxScale persistent connection feature has been available since version 1.3.0. It aims to reduce the load on the database servers in specific scenarios. Testing indicates benefits and feedback from live use has been positive.
Applications are often built on top of single MySQL-compliant database instance but often there is a need for more performance and/or availability than what one database instance can provide. Adding slaves or replacing standalone database server with full-fledged MySQL-compliant cluster often requires changes to the application.
Mark Riddoch, one of the MaxScale team, describes how a MaxScale plugin was developed for booking.com that allows the proxy to be used to reduce the load placed on the master in large MySQL replication environments.
The need for this post became obvious after receiving an increasing amount of questions which were related to linking, library versions and paths in MaxScale. Moreover, I know that there are many who want to make things with their bare hands so it is good to have something which hopefully makes the whole process smoother.
MaxScale is a modular proxy application, the modules can be considered as the building blocks of your proxy implementation within your MySQL database environment. It is important to know what building blocks you have at your disposal. The release of version 1.0 as a beta means that the number of available modules has grown once again. Normally I post about the incremental changes in what is available, but I thought that maybe it was a good time to post a short summary of all the modules.
Today we will use the MariaDB Cluster cluster we created in the previous two blog entries, and tie it all together with an HA Proxy virtual machine setup with separate read and write pools. This assumes your application is already using different connections for reads and writes, or you're using MaxScale, MySQL Proxy, etc to splits reads and writes.