MariaDB 10.0.20 Overview and Highlights

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

https://downloads.mariadb.org/mariadb/10.0.20/

This is the eleventh GA release of MariaDB 10.0, and 21st overall release of MariaDB 10.0.

There were no major functionality changes, but there was one security fix, 6 crashing bugs fixed, some general upstream fixes, and quite a few bug fixes, so let me cover the highlights:

  • Security Fix: Client command line option –ssl-verify-server-cert (and MYSQL_OPT_SSL_VERIFY_SERVER_CERT option of the client API) when used together with –ssl will ensure that the established connection is SSL-encrypted and the MariaDB server has a valid certificate. This fixes CVE-2015-3152.
  • Crashing Bug: mysql_upgrade crashes the server with REPAIR VIEW (MDEV-8115).
  • Crashing Bug: Server crashes in intern_plugin_lock on concurrent installing semisync plugin and setting rpl_semi_sync_master_enabled (MDEV-363).
  • Crashing Bug: Server crash on updates with joins still on 10.0.18 (MDEV-8114).
  • Crashing Bug: Too large scale in DECIMAL dynamic column getter crashes mysqld (MDEV-7505).
  • Crashing Bug: Server crashes in get_server_from_table_to_cache on empty name (MDEV-8224).
  • Crashing Bug: FreeBSD-specific bug that caused a segfault on FreeBSD 10.1 x86 (MDEV-7398).
  • XtraDB upgraded to 5.6.24-72.2
  • InnoDB updated to InnoDB-5.6.25
  • Performance Schema updated to 5.6.25
  • TokuDB upgraded to 7.5.7

Given the security fix, you may want to consider upgrading if that particular CVE is of concern to you. Also, please review the crashing bugs to see if they might affect you, and upgrade if so. Also, if running TokuDB, XtraDB, InnoDB, or Performance Schema, you may also want to benefit from those fixes, as well as the new MariaDB fixes (139 in all).

You can read more about the 10.0.20 release here:

https://mariadb.com/kb/en/mariadb-10020-release-notes/

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

https://mariadb.com/kb/en/mariadb-10020-changelog/

Hope this helps.

MariaDB 5.5.44 Overview and Highlights

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

https://downloads.mariadb.org/mariadb/5.5.44/

This is a maintenance release, and no major changes, so there are only several noteworthy items (but one of those being a security fix and five potential crashing bug):

  • Security Fix: Client command line option –ssl-verify-server-cert (and MYSQL_OPT_SSL_VERIFY_SERVER_CERT option of the client API) when used together with –ssl will ensure that the established connection is SSL-encrypted and the MariaDB server has a valid certificate. This fixes CVE-2015-3152.
  • Crashing Bug: mysql_upgrade crashes the server with REPAIR VIEW (MDEV-8115).
  • Crashing Bug: Server crashes in intern_plugin_lock on concurrent installing semisync plugin and setting rpl_semi_sync_master_enabled (MDEV-363).
  • Crashing Bug: Server crash on updates with joins still on 10.0.18 (MDEV-8114).
  • Crashing Bug: Too large scale in DECIMAL dynamic column getter crashes mysqld (MDEV-7505).
  • Crashing Bug: Server crashes in get_server_from_table_to_cache on empty name (MDEV-8224).
  • XtraDB upgraded to 5.5.42-37.2
  • TokuDB upgraded to 7.5.7

Given the security fix, you may want to review the CVE to see if this is something you need to address. Also, please review the crashing bugs to see if they might affect you, and upgrade if so. Also, if running TokuDB or XtraDB, you may also want to benefit from those fixes, as well as the new MariaDB fixes (59 in all).

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

https://mariadb.com/kb/en/mariadb/development/release-notes/mariadb-5544-release-notes/

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

https://mariadb.com/kb/en/mariadb/development/changelogs/mariadb-5544-changelog/

Hope this helps.

MariaDB 10.1.5 Overview and Highlights

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

https://downloads.mariadb.org/mariadb/10.1.5/

This is the 3rd beta, and 6th overall, release of MariaDB 10.1. There were not many major changes in this release, but a few notable items, as well as many overall bugs fixed (I counted 306).

Since it’s beta, 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 course it goes without saying that do not use this for production systems since it is still only beta. However, I definitely recommend installing it on a test server and testing it out. And if you happen to be running a previous version of 10.1, then you should definitely upgrade to this latest release.

You can read more about the 10.1.5 release here:

https://mariadb.com/kb/en/mariadb-1015-release-notes/

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

https://mariadb.com/kb/en/mariadb-1015-changelog/

Hope this helps.

MySQL 5.6.25 Overview and Highlights

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

For this release, there are 2 “Functionality Added or Changed” items of note:

  • Functionality Added/Changed: MySQL distributions now include an innodb_stress suite of test cases. Thanks to Mark Callaghan for the contribution. (Bug #76347)
  • Functionality Added/Changed: my_print_defaults now masks passwords. To display passwords in cleartext, use the new –show option.

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

  • 10 InnoDB
  •   8 Replication
  •   3 Partitioning (one overlaps w/ an InnoDB bug fix)
  • 35 Miscellaneous (and 6 of those were specifically for “MySQL Enterprise Firewall”)

The highlights for me are 5 of the replication bugs, 1 partitioning bug, 1 performance-related bug, 1 wrong results bug, and 9 crashing bugs:

  • Replication: When using semisynchronous replication performance was degrading when the number of threads increased beyond a certain threshold. To improve performance, now only the thread which is committing is responsible for deleting the active transaction node. All other operations do not touch this active transaction list. (Bug #75570)
  • Replication: When binary logging was enabled, using stored functions and triggers resulting in a long running procedure that inserted many records caused the memory use to increase rapidly. This was due to memory being allocated per variable. The fix ensures that in such a situation, memory is allocated once and the same memory is reused. (Bug #75879)
  • Replication: If an error was encountered while adding a GTID to the received GTID set, the log lock was not being correctly released. This could cause a deadlock. (Bug #75781)
  • Replication: When master_info_repository=TABLE the receiver thread stores received event information in a table. The memory used in the process of updating the table was not being freed correctly and this could lead to an out of memory error. The fix ensures that after an event is flushed to the relay log file by a receiver thread, the memory used is freed. (Bug #72885, Bug #69848)
  • Replication: Using mysqlbinlog to process log events greater than 1.6GB failed with an out of memory error. This was caused by an internal error converting the length variable. The fix upgrades the length variable to avoid overflow in both encoding and decoding functions. (Bug #74734)
  • Partitioning: Executing an ALTER TABLE on a partitioned table on which a write lock was in effect could cause subsequent SQL statements on this table to fail. (Bug #74288).
  • Performance-related: Certain queries for the INFORMATION_SCHEMA TABLES and COLUMNS tables could lead to excessive memory use when there were large numbers of empty InnoDB tables. (Bug #72322)
  • Incorrect Results: Queries that included a HAVING clause based on nondeterministic functions could produce incorrect results. (Bug #69638)
  • Crashing Bug: For small values of the read_rnd_buffer_size system variable, internal caching of temporary results could fail and cause query execution failure.
  • Crashing Bug: A failed FLUSH PRIVILEGES statement followed by statements to create or drop accounts could cause a server exit.
  • Crashing Bug: SHOW VARIABLES mutexes were being locked twice, resulting in a server exit.
  • Crashing Bug: For join queries with a large number of tables, the server could exit converting the join to a semi-join.
  • Crashing Bug: Deleting rows from mysql.user following by granting privileges to a new account could result in a server exit.
  • Crashing Bug: Within a stored procedure, access to view columns after DDL or FLUSH TABLES statements in the procedure could cause a server exit.
  • Crashing Bug: Execution of certain BINLOG statements while temporary tables were open by HANDLER statements could cause a server exit.
  • Crashing Bug: For a prepared statement with an ORDER BY that refers by column number to a GROUP_CONCAT() expression that has an outer reference, repeated statement execution could cause a server exit.
  • Crashing Bug: Specifying –general_log_file= (with an empty value) at server startup caused the server to fail and exit.

Conclusions:

So while there were no major changes, the partitioning fix could fix a potentially serious issue if you think you might encounter it (some partitioning use-cases involve frequent ALTERs), the replication fixes could potentially be important for you, and the numerous crashing (and performance-related & wrong results) bugs are important if you’re performing the operations that trigger them. So read through these, and if you’ll be affected by any of the above, or think you might be, then I’d recommend upgrading.

On a side note, there are several serious “MySQL Enterprise Firewall” bug fixes in this release, which I omitted above since the general public doesn’t have access to it, but if you are using it, you should upgrade due to the number of potentially serious bugs that exist in prior versions.

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

http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-25.html

Hope this helps. :)

MySQL 5.5.44 Overview and Highlights

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

http://dev.mysql.com/downloads/mysql/5.5.html

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

There were 0 “Functionality Added or Changed” items this time, and just 15 overall bugs fixed.

Out of the 15 bugs, there were 5 InnoDB bugs (1 of which also spans partitioning), 1 security-related bug, 1 performance-related, and 3 additional potential crashing bugs. Here are the ones worth noting:

  • InnoDB: An assertion was raised on shutdown due to XA PREPARE transactions holding explicit locks.
  • InnoDB: Removal of a foreign key object from the data dictionary cache during error handling caused the server to exit.
  • InnoDB: SHOW ENGINE INNODB STATUS output showed negative reservation and signal count values due to a counter overflow error.
  • InnoDB: Estimates that were too low for the size of merge chunks in the result sorting algorithm caused a server exit.
  • InnoDB; Partitioning: The CREATE_TIME column of the INFORMATION_SCHEMA.TABLES table now shows the correct table creation time for partitioned InnoDB tables. The CREATE_TIME column of the INFORMATION_SCHEMA.PARTITIONS table now shows the correct partition creation time for a partition of partitioned InnoDB tables. The UPDATE_TIME column of the INFORMATION_SCHEMA.TABLES table now shows when a partitioned InnoDB table was last updated by an INSERT, DELETE, or UPDATE. The UPDATE_TIME column of the INFORMATION_SCHEMA.PARTITIONS table now shows when a partition of a partitioned InnoDB table was last updated. (Bug #69990)
  • Security-related: A user with a name of event_scheduler could view the Event Scheduler process list without the PROCESS privilege.
  • Performance-related: Certain queries for the INFORMATION_SCHEMA TABLES and COLUMNS tables could lead to excessive memory use when there were large numbers of empty InnoDB tables. (Bug #72322)
  • Crashing Bug: SHOW VARIABLES mutexes were being locked twice, resulting in a server exit.
  • Crashing Bug: Under certain conditions, the libedit command-line library could write outside an array boundary and cause a client program crash.
  • Crashing Bug: For a prepared statement with an ORDER BY that refers by column number to a GROUP_CONCAT() expression that has an outer reference, repeated statement execution could cause a server exit.

I don’t think I’d call any of these urgent for all, but if running 5.5, especially if not a very recent 5.5, you should consider upgrading.

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

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-44.html

Hope this helps.

MariaDB 10.1.4 Overview and Highlights

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

https://downloads.mariadb.org/mariadb/10.1.4/

This is the 2nd beta, and 5th overall, release of MariaDB 10.1. Now that it is beta, there were not as many major changes in this release (compared to 10.1.3), but there were a few notable items as well as many overall bugs fixed (I counted 367).

Since it’s beta, 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 course it goes without saying that do not use this for production systems as it is only the 2nd beta release of 10.1. However, I definitely recommend installing it on a test server and testing it out. And if you happen to be running a previous version of 10.1, then you should definitely upgrade to this latest release.

You can read more about the 10.1.4 release here:

https://mariadb.com/kb/en/mariadb-1014-release-notes/

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

https://mariadb.com/kb/en/mariadb-1014-changelog/

Hope this helps.

MariaDB 10.0.19 Overview and Highlights

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

https://downloads.mariadb.org/mariadb/10.0.19/

This is the tenth GA release of MariaDB 10.0, and 20th overall release of MariaDB 10.0.

This was a quick release in order to get a fix for a mysql_upgrade bug (MDEV-8115) introduced in 10.0.18, so there is that, and only 9 other bug fixes.

Here are the main items of note:

  • Fixed the server crash caused by mysql_upgrade (MDEV-8115)
  • Connect upgraded to 1.03.0007

Due to the mysql_upgrade bug fix as well as all of the fixes in MariaDB 10.0.18 (including 5 Security fixes), I would definitely recommend upgrading to this if you are running a prior version of MariaDB 10.0, especially 10.0.18.

You can read more about the 10.0.19 release here:

https://mariadb.com/kb/en/mariadb-10019-release-notes/

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

https://mariadb.com/kb/en/mariadb-10019-changelog/

Hope this helps.

 

MariaDB 10.0.18 Overview and Highlights

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

https://downloads.mariadb.org/mariadb/10.0.18/

This is the ninth GA release of MariaDB 10.0, and 19th overall release of MariaDB 10.0.

There were no major functionality changes, but there were some general improvements, several security fixes, plus a 10.0.18 mysql_upgrade caution, and quite a few bug fixes, so let me cover what I feel are the main items of note:

  • Security Fixes: Fixes for the following security vulnerabilities:
  • InnoDB upgraded to 5.6.24
  • XtraDB upgraded to 5.6.23-72.1
  • Spider upgraded to 3.2.21
  • mroonga upgraded to 5.02
  • Performance Schema upgraded to 5.6.24
  • Connect upgraded to 1.03.0006
  • Deprecation Notice: As per the MariaDB Deprecation Policy, this will be the final release of MariaDB 5.5 for Fedora 19 “Schrödinger’s Cat”, Ubuntu 10.04 LTS “Lucid”, and Mint 9 LTS “Isadora”. When the next version of MariaDB 5.5 is released, repositories for these distributions will go away.
  • Important mysql_upgrade Caution: The mysql_upgrade in this version introduced a serious bug which affects mysql_upgrade. If already running a MariaDB 5.5.x version, then you can safely skip running mysql_upgrade. However, if migrating from MySQL to MariaDB 5.5, then note this bug. For this specific bug, the problem appears if the targeted databases include data structures such as views with binary or text blobs. The malfunction is in the REPAIR VIEW statement which the script calls.
    • The fix will appear in MariaDB 5.5.44, which will be available soon (MariaDB 5.5.44 includes all MySQL 5.5.44 fixes, so it will be available very shortly after MySQL 5.5.44 is released).

Given the security fixes, if you are running a prior version of 10.0, I would recommend upgrading. However, due to the mysql_upgrade bug in this version, I recommend upgrading to
10.0.19 instead (as it contains the fix for this bug).

You can read more about the 10.0.18 release here:

https://mariadb.com/kb/en/mariadb-10018-release-notes/

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

https://mariadb.com/kb/en/mariadb-10018-changelog/

Hope this helps.

 

MariaDB 5.5.43 Overview and Highlights

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

https://downloads.mariadb.org/mariadb/5.5.43/

This is a maintenance release, and so there were not too many major changes, but definitely a few worth mentioning, as well as one *important* caution:

  • Security Fixes: Fixes for the following security vulnerabilities:
  • Deprecation Notice: As per the MariaDB Deprecation Policy, this will be the final release of MariaDB 5.5 for Fedora 19 “Schrödinger’s Cat”, Ubuntu 10.04 LTS “Lucid”, and Mint 9 LTS “Isadora”. When the next version of MariaDB 5.5 is released, repositories for these distributions will go away.
  • Includes all bugfixes and updates from MySQL 5.5.43 (MySQL 5.5.43 Overview and Highlights)
  • TokuDB upgraded to 7.5.6
  • XtraDB upgraded to 5.5.42-37.1
  • Important mysql_upgrade Caution: The mysql_upgrade in this version introduced a serious bug which affects mysql_upgrade. If already running a MariaDB 5.5.x version, then you can safely skip running mysql_upgrade. However, if migrating from MySQL to MariaDB 5.5, then note this bug. For this specific bug, the problem appears if the targeted databases include data structures such as views with binary or text blobs. The malfunction is in the REPAIR VIEW statement which the script calls.
    • The fix will appear in MariaDB 5.5.44, which will be available soon (MariaDB 5.5.44 includes all MySQL 5.5.44 fixes, so it will be available very shortly after MySQL 5.5.44 is released).

Given the security fixes, you may want to review the CVEs to see if this is something you need to address. Also, if running TokuDB or XtraDB, you may also want to benefit from those fixes, as well as the new MariaDB fixes. However, if you plan on migrating from MySQL, if the above bug is relevant to you, then you should either upgrade to MariaDB 5.5.42, wait for 5.5.44, or possibly upgrade to MariaDB 10.0 (10.0.19 also contains the fix).

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

https://mariadb.com/kb/en/mariadb/development/release-notes/mariadb-5543-release-notes/

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

https://mariadb.com/kb/en/mariadb/development/changelogs/mariadb-5543-changelog/

Hope this helps.

 

MySQL 5.6.24 Overview and Highlights

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

For this release, there are 4 “Functionality Added or Changed” items:

  • Functionality Added/Changed: CMake support was updated to handle CMake version 3.1.
  • Functionality Added/Changed: The server now includes its version number when it writes the initial “starting” message to the error log, to make it easier to tell which server instance error log output applies to. This value is the same as that available from the version system variable. (Bug #74917)
  • Functionality Added/Changed: ALTER TABLE did not take advantage of fast alterations that might otherwise apply to the operation to be performed, if the table contained temporal columns found to be in pre-5.6.4 format (TIME, DATETIME, and TIMESTAMP columns without support for fractional seconds precision). Instead, it upgraded the table by rebuilding it. Two new system variables enable control over upgrading such columns and provide information about them:
    • avoid_temporal_upgrade controls whether ALTER TABLE implicitly upgrades temporal columns found to be in pre-5.6.4 format. This variable is disabled by default. Enabling it causes ALTER TABLE not to rebuild temporal columns and thereby be able to take advantage of possible fast alterations.
    • show_old_temporals controls whether SHOW CREATE TABLE output includes comments to flag temporal columns found to be in pre-5.6.4 format. Output for the COLUMN_TYPE column of the INFORMATION_SCHEMA.COLUMNS table is affected similarly. This variable is disabled by default.
  • Functionality Added/Changed: Statement digesting as done previously by the Performance Schema is now done at the SQL level regardless of whether the Performance Schema is compiled in and is available to other aspects of server operation that could benefit from it. The default space available for digesting is 1024 bytes, but can be changed at server startup using the max_digest_length system variable.

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

  • 15 InnoDB
  •   4 Replication
  •   1 Partitioning
  • 30 Miscellaneous

The highlights for me are the Partitioning bug and 2 of the Replication bugs (of the 15 InnoDB bugs, 5 were related to full-text search, and 6 were related to Memcached plugin, and the other 4 were mostly obscure):

  • Partitioning: A number of ALTER TABLE statements that attempted to add partitions, columns, or indexes to a partitioned table while a write lock was in effect for this table were not handled correctly.
  • Replication: When gtid_mode=ON and slave_net_timeout was set to a low value, the slave I/O thread could appear to hang. This was due to the slave heartbeat not being sent regularly enough when the dump thread found many events that could be skipped. The fix ensures that the heartbeat is sent correctly in such a situation.
  • Replication: When replicating from a MySQL 5.7.6 or later server to a MySQL 5.6.23 or earlier server, if the older version applier thread encountered an Anonymous_gtid_log_event it caused an assert. The fix ensures that these new log events added in MySQL 5.7.6 and later do not cause this problem with MySQL 5.6.24 and later slaves.

Conclusions:

So while there were no major changes, the partitioning fix covered a number of bugs, the replication fixes could potentially be important for you, and the numerous InnoDB full-text and Memcached fixes would be important if you’re using either of those. Thus if you rely on any of this, I’d consider upgrading.

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

http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-24.html

Hope this helps. :)