Last week we continued the MariaDB Roadshow in Europe and visited Paris, Brussels and Amsterdam. We have now completed 5 out of 10 events from this tour. The interest in this roadshow is overwhelming - in Amsterdam we even needed to put extra chairs into the room! So far attendees of the roadshow series especially liked topics around MariaDB MaxScale, security features in MariaDB as well as the MariaDB roadmap session. Monty was among the speakers in Helsinki and Amsterdam.
Parallel replication is a much-expected feature of MySQL. It’s available in MariaDB 10.0 and in MySQL 5.7. Yet, both lose efficiency when replicating through intermediate masters. In this post, we’ll explain how parallel replication works and why it does not play well with intermediate masters. We’ll also offer a solution (hint: it involves Binlog Servers).
Team MariaDB is touring across several European regions again with the theme "Scaling at its Best!". Beside product pitches our technical experts will help you understand how to take advantage of the wide range of new features and enhancements available now in MariaDB 10, MaxScale and other MariaDB solutions.
MaxScale’s filter system is very flexible and enables a new way of interacting with queries. The upcoming firewall filter shows just one of the many ways that you can control and manage the flow of queries through MaxScale.
When I started my career in early nineties, the Internet, the open source software movement and the Linux operating system were in their infancy and MariaDB and MySQL did not exist. Today open source is a mainstream software delivery mechanism, and web applications are built upon open source stacks which include Linux and MariaDB. Sybase was the first relational database I worked with - a then leading relational technology in early nineties.
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.
MariaDB MaxScale is now RC and together with all the MariaDB team that has been involved in the project we need to thank all the companies that agreed to become part of the MaxScale Beta Test Plan. This major step in the MaxScale life (read more here) had an important impact on the MaxScale QA process.
We have asked some companies to help us in testing MaxScale in “real” environments with different custom settings, different configurations and with traffic load as close to reality as possible.
This time of the year it is traditional, at least in the UK, to look back and reflect on the year that is coming to a close. Since we have just produced the release candidate for MaxScale and are looking forward to the GA release early in the New Year, it seems like a good time to reflect on the events that have bought us to this stage in the story of MaxScale.
One of the nice things about the "plug and play" approach of MaxScale is that people constantly find ways of using it that were not originally envisaged when we designed MaxScale. One such configuration that I have heard of from multiple sources is using monitoring outside of MaxScale itself. This post will discuss a little about how monitoring works and how it can be moved outside of MaxScale. In particular a simplified example will be presented which shows how to use the notification mechanism in Galera to control MaxScale's use of the nodes in a Galera cluster.
How can we find extra ways to test MaxScale? It‘s now working its way through a beta program, heading for general release. As part of the team responsible for its development, I’ve been looking for ways to find obscure bugs. Several approaches are involved, including unit tests and system tests. But another thing we wanted to try was to put a real life application, written by other people, in front of MaxScale.