For several years, I have hosted a medium sized Invision Power Board (IPB) site. The site has roughly 9,000+ users and 1,000,000+ posts. I work with MariaDB on a daily basis, and often find myself recommending it to customers. It's only appropriate I put my money where my mouth is, so to speak. This blog post has no benchmarks. It is just a very simple to follow set of steps I took to migrate my site from MySQL 5.1 to MariaDB 10 on CentOS 6.5 with very little downtime for the end users.
Remember when the LAMP stack was young? Open source Linux, Apache HTTPd, MySQL, and PHP were the insurgent technologies delivering world-beating performance and scale at unheard-of prices, back in the late 1990s and early 2000s. Now, the LAMP stack has evolved and matured. It remains the core of high-performance, scale-out application architectures, and has been for well over a decade now.
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.
For certain situations, the static structure of tables in a relational database can be very limited. Each column is statically defined, has a pre-defined type and you can only enter a value of that type into the column.You can be creative and list multiple values in one column, but then those values are not generally easily accessed and manipulated with other functions. You have to use an API or contortions of a function like SUBSTRING() to pull out a value you want. Even then, you have to know what is contained in the column to be able to manipulate it properly.
MySQL 5.6 introduces a new "multi-threaded slave" feature (aka "parallel replication") that turns the "slave SQL thread" into a number of distinct threads that each apply events to different schemas. This means that separate slave "worker threads" will be executing different positions in the slave's relay log (corresponding, of course, to different positions in the master's binary log) and that the Relay_Master_Log_File and Exec_Master_Log_Pos values in SHOW SLAVE STATUS output are no longer an accurate indicator of the current position of the slave. This causes severe problems if using Percona XtraBackup/innobackupex with the --slave-info option to get a backup that can be used to seed a new slave. Let's take a look at how multi-threaded slave works in MySQL 5.6, how innobackupex gets position information, how to recognize problems, and how to work around them to get a consistent backup that can be used for seeding a new slave.
In my last article, I explored how to enable Global Transaction IDs in MariaDB 10.0. I used a very common topology of 3 servers that is used for simple failover in case of a failure. In this article, I'm going to use that topology as a base to set up multi source replication and show how it is possible to simplify the high availability setup compared to regular MySQL replication.
As we start the beginning of our FY15, I want to thank all our customers, partners, staff, and community members for their contributions this past year. I'm proud of what we collectively achieved even as we drove significant changes in our business and organization. It's energizing to feel the momentum and enthusiasm building around MariaDB.