MariaDB 10.0.11 Overview and Highlights

MariaDB 10.0.11 was recently released, and is available for download here:

This is the second GA release of MariaDB 10.0, and 12th overall release of MariaDB 10.0.

This is primarily a bug-fix release.

Here are the main items of note:

  1. Updated TokuDB engine to version 7.1.6
  2. Updated Spider storage engine to version 3.2 (now Gamma)
  3. Updated XtraDB storage engine to version 5.6.17-65.0
  4. Updated InnoDB storage engine to version 5.6.17
  5. Updated performance_schema to version 5.6.17
  6. Updated Connect, and OQGraph engines.
  7. Online ALTER TABLE works for partitioned tables
  8. New system variable default_regex_flags. To make MariaDB RLIKE operator behave in a non-standard but backward compatible way use
    SET @@default_regex_flags='DOTALL';
  9. As per the MariaDB Deprecation Policy, this will be the last release of MariaDB 10.0 for both Ubuntu 12.10 “Quantal” and Mint 14 “Nadia”.

You can read more about the 10.0.11 release here:

And if interested, you can review the full list of changes in 10.0.11 (changelogs) here:

Hope this helps.


Another reason for Xtrabackup error “log block numbers mismatch”

I ran into an issue the other day where Xtrabackup was not completing and threw the following error:

xtrabackup: error: log block numbers mismatch:
xtrabackup: error: expected log block no. 134860907, 
but got no. 176803931 from the log file.
xtrabackup: Error: xtrabackup_copy_logfile() failed.

When researching this error, I found that this error is generally caused when the following 2 conditions must are met, and this is generally when “xtrabackup cannot catch up with log writing activity on the server, so the log wraps around before xtrabackup can copy records before they are overwritten”:

  1. The log block numbers must wrap around, which only happens once per 1 GB of log writes.
  2. The wrap-around point must be between the last checkpoint and the current log tail at the time the backup starts.

Discussed here:

When this does occur as a result of the above (and not a bug), then it’s usually an I/O issue, either on the MySQL-side or the disk-side. One you can check with the /dev/null redirect of the actual data (i.e., if it then completes, perhaps you have some IO issue, so investigate that, and/or perform during a period of low-activity).

In this specific case, however, it was a new version of Xtrabackup, low-load, 6G InnoDB log files, …

So what was the problem?

Here the user was trying to use the “xtrabackup” binary to dump a MySQL 5.6 instance. Once switched to “xtrabackup_56” binary, as described here, it worked as expected.

Hope this helps.