MaxScale, an open-source database-centric router for MySQL and MariaDB makes High Availability possible by hiding the complexity of backends and masking failures. MaxScale itself however is a single application running in a Linux box between the client application and the databases - so how do we make MaxScale High Available? This blog post shows how to quickly setup a Pacemaker/Corosync environment and configure MaxScale as a managed cluster resource. We will guide you step by step on how to enable basic High Availability by setting up three Linux Centos 6.5 servers with MaxScale.
With MariaDB, as with any service, you must monitor user resource usage to ensure optimal performance. MariaDB provides detailed statistics for resource usage on per-user basis that you can use for database service monitoring and optimization. User statistics are especially useful in shared environments to prevent a single gluttonous user from causing server-wide performance deterioration. If you detect abnormal use, you can apply fine-grained limits, as we'll see.
MaxScale for MariaDB and MySQL hides the complexity of database scaling from the application. To streamline building MaxScale from source and running the test suite, you can automate the process with some useful tools to meet your needs. I have created a Vagrant / Puppet setup I'd like to share with you.
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 explains how MariaDB makes handling GTID simpler
MaxScale 1.0 from SkySQL is now in Beta and there are some cool features in it, I guess some adventurous people has already put it into production. There are still some rough edges and stuff to be fixed, but it is clearly close to GA. One thing missing though are something to manage starting and stopping MaxScale in a somewhat controlled way, which is what this blog is all about.
Here we take a look at how one of the example filters supplied with the MaxScale 1.0 beta can answer that simplest of profiling questions - "Which of my database queries run within the MySQL server for the longest time?".
We all know that in general it's a bad idea to have columns values contain too much "hidden" information, and in particular for primary keys, this is a big no-no, although I know that not everybody agrees here. In some cases though, there is data that at it's heart contains several aspects and we just cannot avoid this, the prime example being data and time values. What I mean here is that a single datetime value has aspects that aren't always obvious from the datetime value itself. Examples include leap year information and weekday.
Let's assume you want to start an automatically expanding and shrinking MySQL replication cluster with up-to seven database servers. This blog shows how to setup up and start MaxScale to work with a master and a single slave and, when needed, how it adapts to the changing cluster configurations. While the set up here is simple similar behavior can be applied in bigger and more complex scenarios.
I spend perhaps too much time generating and reviewing numbers and charts and reports, but the right combination of tools can make this enjoyable (or at least less tedious). For me, that generally means using the pandas data analysis library and the python programming language to analyze data stored in MariaDB or MySQL.
Today we're going to cover how to upgrade MySQL 5.1 to MariaDB 10 on Centos 6 in place. This tutorial is a general outline, and the steps were performed on an out-of-the-box install of MySQL 5.1. Do be careful to check your configuration file(s) when completed.