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.
Another OSCON has been wrapped up. While these year was slightly smaller than last year it was still an amazing event. The interesting part was that MySQL and MariaDB seemed to be bigger topics than in years gone by.
Now that I have been back in the office for a few days, I am getting caught up on my overloaded inbox, and have had some time to reflect on the event.
Part 1 of this blog post told the story of creating a binlog router for MaxScale that could connect to a MySQL Replication Master, download the binlog file from that master and store them locally on the MaxScale server. This post will concentrate on the other side of the router, the interaction with the MySQL slaves that will see MaxScale as the replication master.