This guide will help you in compiling and debugging MariaDB (MySQL, Percona) within the Eclipse IDE on Linux and using cmake for source project preparation. It will be split in parts to keep each post lightweight and with a finite objective. At the end of reading this series of blog posts you should be able to:
MariaDB 5.5.37 was recently released (it is the latest MariaDB 5.5), and is available for download here:
https://downloads.mariadb.org/mariadb/5.5.37/
This is a maintenance release, and so there are not too many big changes of note, just a number of normal bug fixes. However, there are a few items worth mentioning:
If you are installing MySQL ODBC Driver and encounter the following error:
Error 1918. Error installing ODBC driver MySQL ODBC 5.1 Driver, ODBC error 13: The setup routines for the MySQL ODBC 5.1 Driver could not be loaded due to system error code 126: The specified module could not be found. ...\myodbc5S.dll).. Verify...
Then you will need to install the Microsoft Visual C++ 2010 Redistributable Package (select the appropriate one for your OS architecture below):
64-bit version:
In a previous post, I discussed debugging stored procedures with RESIGNAL, which is of great value when troubleshooting errors raised by your stored procedures, functions, triggers, and events as of MySQL/MariaDB 5.5.
However, as of MySQL 5.6 and MariaDB 10.0, there is GET DIAGNOSTICS, which can be used to get the exact error details as well.
RESIGNAL just outputs the error, as it comes from the server, for instance:
ERROR 1146 (42S02): Table 'db1.t1' doesn't exist
I was recently debugging a stored procedure and could not easily identify the underlying reason for why it was failing.
It had a standard exit handler catch-all for SQLEXCEPTION, which was:
DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN SELECT ...; END;
When there was an error, it didn't really output anything useful.
As of MySQL 5.5, there is RESIGNAL:
"RESIGNAL passes on the error condition information that is available during execution of a condition handler within a compound statement inside a stored procedure or function, trigger, or event."
MariaDB replication in general works as follows: on a master server, all updates to the database are written into the binary log as binlog events, a slave server connects to the master and reads the binlog events and applies the events locally to replicate the same changes as done on the master. A server can be both a master and a slave at the same time, it is thus possible for binlog events to replicated through multiple levels of servers.
I ran into an interesting issue today, while examining some EXPLAIN outputs, and wanted to share the findings, as some of this is undocumented.
Basically, you can start with a very simple InnoDB table - 2 INT columns, Primary Key (PK) on the 1st column, regular index on the 2nd:
CREATE TABLE `t1` ( `id1` int(10) unsigned NOT NULL, `id2` int(10) unsigned DEFAULT NULL, PRIMARY KEY (`id1`), KEY `id2` (`id2`) ) ENGINE=InnoDB;
The query is:
SELECT id1 FROM t1;
This is a straight-forward query with no WHERE clause.
Migrating from MySQL to MariaDB is generally a straightforward
procedure: you can shut down MySQL, install MariaDB, and start it
up with a very good chance of success. When
upgrading/crossgrading/migrating from one release of MySQL or
MariaDB to another, it is important to run
mysql_upgrade. The same is true when migrating from
MySQL to MariaDB, in part because MariaDB has some different
definitions for certain privilege tables. This means that the
structures of the MySQL tables are not valid for MariaDB, a
problem easily fixed by mysql_upgrade, unless
you are trying to import an SQL dump from MySQL that creates
tables using the old-style structures and tries to interact with
them before it is possible to run mysql_upgrade.
Let's take a look at why this is a problem and how to solve it.
…
[Read more]MariaDB 10.0.8 was recently released as RC ("Release Candidate"), and is available for download here:
https://downloads.mariadb.org/mariadb/10.0.8/
This is the first RC release of MariaDB 10.0. It is primarily a bug-fix and polishing release, and all features planned for MariaDB 10.0 GA are included in this release.
There were 6 notable changes in MariaDB 10.0.8:
The first blogpost in this series did a quick introduction to MaxScale, but now it is time start getting our hands dirty. We will get a more practical view on MaxScale and begin to put it to work. The following is based on a simple Proof of Concept that I did recently. The application is a mid-size web-based online shop where scalability is becoming an issue. They use PHP and with an old and rather inflexible framework, so even though changing how the database is used is possible, it's not easy and having database routing in the application code isn't a very good idea either.