Archive for the ‘MariaDB’ Category

MariaDB 10.1.2 Overview and Highlights

Saturday, January 17th, 2015

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

This is the third alpha release of MariaDB 10.1, so there are still a lot of new changes, functionalities added, defaults changed, and many bugs fixed (I counted 117, which is *way* down from the 637 fixed in 10.1.1). Since it’s alpha, I’ll only cover the major changes and additions, and omit covering general bug fixes (feel free to browse them all here).

To me, these are the highlights of the new features:

You can read more about the 10.1.2 release here:

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

Hope this helps.


MariaDB 10.0.15 Overview and Highlights

Friday, January 16th, 2015

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

This is the sixth GA release of MariaDB 10.0, and 16th overall release of MariaDB 10.0.

This release has an important InnoDB/XtraDB fix, a new addition, security enhancements (and improvement) – all related to yaSSL, so be sure to check out these fixes if you’re running MariaDB 10.0, and not up to 10.0.15 yet. (MariaDB 10.0 is the current stable series of MariaDB. It is an evolution of the MariaDB 5.5 with several entirely new features not found anywhere else and with backported and reimplemented features from MySQL 5.6.)

Here are the main items of note:

  1. This release fixes a serious bug in InnoDB and XtraDB that sometimes could cause a hard lock up of the server (MDEV-7026)
  2. This is the first release that includes Mroonga full-text search storage engine.
  3. When compiled with OpenSSL, MariaDB now supports TLSv1.2 protocol. Limit it to TLSv1.2 ciphers only with –ssl_cipher=TLSv1.2. Limit it to SSLv3 ciphers with –ssl-cipher=SSLv3. RPM and DEB packages from are built with OpenSSL, others (for Windows and generic Linux) are built with yaSSL.
  4. Fixes for the following security vulnerabilities:
  5. Bundled PCRE is upgraded to 8.36
  6. InnoDB upgraded to 5.6.21
  7. XtraDB upgraded to 5.6.21-70.0
  8. TokuDB upgraded to 7.5.3
  9. SphinxSE upgraded to 2.2.6
  10. Updates to the CONNECT handler including:
  11. We now offer openSUSE repos, see the repository configuration tool for details on how to use it.

Given the severe InnoDB/XtraDB bug, if you’re running a prior MariaDB 10.0 version, I’d recommend upgrading (assuming you’re using InnoDB). Likewise, if you’re using SSL. And then there were a number of fixes to other fixes for TokuDB, CONNECT, and Sphinx, so if you’re using those technologies, you may want to consider upgrading as well.

You can read more about the 10.0.15 release here:

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

Hope this helps.


MySQL 5.6.22 Overview and Highlights

Tuesday, January 13th, 2015

MySQL 5.6.22 was recently released (it is the latest MySQL 5.6, is GA), and is available for download here.

For this release, there is 1 “Security Note”, 2 “Functionality Changed”, and 5 “Compilation Notes”, all benign, but let me address them:

  1. Security Note: The linked OpenSSL library for the MySQL Commercial Server has been updated from version 1.0.1h to version 1.0.1j. Issues fixed in the new version are described at
  2. Functionality Changed: Replication: The variable binlogging_impossible_mode has been renamed binlog_error_action. binlogging_impossible_mode is now deprecated. (Bug #19507567)
  3. Functionality Changed: Security: yaSSL was upgraded to version 2.3.5. (Bug #19695101)
  4. Compilation Notes: These are all rather minor, so I’ll spare the full entries here. However, if you build MySQL from source, it would be worth several minutes to read the 5 notes in the changelogs.

In addition to those, there were 46 other bug fixes:

  • 17 InnoDB
  •   9 Replication
  • 19 Miscellaneous
  •   1 Partitioning

The highlights for me are 6 of the InnoDB bugs, as 2 were regression bugs (crashing/corruption), 2 potentially corruption causing, another crashing, and 1 halting:

  1. InnoDB: An ALTER TABLE operation raised an assertion. When a foreign key object was removed from the dictionary cache, an incorrect foreign key object was removed from the rb-tree. (Bug #19908343) References: This bug is a regression of Bug #18806829.
  2. InnoDB: Pages with a checksum value of zero were incorrectly treated as empty pages. A page should only be considered empty if its checksum value and LSN field values are zero. (Bug #19500258, Bug #73689) References: This bug is a regression of Bug #17335427.
  3. InnoDB: The dict_set_corrupted() function attempted to update the clustered index of the SYS_INDEXES data dictionary table incorrectly. (Bug #19584379).
  4. InnoDB: The InnoDB data dictionary was not updated when a ALTER TABLE … CHANGE COLUMN operation changed the case of the column name. (Bug #19465984).
  5. InnoDB: A memory access violation caused fts_optimize_thread and mysqld to terminate. (Bug #19314480).
  6. InnoDB: A procedure, called from a function to perform an operation on a temporary table, caused the server to halt/stall. (Bug #19306524)


So while there were no major changes, those 6 InnoDB bugs (2 being regression bugs) are definitely of concern, so I’d be sure to review these to see if you’re running an affected version, and consider upgrading if so.

And with the yaSSL updates, if you use SSL connections, you may want to consider upgrading as well.

The full 5.6.22 changelogs can be viewed here (which has more details about all of the bugs listed above):

Hope this helps. :)


MariaDB 5.5.41 Overview and Highlights

Tuesday, January 13th, 2015

MariaDB 5.5.41 was recently released (it is the latest MariaDB 5.5), and is available for download here:

This is a maintenance release, and so there were not too many changes, *but* please take notice as there are 2 very important bug fixes:

Thus if you’re running pre-5.5.41 and have encountered, or even if you may be prone to, either bug #7026 or #7100, you should plan to upgrade.

If interested, the official MariaDB 5.5.41 release notes are here:

And the full list of fixed bugs and changes in MariaDB 5.5.41 can be found here:

Hope this helps.


MySQL 5.5.41 Overview and Highlights

Tuesday, January 13th, 2015

MySQL 5.5.41 was recently released (it is the latest MySQL 5.5, is GA), and is available for download here:

< Forgive me for the flurry of my latest release "Overview and Highlights" that will follow, as I had a serious-at-the-time health issue that delayed me for about a month. Back on track now though. :) >

This release, similar to the last 5.5 release, is mostly uneventful.

There was only 1 “Functionality Added or Changed” bugs this time, and 14 bugs overall fixed.

Out of the 14 bugs, there were 6 InnoDB bugs, and 2 replication bugs, all of which seemed rather minor or obscure. The one worth noting is the “Functionality Added or Changed” item, which was:

  • yaSSL was upgraded to version 2.3.5. (Bug #19695101)

With the recent yaSSL issues, if you use SSL certificates, you may want to consider upgrading to ensure you’re using the latest yaSSL.

Lastly, I should note there were some CMake notes, so if you compile MySQL yourself and use CMAKE, please see the full 5.5.41 changelogs.

For reference, the full 5.5.41 changelog can be viewed here:

Hope this helps.


MaxScale is GA

Tuesday, January 13th, 2015

MariaDB has announced that MaxScale is now GA.

“MaxScale is an open-source, database-centric proxy that works with MariaDB Enterprise, MariaDB 10 and Oracle MySQL®. Its pluggable architecture is designed to increase flexibility and aid in customization as well as a lightweight, high-speed networking core designed to facilitate throughput.

MaxScale simplifies the process of growth by isolating the application from scaling at the database level. This allows scaling databases while improving DBA productivity and developer agility. Additionally, MariaDB MaxScale provides continuity to applications during database failover, upgrades and faster rollout of new database features – all of which improves your end customer’s experience. Now, you can stay competitive and create new revenue generating services with MariaDB MaxScale’s flexible plugin architecture.”

(I quoted that from the email release, fwiw.)

Features include:

  • MariaDB and MySQL Client and Server protocols
  • MariaDB Galera and MySQL replication cluster monitoring
  • Connection and Statement based load balancing
  • Query Performance Logging
  • Query Statement Modification based on regular expressions
  • Query Duplication to another database, storage engine or application
  • and more

Download MaxScale:

Product Page:

External FAQ:


Upcoming MaxScale Webinar (January 15th):

Nice Blog on Read Write Splitting and MaxScale (by Vilho Raatikka):


Discussing the innodb_log_block_size variable

Tuesday, November 11th, 2014

Not a ground-breaking post here, but if you are interested in knowing more about the innodb_log_block_size variable, or if you use SSD cards and/or large InnoDB log files on ext4, then this is for you.

I’d read about it before briefly before, but didn’t give it too much thought until I ran across the following entry in an error log the other day:

InnoDB: Warning: innodb_log_block_size has been changed
from default value 512. (###EXPERIMENTAL### operation)

This got me wanting to know more.

Basically, this variable changes the size of transaction log records. Generally, the default of 512 is a good value. However, it has been found that setting it to 4096 has been beneficial when using SSD cards. (Note that while it is possible to set this to a value other than 512 or 4096, those are currently the only 2 values that make sense to use.)

Also, it has been found that 4096 is the best setting if you run ext4 along with innodb_flush_method=ALL_O_DIRECT (note both innodb_log_block_size and ALL_O_DIRECT are specific to XtraDB/XtraDB+; read: MariaDB and Percona server).

What is ALL_O_DIRECT and when it is useful?

“ALL_O_DIRECT: use O_DIRECT to open both data and log files, and use fsync() to flush the data files but not the log files. This option is recommended when InnoDB log files are big (more than 8GB), otherwise there might be even a performance degradation.”…/innodb_io.html#innodb_flush_method

Thus if you’re running large InnoDB log files (8G+) on ext4, you may want to consider ALL_O_DIRECT, and because you’re on ext4, you should set innodb_log_block_size=4096, the default log-block-size in ext4, in order to avoid the unaligned AIO/DIO warnings.

Likewise, if running with SSD cards, you’d likely see a performance improvement with innodb_log_block_size=4096 also.

If interested, there is a bit more about the innodb_log_block_size option here:…variables/#innodb_log_block_size…/innodb_io_55.html#innodb_log_block_size

Hope this helps.


MariaDB Launches Ambassadors Program

Tuesday, November 11th, 2014

It was announced today that the MariaDB Corporation is launching an Ambassadors Program on behalf of the MariaDB Foundation.

Colin Charles, Chief Evangelist at MariaDB Corporation said, “The MariaDB Ambassador Program is set up to recognize and support experienced contributors to the MariaDB and MySQL ecosystem who are responsible for representing, promoting and expanding the use of MariaDB and its ideals to the larger open source community and general public.”

He further added, “There are two distinct types of ambassadors, all of whom will be volunteers. Community Ambassadors will promote grassroots adoption in their specific region. Platform Ambassadors will contribute virtually through the creation of code, patches, features, and who lead MariaDB engineering efforts at their respective organizations. MariaDB Corporation will provide each Community Ambassador with funds to organize local MariaDB meetups and invite Platform Ambassadors to MariaDB Engineering meetings as guests.”

You can read the full press release here:


Disabling InnoDB in MySQL 5.6 and MariaDB 10.0

Sunday, November 9th, 2014

There are a few circumstances where one will not want to run with only MyISAM tables. In this case, it can be beneficial to completely disable InnoDB.

As InnoDB has become more prevalent, disabling it in MySQL requires a little more effort than before.

In MariaDB 10.0, you can still completely disable it as you have done in the past (just add the –skip-innodb option, specify default-storage-engine=MyISAM, and comment out other InnoDB options):


Alternatively, instead of –skip-innodb, you can instead use “innodb=OFF”:


In MySQL 5.6, the –skip-innodb option has been deprecated (though still currently works), and since InnoDB is the new “default” storage engine, you must set both “default-storage-engine” and the new “default-tmp-storage-engine” options to “MyISAM”. If you do not set the latter, you instance will not start, and the error log will simply complain that “Unknown/unsupported storage engine: InnoDB” and you won’t easily identify why:

2014-11-08 18:47:28 13524 [ERROR] Unknown/unsupported storage engine: InnoDB
2014-11-08 18:47:28 13524 [ERROR] Aborting

So, if you want to disable InnoDB in MySQL 5.6, you’ll need to specify the following:


For reference, this last part is documented in the manual here, but I felt a post was appropriate given the obscurity of this overall issue.

Also, if you disable InnoDB in MySQL, you may see an extraneous message in your error log, as described here. Also, in both MySQL and MariaDB, you’ll likely see a few strange messages after running mysql_upgrade, which I discuss in more detail here.

Hope this helps.


Period Panties by Period Panteez Menstrual Underwear Menstruation PMS Panty