High availability is one of the most important aspects of running a business. Whether it is a simple app for a small group of users or a large service used by millions, downtime costs a lot of money and ruins everyone’s day. No matter how hard we try, downtime is inevitable.
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.
Please join Roger Bodamer, MariaDB’s Chief Product Officer, on Thursday, October 6 to learn about the exciting new features in MariaDB MaxScale 2.0 that enable rapid innovation for web applications without impacting the architecture that simultaneously supports your legacy applications. In this webinar, we will cover:
I wanted to do some tests with MariaDB MaxScale and realized that the two existing routers (beyond the binlog router that is, which is a bit special) didn't do what I wanted them to do. What I was looking for was a simple round-robin feature and neither the readconnroute nor readwritesplit could be configured to do this. They are just too smart for my simple experiment.
The new CDC protocol modules in MaxScale 2.0.0 can be used to convert binlog events into easy to stream data. These streams can be guided to other systems for further processing and in-depth analysis. In this article, we set up a simple Kafka broker on CentOS 7 and publish changes in the database as JSON to it with the help of the new CDC protocol in MaxScale.
MariaDB MaxScale 2.0 can be configured for MariaDB 10 Binlog to AVRO conversion and the converted files can be requested with the new CDC protocol. This post will cover details of how to use the CDC protocol to request streaming data from MariaDB MaxScale.
If you are like me (let's for everyones sake hope you are not, though), you like to do things the hard way, in particular when it comes to testing things.
MariaDB MaxScale 2.0 for data streaming requires configuring the MariaDB Master to send binary log events to MariaDB MaxScale, and configuring MariaDB MaxScale to receive and convert binary logs. This blog is a step by step guide to successfully receive binary log events from a Master database and convert them to AVRO records.
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.
I am happy to see MariaDB Corporation announcing a major new version of MariaDB MaxScale. MaxScale 2.0 Beta is now available here.