Archive for the ‘MariaDB’ Category

MariaDB 10.1.1 Overview and Highlights

Saturday, October 25th, 2014

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

https://downloads.mariadb.org/mariadb/10.1.1/

This is the second alpha release of MariaDB 10.1, so there are a lot of new changes and functionalities added, and many, many bugs fixed (I counted 637). Since it’s alpha, I’ll only cover the major changes and additions, as there are a lot of great new features, and omit covering any of the bug fixes (feel free to browse them all here).

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

And here are other new features of note:

You can read more about the 10.1.1 release here:

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

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

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

Hope this helps.

 

Ignoring the lost+found Directory in your Datadir

Wednesday, October 15th, 2014

I still get asked about the lost+found directory enough, and so I wanted to provide a current update.

The lost+found directory is a filesystem directory created at the root level of a mapped drive. Thus this is common to see if you create your mysql datadir at the root level of a mapped drive.

In the past, you could ignore it, if it wasn’t too problematic for you, or you could move your datadir down a level, and then it wouldn’t be created in the datadir anymore.

However, there is now the –ignore-db-dir option. It is actually not too new (it’s been in MariaDB since 5.3.9 and 5.5.28, and in MySQL as of 5.6.3), but I don’t think many are too familiar with it.

But when you do run into this problem, some/many would prefer to add a single line to the config file rather than move the datadir.

To do this, just add the following option to your my.cnf file, under the [mysqld] section (it cannot be set dynamically):

ignore-db-dir=lost+found

And just to show the example:

Before updating my.cnf file:

mysql> select version();
+--------------------+
| version()          |
+--------------------+
| 5.5.40-MariaDB-log |
+--------------------+

mysql> show global variables like 'ignore_db_dirs';
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| ignore_db_dirs |       |
+----------------+-------+

Update my.cnf file and restart mysqld:

mysql> show global variables like 'ignore_db_dirs';
+----------------+------------+
| Variable_name  | Value      |
+----------------+------------+
| ignore_db_dirs | lost+found |
+----------------+------------+

mysql> use lost+found
ERROR 1102 (42000): Incorrect database name 'lost+found'

Now you see the lost+found directory is ignored now.

Of course, you can omit multiple directories. However, if you need to add more than one, then you *must* use multiple instances of the ignore_db_dirs= option, one for each directory you want to ignore. That is, you cannot separate them by comma, even though that is how it will be displayed when you have more than one being ignored (I think it treats the comma as part of the name, so then neither of the dirs you want to ignore would be ignored):

For instance, if I want to ignore both “lost+found” and “test”, then you must add the following to the config file:

ignore-db-dir=lost+found
ignore-db-dir=test

Then restart mysqld:

mysql> show global variables like 'ignore_db_dirs';
+----------------+-----------------+
| Variable_name  | Value           |
+----------------+-----------------+
| ignore_db_dirs | lost+found,test |
+----------------+-----------------+

Hope this helps.

 

MariaDB 5.5.40 Overview and Highlights

Friday, October 10th, 2014

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

https://downloads.mariadb.org/mariadb/5.5.40/

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 interested, the official MariaDB 5.5.40 release notes are here:

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

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

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

Hope this helps.

 

MariaDB 10.0.14 Overview and Highlights

Tuesday, October 7th, 2014

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

https://downloads.mariadb.org/mariadb/10.0.14/

This is the fifth GA release of MariaDB 10.0, and 15th overall release of MariaDB 10.0.

This is primarily a bug-fix release. (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. TokuDB upgraded to 7.5.0
  2. XtraDB upgraded to 5.6.20-68.0
  3. InnoDB upgraded to 5.6.20
  4. Spider upgraded to 3.2.11
  5. SphinxSE upgraded to 2.1.9
  6. The Feedback plugin now includes statistics on collation usage.
  7. Error log has a flood protection that is activated after 10 identical unsafe warnings and disables them for the next 5 minutes.
  8. Many fixes and optimizations for the Power8 platform.
  9. As per the MariaDB Deprecation Policy, this will be the last release of MariaDB 10.0 for both Ubuntu 13.10 “Saucy” and Mint 16 “Petra”.
  10. With the recent release of CentOS 7 and RHEL 7, we are pleased to now provide packages for both distributions. Instructions for how to enable the repositories can be found by visiting the “Installing MariaDB with YUM” page and the repository configuration tool.
  11. Crash in GROUP_CONCAT(IF () ORDER BY 1) (MDEV-6743)
  12. Server crashes in my_hash_first if shutdown is performed when FLUSH LOGS is running (MDEV-6616)
  13. Slave replicating using GTID doesn’t recover correctly when master crashes in the middle of transaction (MDEV-6462)
  14. MariaDB crash on Power8 when built with advance tool chain (MDEV-6450)

As always, it’s great to see all of the fixes alone from TokuDB, XtraDB, InnoDB, Spider, and Sphinx (and thus if you’re relying on any of these technologies, I would consider upgrading). The Power8 enhancements are very nice to see also! (If you’re running Power8 and looking for performance improvements, then you should definitely look into upgrading.) The crash fixes are mostly obscure, but double-check them, just in case they might affect you currently, and if so, then plan to upgrade.

You can read more about the 10.0.14 release here:

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

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

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

Hope this helps.

 

MySQL 5.7.5 Overview and Highlights

Tuesday, October 7th, 2014

MySQL 5.7.5 was recently released (it is the latest MySQL 5.7, and is the “m15″ or “Milestone 15″ release), and is available for download here and here.

As for the fixes/changes, there are quite a few (the official release was split into 3 separate emails), which is expected in such an early milestone release.

The main highlights for me were (though the enhancements, and potentially impactful changes, are definitely not limited to this list):

  • InnoDB: The innodb_buffer_pool_size parameter is now dynamic, allowing you to resize the buffer pool without restarting the server. The resizing operation, which involves moving pages to a new location in memory, is performed chunks. Chunk size is configurable using the new innodb_buffer_pool_chunk_size configuration option. You can monitor resizing progress using the new Innodb_buffer_pool_resize_status status variable. For more information, see Resizing the InnoDB Buffer Pool Online.
  • Replication: When replicating from a master running a version earlier than MySQL 5.6.0 [Read "5.5" or "5.1"] to a slave running MySQL 5.6.0 or later, the slave requires the master_uuid value, which is the server_uuid value from the master. The master_uuid value is unsupported on the older master, and in such a replication situation could become invalid on the newer slave. A check for empty master_uuid now ensures that the slave uses an empty value for master_uuid. (Bug #18338203)
  • Incompatible Change: mysql_install_db has been rewritten from Perl into C++. This enables it to be provided as an executable binary and eliminates its dependency on having Perl installed.
  • MySQL builds on Windows using Visual Studio now require Visual Studio 2013 or later. The previous requirement was Visual Studio 2010 or later. (Bug #18404381)
  • Now, MYSQL_MAINTAINER_MODE is on by default when compiling debug builds with GCC, and MYSQL_MAINTAINER_MODE enbles -Werror regardless of whether GCC or Clang is used.
  • MySQL now includes DTrace support on Oracle Linux 6 or higher with UEK kernel. If DTrace is present, server builds will detect it with no special CMake options required.
  • Incompatible Change: A new log record type (MLOG_FILE_NAME) is used to identify file-per-table tablespaces that have been modified since the last checkpoint. This enhancement simplifies tablespace discovery during crash recovery and eliminates scans on the file system prior to redo log application. For more information about the benefits of this enhancement, see Tablespace Discovery During Crash Recovery. This enhancement changes the redo log format, requiring that MySQL be shut down cleanly before upgrading to or downgrading from MySQL 5.7.5.
  • Incompatible Change: The InnoDB storage engine can no longer be disabled. The –skip-innodb option is deprecated and has no effect, and its use results in a warning. It will be removed in a future MySQL release. This also applies to its synonyms (–innodb=OFF, –disable-innodb, and so forth). A new innodb_lock_no_retry flag for the –debug option is now available.
  • Incompatible Change: The Performance Schema now provides a user_variables_by_thread table that exposes user-defined variables. For more information, see Performance Schema Connection Attribute Tables. In consequence of this change, the server now limits user-defined variable names to a maximum of 64 characters, the length of the VARIABLE_NAME column in the table. Previously, the server did not enforce a limit.
  • The optimizer computes more accurate costs for semi-join materialization. (Bug #18558561)
  • To generate execution plans, the optimizer uses a cost model that is based on estimates of the cost of various operations that occur during query execution. The optimizer has a set of compiled-in default “cost constants” available to it to make decisions regarding execution plans. The optimizer now has in addition a database of cost estimates to use during execution plan construction. These estimates are stored in the server_cost and engine_cost tables in the mysql system database and are configurable at any time: Any non-NULL cost estimate stored in the cost model tables overrides the corresponding compiled-in default estimate. Any NULL estimate indicates to the optimizer to use the compiled-in default. Implementation and testing is ongoing to make it safe for DBAs to change these values. Currently, changing them should be considered at your own risk. If you upgrade to this release of MySQL from an earlier version, you must run mysql_upgrade (and restart the server) to incorporate these changes into the mysql database.
  • The optimizer now uses more exact index statistics. Currently, the improved values are used by InnoDB, with these effects: 1) In many cases, better execution plans result for queries for which previously a less optimal join index or table join order was chosen. 2) The row estimates in EXPLAIN output are more accurate, as well as the filter values in some cases. 3) Cardinality estimates in the index statistics displayed by SHOW INDEX are more accurate for InnoDB tables.
  • During query execution plan construction, the optimizer now uses condition filtering to make better use of all conditions on a table in determining the estimate of qualifying rows that will be joined to the next table. For example, even though there might be an index that can be used to select rows, there might also be additional conditions in the WHERE clause that can further restrict the estimate for qualifying rows. Use of additional conditions is controlled by the condition_fanout_filter flag of the optimizer_switch system variable. This flag is on by default but can be disabled to suppress use of condition filtering (for example, for a query that is found to perform better without it).
  • Security Note: Incompatible Change: MySQL 5.6 deprecated passwords that used the older pre-4.1 password hashing format. Support for these passwords is now removed, which involves the following changes. Applications that use any feature no longer supported must be modified. The mysql_old_password authentication plugin is removed. The –secure-auth option to the server and client programs is the default, but is now a no-op. It is deprecated and will be removed in a future MySQL release. The –skip-secure-auth option to the server and client programs is no longer supported and using it produces an error.
  • Incompatible Change: Strict SQL mode for transactional storage engines (STRICT_TRANS_TABLES) is now enabled by default.
  • InnoDB: SPATIAL indexes can now be used for InnoDB tables. InnoDB supports indexing of spatial data types, including use of ALTER TABLE … ALGORITHM=INPLACE for online operations (ADD SPATIAL INDEX). To support transaction isolation properties, InnoDB uses predicate locking. A predicate lock locks the minimum bounding rectangle (MBR) used for a query so that other transactions cannot insert or modify a row that would match the query condition.
  • Incompatible Change: Previously, mysql_upgrade performed an upgrade by invoking the mysql and mysqlcheck clients. mysql_upgrade has been reimplemented to generate the required SQL statements itself and execute them by communicating directly with server.
  • Incompatible Change: In MySQL 5.6.6, the YEAR(2) data type was deprecated. Support for YEAR(2) has now been removed. Once you upgrade to MySQL 5.7.5 or newer, any remaining YEAR(2) columns must be converted to YEAR(4) to become usable again. For conversion strategies, see YEAR(2) Limitations and Migrating to YEAR(4). For example, run mysql_upgrade after upgrading.
  • Incompatible Change: The GET_LOCK() has been reimplemented using the metadata locking (MDL) subsystem and its capabilities have been extended.
  • InnoDB: For optimal shutdown and recovery performance, shutdown and recovery phases are now supported by the multi-threaded page cleaner feature (innodb_page_cleaners) that was introduced in MySQL 5.7.4. (Bug #18805275)
  • InnoDB: Instead of inserting one index record at a time, InnoDB now performs a bulk load when creating or rebuilding indexes. This method of index creation is also known as a “sorted index build”. This enhancement, which improves the efficiency of index creation, also applies to full-text indexes.
  • InnoDB: InnoDB memory allocations now are instrumented for the Performance Schema and will appear in the memory summary tables.
  • InnoDB: You can now truncate undo logs that reside in undo tablespaces. This feature is enabled using the innodb_undo_log_truncate configuration option. For more information, see Truncating Undo Logs That Reside in Undo Tablespaces.
  • InnoDB: Work was done to introduce the notion of attachable transactions in InnoDB (for AutoCommit / ReadOnly / ReadCommitted / NonLocking transactions). This is used to read from InnoDB Data Dictionary tables. Along with this, attachable transactions were exposed to the server. Data Dictionary access code will use them to read Data Dictionary data.
  • Replication: Retrying of transactions is now supported when multi-threading is enabled on a slave. In previous versions, slave_transaction_retries was treated as equal to 0 when using multi-threaded slaves. (Bug #16390504, Bug #68465)
  • Replication: Global transaction identifiers (GTIDs) are now logged in a MySQL system table whenever they are enabled on the server, which lifts a previous requirement to use binary logging when replicating with GTIDs. If binary logging is disabled, the server stores the GTID for each transaction in the mysql.gtid_executed table as the transaction is executed. If binary logging is enabled, then, whenever the binary log is rotated or the server is shut down, the server also writes into the new binary log the GTIDs for all transactions from the previous binary log.
  • Replication: The new variable simplified_binlog_gtid_recovery can be used to change the way binary log files are searched for previous GTIDs during recovery, speeding up the process when a large number of binary log files exist. (Bug #69097, Bug #16741603, Bug #74071, Bug #19686914)
  • Replication: Multi-threaded slaves can use the new slave_preserve_commit_order variable to ensure that the order which transactions were committed on the master is preserved on the slave. This prevents the slave from entering a state that the master was not in and is well suited to using multi-threaded slaves for replication read scale-out.
  • Replication: The new options binlog_group_commit_sync_delay and binlog_group_commit_sync_no_delay_count provide a way to configure the synchronization of the binary log. This enables more transactions to be synchronized together to disk at once, reducing the overall time to commit a group of transactions because the larger groups require fewer time units per group.
  • Replication: To make monitoring of a replication setup easier, various replication related variables have been moved to the performance_schema tables. This is particularly helpful for monitoring multi-source replication.
  • The mysqladmin flush-logs command now permits optional log types to be given, to specify which logs to flush. Following the flush-logs command, you can provide a space-separated list of one or more of the following log types: binary, engine, error, general, relay, slow. These correspond to the log types that can be specified for the FLUSH LOGS SQL statement. Thanks to Daniël van Eeden for the patch. (Bug #60878, Bug #12368203)
  • Scalability for InnoDB tables was improved by avoiding THR_LOCK locks. As a result of this change, DML statements for InnoDB tables that previously waited for a THR_LOCK lock will wait for a metadata lock. (Bug #42147, Bug #11751331)
  • The Boost.Geometry library now is required to build MySQL.

And that pretty much just covers the highlights of the “Functionality Added or Changed” section. I’m not even getting into the “Bugs Fixed” section, of which there were 296 (many InnoDB & Replication)! So there has been a lot going on in this release. If you’re running some 5.7 version, then you should definitely upgrade. (But this should not be used for production systems yet, of course.)

You can view the full 5.7.5 changelogs here:

http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-5.html

Hope this helps.

 

MySQL 5.6.21 Overview and Highlights

Friday, October 3rd, 2014

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

For this release, there was 1 “InnoDB Notes” and 1 “Functionality Added or Changed” bug fix (and 0 “Security Fix”), so not much there, but of course they should be noted:

  1. InnoDB Note: The –skip-innodb option is now deprecated and its use results in a warning. It will be removed in a future MySQL release. This also applies to its synonyms (–innodb=OFF, –disable-innodb, and so forth).
  2. Functionality Added: Internally, spatial data types such as Geometry are represented as BLOB values, so when invoked with the –hex-blob option, mysqldump now displays spatial values in hex. (Bug #43544, Bug #11752369)

In addition to those, there were 43 other bug fixes (the “partitioning” bug is also an “InnoDB” bug):

  • 12 InnoDB
  • 13 Replication
  • 18 Miscellaneous
  •   1 Partitioning

The highlights for me were 3 InnoDB regression bugs fixed and an important InnoDB/Partitioning performance-related bug fix as well (there were also 2 InnoDB/memcached bugs, and 13 replication bugs, so if using memcached or replication, you should review the full changelogs), so check if they might have affected you:

  1. InnoDB: An ALTER TABLE … ADD FOREIGN KEY operation could cause a serious error. (Bug #19471516, Bug #73650, Bug #73761 – Public, & Percona Bug #1366073)
  2. InnoDB: During recovery, a segmentation fault would occur when marking a table as corrupt. (Bug #18942294)
  3. InnoDB: With a transaction isolation level less than or equal to READ COMMITTED, gap locks were not taken when scanning a unique secondary index to check for duplicates. As a result, duplicate check logic failed allowing duplicate key values in the unique secondary index. (Bug #19140907, Public Bug #73170) References: This bug is a regression of Bug #16133801 (Public Bug #68021).
  4. InnoDB; Partitioning: Large numbers of partitioned InnoDB tables could consume much more memory when used in MySQL 5.6 or 5.7 than the memory used by the same tables used in previous releases of the MySQL Server. (Bug #17780517, Bug #70641) References: This bug was introduced by Bug #11764622, Bug #57480.

Conclusions:

So while there were no major changes, those 3 InnoDB 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.

The last bug really only relates to partitioned InnoDB tables, so if you’re not using them, then it’s not really a big deal. However, of course, if you are and you are running an affected version, then I would consider upgrading due to the memory over-consumption.

Similarly, if running memcached, I’d recommend checking those fixes and affected versions to see if you might benefit from an upgrade also.

The full 5.6.21 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-21.html

Hope this helps. :)

 

MySQL 5.5.40 Overview and Highlights

Thursday, September 25th, 2014

MySQL 5.5.40 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” bugs this time, and 18 bugs overall fixed.

Out of the 18 bugs, most seemed rather minor or obscure, but there are 3 I think are worth noting (all 3 are InnoDB-related, regressions, and serious if you encounter them, so best to be aware of them):

  • InnoDB: An ALTER TABLE … ADD FOREIGN KEY operation could cause a serious error. (Bug #19471516, Bug #73650)
  • InnoDB: With a transaction isolation level less than or equal to READ COMMITTED, gap locks were not taken when scanning a unique secondary index to check for duplicates. As a result, duplicate check logic failed allowing duplicate key values in the unique secondary index. (Bug #19140907) References: This bug is a regression of Bug #16133801.
  • InnoDB: During recovery, a segmentation fault would occur when marking a table as corrupt. (Bug #18942294)

Unfortunately, none of the bug reports are viewable. Even the one in public bug tracker has been marked “private”. So there is no telling what versions this affects. Bugs #73648 & 73648, the next closest viewable bugs were submitted 8/19/14 and 8/20/14, respectively. Thus it was a recently filed bug, and hopefully doesn’t affect too many previous versions. If I were running 5.5.39, using InnoDB with FKs, I think I’d upgrade. In fact, I might upgrade anyway because of the 3rd bug as well, because corruption is not that uncommon during recovery, and a segmentation fault at that time would just make a bad day worse.

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

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

Hope this helps.

 

MariaDB 10.0.13 Overview and Highlights

Tuesday, August 12th, 2014

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

https://downloads.mariadb.org/mariadb/10.0.13/

This is the fourth GA release of MariaDB 10.0, and 14th overall release of MariaDB 10.0.

This is primarily a bug-fix release.

Here are the main items of note:

  1. InnoDB upgraded to 5.6.19.
  2. XtraDB upgraded to 5.6.19-67.0.
  3. TokuDB upgraded to 7.1.7.
  4. Performance_Schema upgraded to 5.6.20.
  5. Connect engine supports partitioning.
  6. Many plugins have had their maturity level increased (from beta to gamma or from gamma to stable).
  7. filesort-with-small-limit-optimization is now visible through the slow query log and a new status variable, sort_priority_queue_sorts.
  8. New variables aria_pagecache_file_hash_size and key_cache_file_hash_size for determining the number of hash buckets for open and changed files for Aria and MyISAM respectively.

You can read more about the 10.0.13 release here:

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

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

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

Hope this helps.

 

MariaDB 5.5.39 Overview and Highlights

Tuesday, August 5th, 2014

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

https://downloads.mariadb.org/mariadb/5.5.39/

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 interested, the official MariaDB 5.5.39 release notes are here:

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

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

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

Hope this helps.

 

MySQL 5.6.20 Overview and Highlights

Tuesday, August 5th, 2014

MySQL 5.6.20 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 Fix”, 1 “InnoDB Important Change”, and 7 “Functionality Added or Changed” fixes, all of which should be read in case they might affect you (though for this release, these mostly appear to be minor – some [default] changes, build notes/changes, and deprecations):

  1. Security Fix: The linked OpenSSL library for the MySQL 5.6 Commercial Server has been updated from version 1.0.1g to version 1.0.1h. Versions of OpenSSL prior to and including 1.0.1g are reported to be vulnerable to CVE-2014-0224. This change does not affect the Oracle-produced MySQL Community build of MySQL Server 5.6, which uses the yaSSL library instead.
  2. InnoDB Important Change: Redo log writes for large, externally stored BLOB fields could overwrite the most recent checkpoint. The 5.6.20 patch limits the size of redo log BLOB writes to 10% of the redo log file size. The 5.7.5 patch addresses the bug without imposing a limitation. For MySQL 5.5, the bug remains a known limitation. As a result of the redo log BLOB write limit introduced for MySQL 5.6, innodb_log_file_size should be set to a value greater than 10 times the largest BLOB data size found in the rows of your tables plus the length of other variable length fields (VARCHAR, VARBINARY, and TEXT type fields). Failing to do so could result in “Row size too large” errors. No action is required if your innodb_log_file_size setting is already sufficiently large or your tables contain no BLOB data. (Bug #69477)
  3. Replication: The new system variable binlog_impossible_mode controls what happens if the server cannot write to the binary log, for example, due to a file error. For backward compatibility, the default for binlog_impossible_mode is IGNORE_ERROR, meaning the server logs the error, halts logging, and continues updates to the database. Setting this variable to ABORT_SERVER makes the server halt logging and shut down if it cannot write to the binary log. (Bug #51014)
  4. CMake support was updated to handle CMake version 3.
  5. New Debian7, Ubuntu12.04, and Ubuntu14.04 distribution support that was introduced with 5.6.17 now comes with the platform-specific packaging source placed under the packaging directory, in the deb-precise, deb-wheezy, and deb-trusty directories.
  6. Support for LinuxThreads has been removed from the source code. LinuxThreads was superseded by NPTL in Linux 2.6. (Bug #72888)
  7. By default, mysql_install_db creates a my.cnf file in the installation base directory using a template. This may be undesireable for some deployments. To enable this behavior to be suppressed, mysql_install_db now supports a –keep-my-cnf option to preserve any existing my.cnf file and not create a new my.cnf file. (Bug #71600)
  8. The mysqlhotcopy utility is now deprecated and will be removed in a future version of MySQL. Among the reasons for this: It works only for the MyISAM and ARCHIVE storage engines; it works on Unix but not Windows. Alternatives include mysqldump and MySQL Enterprise Backup.
  9. The timed_mutexes system variable has no effect and is deprecated.

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

  • 11 InnoDB
  • 09 Replication
  • 01 Partitioning
  • 31 Miscellaneous

There were 2 regression bugs fixed, so check if they might have affected you:

  1. InnoDB: A regression introduced in MySQL 5.6.5 would cause full-text search index tables to be created in the system tablespace (space 0) even though innodb_file_per_table was enabled.
  2. When a SELECT included a derived table in a join in its FROM list and the SELECT list included COUNT(DISTINCT), the COUNT() returned 1 even if the underlying result set was empty.

Conclusions:

I’ve not too much to say about this release regarding whether one should upgrade or not. I will say that if you are running a *Commercial* version of MySQL 5.6, pre-5.6.20, and you use SSL, then you should upgrade. Aside from that, it more depends if you’re affected by one of these bugs or not.

The full 5.6.20 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-20.html

Hope this helps. :)

 


Period Panties by Period Panteez Menstrual Underwear Menstruation PMS Panty