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.
The MaxScale team have been working hard fixing bugs and improving performance. On Friday we released a update of MaxScale, the pluggable proxy for MySQL and MariaDB, I wanted to write a little about a few of those changes. I will not mention every change, there are release notes that give the list of bugs fixed in this version, but rather highlight a couple of performance related changes and describe the rationale behind them. However before I start on the two items I wanted to discuss just a quick note to say that this version introduces cmake as the means to build MaxScale.
Tonight I will give a presentation on Max Scale (An Advanced Proxy for MySQL) for the Chicago MySQL Meetup