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.
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.
We've dropped a user, now we want to change the DEFINER on all database objects that currently have it set to this dropped user?
This should be possible by checking the INFORMATION_SCHEMA tables of the appropriate object types (routines, triggers, views and events) and performing an ALTER on each of them that just modifies the DEFINER but nothing else, right?
It's important to understand which Galera version you are running, for proper compatibility of MariaDB with the Galera replication library, and also to check which featureset you have access to. However, Galera version numbering can be difficult to decipher because of its complex scheme.
Version numbering in Galera consists of three different components:
Over the summer, SkySQL has taken big strides in our collaboration with strategic partners. Our relationship with IBM has deepened and broadened as the porting and optimization of MariaDB on Power8 servers has progressed. The performance results look very promising and this collaboration is already opening some very exciting discussions with lead customers.