Multi-source replication is a handy way to simplify your high availability database setup – especially as compared to the regular MySQL replication approach. This blog post looks at how it works.
Replication has been one of the most popular MySQL features since it made its way into the application more than a decade ago. Global Transaction IDs was introduced to make handling complex solutions easier. This blog post explains how MariaDB makes handling GTID simpler.
When it comes to database high availability, how many 9s do you really need? Finding the right mix of reliability and infrastructure complexity is vital to make the best use of your resources. In this blog, we will take a high-level look at three common approaches, spanning from 99.9% to 99.999% uptime.
The 2.1.3 GA release of MariaDB MaxScale, introduces the following key features for the secure setup of MariaDB MaxScale Binlog Server:
The binlog cache files in the MaxScale host can now be encrypted.
MaxScale binlog server also uses SSL in communication with the master and the slave servers.
This blog covers how the binary log encryption works in MariaDB Server and in MariaDB MaxScale.
We are happy to announce the general availability (GA) of MariaDB Server 10.2! MariaDB Server 10.2 is the newest major version of MariaDB Server, the fastest growing open source relational database.
Join us for one of our full-day roadshows coming to a city near you! MariaDB is hosting educational roadshows across North America to showcase exciting new products and solutions, and share best practices for enabling critical enterprise features such as high availability and security. MariaDB experts will lead content-rich sessions on open source, product features, architecture and security.
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 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.
Losing temporary tables on a slave when binlog_format is not set to ROW is a well-known problem, and there is even a way to avoid it, as described by the safe slave shutdown procedure in the MySQL documentation. However, the documentation doesn't describe how to fix your slave if you accidentally shut it down while it has temporary tables open. In this blog post, I'll describe how to do that.