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.
The latest set of updates for MaxScale has just been released, among the highlights of this alpha release are improved Galera support, the introduction of the first phase of the filter API and server maintenance mode.
I have spent some time thinking about and working on a project that went public on GitHub at the beginning of this year. That project is called MaxScale and is primarily a proxy server for MySQL/MariaDB databases, although it can be something much more than this. The obvious and often asked question is why do we need another proxy? I want to try to give you a flavor for what MaxScale is and why I think there is a need for a tool like MaxScale. The architecture of MaxScale makes it different from your average proxy