オリジナル版：http://dev.mysql.com/doc/refman/5.6/en/news-5-6-6.html
MySQL 5.6.6(マイルストーンリリース)は世界でもっともポピュラーなオープンソースデータベースの新バージョンです。
このリリースの新機能はベータ品質です。他の試作版と同様に、製品レベルのシステムあるいは、重要なデータを持つシステムにインストールする場合は慎重にしてください。
5.6.6はMySQL 5.5の全機能を含んでいます。MySQL 5.6の新機能の概要については、以下の"MySQL 5.6の何が新しくなったのか"を参照してください。
http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html
新しいサーバにMySQL 5.6.6をインストールする情報として、以下のMySQLのインストールドキュメントを参照してください。
http://dev.mysql.com/doc/refman/5.6/en/installing.html
以前のMySQLリリースからアップグレードするには、以下のアップグレードについての注意事項を参照してください。
http://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html
このリリースから以前のリリースへのダウングレードはサポートされていませんのでご注意下さい
MySQL Server 5.6は、ダウンロード・ページの「開発版リリース」からソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。
http://dev.mysql.com/downloads/
すべてのミラーサイトが現在、最新であるとは限らないことに注意してください。あるミラーサイトでこのバージョンを見つけることができない場合は、再度確認を行うか、あるいは別のダウンロード・サイトを選択してください。
MySQL 5.6向けのプラットフォームリストに注目してください：
- x86(32ビット)とx86_64上のApple Mac OS X 10.6と10.7
(OS X 10.5はサポート対象からはずされました)
- x86(32ビット)とx86_64上のDebian 6
(Debian 5はサポート対象からはずされました)
- x86(32ビット)とx86_64上のRedHat Enterprise / Oracle Linux 5, 6
(RHEL/OL 4はサポート対象からはずされました)
- x86_64上のSuSE Enterprise Linux 11
(SLES 10はサポート対象からはずされました)
- x86(32ビット)とx86_64上のgeneric Linux (kernel 2.6)
- x86_64上のFreeBSD 9
(FreeBSD 7 and 8はサポート対象からはずされました)
- Sparc (64 bit)、x86 (32ビット)、x86_64上のOracle Solaris 10, 11
- x86(32ビット)とx86_64上のWindows Vista, 7, 2008
(Windows XPと2003はサポート対象からはずされました)
Linuxディストリビューション固有のパッケージは固有のフォーマット(RPM、もしくはdeb)で提供され、加えて一般的なtar.gzパッケージがこれらのディストリビューションに適合します。
RedHatに互換性のあるCentOSやFedoraに関してはRedHatと一般的なパッケージの両方で動作します。
オペレーティングシステムのより新しいバージョンを使用するのであれば、バイナリ互換性アプローチ（より古いバージョンのためにビルドされたアプリケーションのサポート）によってMySQL 5.6の使用が保障されるはずです。
バグレポート、バグ修正、パッチ等の情報をお待ちしております。
http://forge.mysql.com/wiki/Contributing
5.6.6の全ての「バグフィックス」のリストはオンラインでも閲覧できます
http://dev.mysql.com/doc/refman/5.6/en/news-5-6-6.html
もしプロダクションレベルのシステムでMySQLを稼動させるならば、MySQL製品、バックアップ、モニタリング、モデリング、開発、管理ツールを含むMySQL Enterprise Editionに注目してください。MySQLのパフォーマンス、セキュリティ、稼働時間を高いレベルで達成します。
http://mysql.com/products/enterprise/
D.1.1. Changes in MySQL 5.6.6 (2012-Aug-7, Milestone 9)
Binary Logging
* Performance: The server now implements group commit for the
binary log: Multiple commits are grouped in memory, then
written and flushed to disk as a group rather than
individually. This reduces the number of writes and flushes,
improving performance of binary logging. Group commit works
for all storage engines. InnoDB implements some optimizations
to take advantage of group commit capability.
These system variables were added in conjunction with group
commit:
+ binlog_order_commits: Whether to commit transactions in
the same order they are written to the binary log or
permit them to be committed in parallel.
+ binlog_max_flush_queue_time: How long in microseconds to
keep reading transactions from the flush queue before
proceeding with the group commit.
+ innodb_flush_log_at_timeout: Write and flush logs every N
seconds.
Performance Schema Notes
* The Performance Schema is now enabled by default. To
disable it, set performance_schema=off at server startup.
In addition, the Performance Schema now automatically sizes
the values of several of its parameters at server startup if
they are not set explicitly. For example, it sizes the
parameters that control the sizes of the events waits tables
this way. To see which parameters are sized under this policy,
use mysqld --verbose --help and look for those with a default
value of -1, or see Section 20.11, "Performance Schema System
Variables."
For each autosized parameter that is not set at server startup
(or is set to -1), the Performance Schema determines how to
set its value based on the value of the following system
values, which are considered as "hints" about how you have
configured your MySQL server:
max_connections
open_files_limit
table_definition_cache
table_open_cache
To override autosizing for a given parameter, set it a value
other than -1 at startup. In this case, the Performance Schema
assigns it the specified value.
At runtime, SHOW VARIABLES displays the actual values that
autosized parameters were set to.
If the Performance Schema is disabled, its autosized
parameters remain set to -1 and SHOW VARIABLES displays -1.
Security Improvements
* These security improvements were implemented:
+ MySQL now provides a method for storing authentication
credentials securely in an option file named
.mylogin.cnf. To create the file, use the
mysql_config_editor utility. The file can be read later
by MySQL client programs to obtain authentication
credentials for connecting to a MySQL server.
mysql_config_editor writes the .mylogin.cnf file using
encryption so the credentials are not stored as clear
text, and its contents when decrypted by client programs
are used only in memory. For more information, see Section
4.6.6, "mysql_config_editor --- MySQL Configuration
Utility."
The .mylogin.cnf file can contain multiple sets of
options, known as "login paths." To specify which option
group to use from the .mylogin.cnf file for connecting to
the server, use the --login-path option. See Section
4.2.3.3.1, "Command-Line Options that Affect Option-File
Handling."
+ MySQL now supports stronger encryption for user account
passwords, available through an authentication plugin
named sha256_password that implements SHA-256 password
hashing. This plugin is built in, so it is always
available and need not be loaded explicitly. For more
information, including instructions for creating accounts
that use SHA-256 passwords, see Section 6.3.6.2, "The
SHA-256 Authentication Plugin."
Other changes associated with the introduction of the
sha256_password plugin:
o The old_passwords system variable previously
permitted values of 1 or 0 to control whether "old"
or "new" MySQL native password hashing was used by
the CREATE USER and GRANT statements and the
PASSWORD() function. Now old_passwords permits a
value of 2 to select use of SHA-256 password
hashing.
o SHA-256 password hashing (old_passwords=2) uses a
random salt value, which makes the result from
PASSWORD() nondeterministic. Consequently,
statements that use this function are no longer safe
for statement-based replication and cannot be stored
in the query cache.
o The server has a --default-authentication-plugin
option to specify the default plugin to associate
with new accounts for which no plugin is named
explicitly. This option also changes the initial
old_passwords value to be consistent with the
password hashing method required by the default
plugin, if necessary.
o If MySQL is built with OpenSSL, RSA encryption can
be used to transmit passwords during the client
connection process. The
sha256_password_private_key_path and
sha256_password_public_key_path system variables
permit the private and public key files to be named
on the server side. The Rsa_public_key status
variable displays the public key value. The mysql
and mysqltest clients support a --server-public-key
option permitting the public key file to be
specified explicitly when connecting to the server.
(This option is implemented through a new
MYSQL_SERVER_PUBLIC_KEY option to the
mysql_options() C API function.)
MySQL Connector support: Connectors that use the C client
library should work with sha256_password with no changes.
Connectors that implement the authentication process for
themselves must be updated to account for changes in the
client/server protocol.
+ The mysql.user table now has a password_expired column.
Its default value is 'N', but can be set to 'Y' with the
new ALTER USER statement (which also sets the Password
column to the empty string). After an account's password
has been expired, all operations performed in subsequent
connections to the server using the account result in an
error until the user issues a SET PASSWORD statement to
establish a new account password. For more information,
see Section 13.7.1.1, "ALTER USER Syntax."
If you upgrade to this release of MySQL from an earlier
version, you must run mysql_upgrade (and restart the
server) to incorporate this change into the mysql
database.
+ MySQL now has provision for checking password security:
o In statements that assign a password supplied as a
cleartext value, the value is checked against the
current password policy and rejected if it is weak
(the statement returns an ER_NOT_VALID_PASSWORD
error). This affects the CREATE USER, GRANT, and SET
PASSWORD statements. Passwords given as arguments to
the PASSWORD() and OLD_PASSWORD() functions are
checked as well.
o The strength of potential passwords can be assessed
using the new VALIDATE_PASSWORD_STRENGTH() SQL
function, which takes a password argument and
returns an integer from 0 (weak) to 100 (strong).
Both capabilities are implemented by the
validate_password plugin. If the plugin is not installed,
the affected statements and PASSWORD() and OLD_PASSWORD()
work as before (no password checking), and
VALIDATE_PASSWORD_STRENGTH() always returns 0.
The validate_password plugin also implements a set of
system variables corresponding to the parameters that
control password checking. If the plugin is installed,
you can modify these variables to configure the password
policy.
For more information, see Section 6.1.2.5, "The Password
Validation Plugin."
+ mysql_upgrade now produces a warning if it finds user
accounts with passwords hashed with the older pre-4.1
hashing method. Such accounts should be updated to use
more secure password hashing. See Section 6.1.2.3,
"Password Hashing in MySQL"
(Bug #65461, Bug #14136939)
Functionality Added or Changed
* Performance: InnoDB: The MySQL server now includes the widely
used memcached in-memory caching system, and a plugin that
allows fast NoSQL-style access to InnoDB tables through the
memcached protocol. This access method avoids the overhead of
SQL parsing and constructing a query optimization plan. You
can store the underlying data in a single InnoDB table, or
spread it across multiple tables. You can read and write data
through both memcached and SQL. For example, you can do fast
single-key lookups through memcached get calls, and do
statistical reports across all the data through SQL.
Several configuration options let you fine-tune this system.
See Section 14.2.10, "InnoDB Integration with memcached" for
full details.
* Performance: InnoDB: The persistent statistics feature for
InnoDB tables is now enabled by default, and can be controlled
at the level of individual tables. This feature involves the
configuration options innodb_stats_persistent,
innodb_stats_auto_recalc, and
innodb_stats_persistent_sample_pages, and the clauses
STATS_PERSISTENT, STATS_AUTO_RECALC, and STATS_SAMPLE_PAGES of
the CREATE TABLE and ALTER TABLE statements. See Section
14.2.5.2.9, "Persistent Optimizer Statistics for InnoDB
Tables" for usage details.
* Incompatible Change: The --safe-mode server option has been
removed.
* Incompatible Change: It is now explicitly disallowed to assign
the value DEFAULT to stored procedure or function parameters
or stored program local variables (for example with a SET
var_name = DEFAULT statement). This was not previously
supported, or documented as permitted, but is flagged as an
incompatible change in case existing code inadvertantly used
this construct. It remains permissible to assign DEFAULT to
system variables, as before, but assigning DEFAULT to
parameters or local variables now results in a syntax error.
After an upgrade to MySQL 5.6.6 or later, existing stored
programs that use this construct produce a syntax error when
invoked. If a mysqldump file from 5.6.5 or earlier is loaded
into 5.6.6 or later, the load operation fails and affected
stored program definitions must be changed.
* Important Change: Replication: It is now possible, in the
event that a multi-threaded slave fails while running with the
--relay-log-recovery option, to switch it safely to
single-threaded mode despite the presence of any gaps with
unprocessed transactions in the relay log. To accomplish this,
you can now use START SLAVE [SQL_THREAD] UNTIL
SQL_AFTER_MTS_GAPS to cause the slave SQL threads to run until
no more such gaps are found in the relay log. Once this
statement has completed, you can change the
slave_parallel_workers system variable, and (if necessary)
issue a CHANGE MASTER TO statement before restarting the
slave. (Bug #13893363)
References: See also Bug #13893310.
* Important Change: Replication: INSERT ON DUPLICATE KEY UPDATE
is now marked as unsafe for statement-based replication if the
target table has more than one primary or unique key. For more
information, see Section 16.1.2.3, "Determination of Safe and
Unsafe Statements in Binary Logging." (Bug #58637, Bug
#11765650, Bug #13038678)
* Important Change: Replication: The SHOW BINARY LOGS statement
(and its equivalent SHOW MASTER LOGS) may now be executed by a
user with the REPLICATION CLIENT privilege. (Formerly, the
SUPER privilege was necessary to use either form of this
statement.)
* Important Change: INSERT DELAYED is now deprecated, and will
be removed in a future release. Use INSERT (without DELAYED)
instead. (Bug #13985071)
* Important Change: The YEAR(2) data type is now deprecated
because it is problematic. YEAR(2) columns in existing tables
are treated as before, but YEAR(2) in new or altered tables
are converted to YEAR(4). Support for YEAR(2) will be removed
entirely in a future release of MySQL. For more information,
see Section 11.3.4, "YEAR(2) Limitations and Migrating to
YEAR(4)."
* Important Change: In MySQL, the TIMESTAMP data type differs in
nonstandard ways from other data types:
+ TIMESTAMP columns not explicitly declared with the NULL
attribute are assigned the NOT NULL attribute. (Columns
of other data types, if not explicitly declared as NOT
NULL, permit NULL values.) Setting such a column to NULL
sets it to the current timestamp.
+ The first TIMESTAMP column in a table, if not declared
with the NULL attribute or an explicit DEFAULT or ON
UPDATE clause, is automatically assigned the DEFAULT
CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP
attributes.
+ TIMESTAMP columns following the first one, if not
declared with the NULL attribute or an explicit DEFAULT
clause, are automatically assigned DEFAULT '0000-00-00
00:00:00' (the "zero" timestamp). For inserted rows that
specify no explicit value for such a column, the column
is assigned '0000-00-00 00:00:00' and no warning occurs.
Those nonstandard behaviors remain the default for TIMESTAMP
but now are deprecated and this warning appears at startup:
[Warning] TIMESTAMP with implicit DEFAULT value is deprecated.
Please use --explicit_defaults_for_timestamp server option (see
documentation for more details).
As indicated by the warning, to turn off the nonstandard
behaviors, enable the new explicit_defaults_for_timestamp
system variable at server startup. With this variable enabled,
the server handles TIMESTAMP as follows instead:
+ TIMESTAMP columns not explicitly declared as NOT NULL
permit NULL values. Setting such a column to NULL sets it
to NULL, not the current timestamp.
+ No TIMESTAMP column is assigned the DEFAULT
CURRENT_TIMESTAMP or ON UPDATE CURRENT_TIMESTAMP
attributes automatically. Those attributes must be
explicitly specified.
+ TIMESTAMP columns declared as NOT NULL and without an
explicit DEFAULT clause are treated as having no default
value. For inserted rows that specify no explicit value
for such a column, the result depends on the SQL mode. If
strict SQL mode is enabled, an error occurs. If strict
SQL mode is not enabled, the column is assigned the
implicit default of '0000-00-00 00:00:00' and a warning
occurs. This is similar to how MySQL treats other
temporal types such as DATETIME.
To upgrade servers used for replication, upgrade the slaves
first, then the master. Replication between the master and its
slaves should work provided that all use the same value of
explicit_defaults_for_timestamp:
1. Bring down the slaves, upgrade them, configure them with
the desired value of explicit_defaults_for_timestamp, and
bring them back up.
The slaves will recognize from the format of the binary
logs received from the master that the master is older
(predates the introduction of
explicit_defaults_for_timestamp) and that operations on
TIMESTAMP columns coming from the master use the old
TIMESTAMP behavior.
2. Bring down the master, upgrade it, and configure it with
the same explicit_defaults_for_timestamp value used on
the slaves, and bring it back up.
* InnoDB: Many DDL operations on InnoDB tables can now be
performed "online", without making the tables unavailable for
queries. Some operations, such as creating or dropping
indexes, even allow DML statements (INSERT, UPDATE, DELETE) on
the table while the operation is in progress. See Section
14.2.2.6, "Online DDL for InnoDB Tables" for full details.
* InnoDB: InnoDB tables now support the notion of "transportable
tablespaces", allowing .ibd files to be exported from a
running MySQL instance and imported into another running
instance. The FOR EXPORT clause of the FLUSH TABLE command
writes any unsaved changes from InnoDB memory buffers to the
.ibd file. After copying the .ibd file and a separate metadata
file to the other server, you can use the DISCARD TABLESPACE
and IMPORT TABLESPACE clauses of the ALTER TABLE statement to
bring the table data into a different MySQL instance.
For more information, see Section 13.7.6.3, "FLUSH Syntax."
* InnoDB: For systems with constant heavy workloads, or
workloads that fluctuate widely, several new configuration
options let you fine-tune the flushing behavior for InnoDB
tables: innodb_adaptive_flushing_lwm,
innodb_max_dirty_pages_pct_lwm, innodb_max_io_capacity, and
innodb_flushing_avg_loops. These options feed into an improved
formula used by the innodb_adaptive_flushing option. For full
details about improvements to flushing algorithms and options,
see Section 14.2.5.2.8, "Improvements to Buffer Pool
Flushing."
* Replication: The STOP SLAVE option SQL_BEFORE_GTIDS did not
function correctly, and the SQL_AFTER_GTIDS option for the
same statement did not function at all. (Bug #13810456)
* Replication: Added the --slave-rows-search-algorithms option
for mysqld, which determines the search algorithms used for
finding matches for slave updates when slave_allow_batching is
enabled, including whether or not table or index hashing is
used with searches employing a primary or unique key, some
other key, or no key.
* yaSSL was upgraded from version 1.7.2 to 2.1.4.
* The generic "procedure API" has been removed from the server.
This was formerly present as a means of writing server
procedures, but went unused except for PROCEDURE ANALYSE().
PROCEDURE ANALYSE() remains available, but is no longer
implemented using a public interface. (For information, see
Section 8.4.2.4, "Using PROCEDURE ANALYSE.") One consequence
of removing the procedure interface is that EXPLAIN SELECT ...
PROCEDURE ANALYSE() now works where previously it produced an
error.
* To improve scalability by reducing contention among sessions
for the global lock on the open tables cache, the cache now
can be partitioned into several smaller cache instances. A
session now need lock only one instance to access it for DML
statements. This segments cache access among instances,
permitting higher performance for operations that need to use
the cache when many there are many sessions accessing tables.
(DDL statements still require a lock on the entire cache, but
such statements are much less frequent than DML statements.)
A new system variable, table_open_cache_instances, permits
control over the number of cache instances. Each instance has
a size of table_open_cache / table_open_cache_instances. By
default, the number of instances is 1.
Three new status variables provide information about the
operation of the open tables cache. Table_open_cache_hits and
Table_open_cache_misses indicate the number of hits and misses
or lookups in the cache. Table_open_cache_overflows indicates
how many times, after a table is opened or closed, an instance
has an unused entry and the size of the instance is larger
than table_open_cache / table_open_cache_instances.
* Previously, for semi-join processing the outer query
specification was limited to simple table scans or inner joins
using comma syntax, and view references were not possible. Now
outer join and inner join syntax is permitted in the outer
query specification, and the restriction that table references
must be base tables has been lifted.
* It is now possible for client programs to pass connection
attributes to the server in the form of key/value pairs.
Attributes are manipulated using the
MYSQL_OPT_CONNECT_ATTR_RESET and MYSQL_OPT_CONNECT_ATTR_DELETE
options for the mysql_options() C API function, and the
MYSQL_OPT_CONNECT_ATTR_ADD option for the new mysql_options4()
function. Connection attributes are exposed through the
session_connect_attrs and session_account_connect_attrs
Performance Schema tables.
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 performance_schema
database.
For more information, see Section 21.8.3, "C API Function
Descriptions," and Chapter 20, "MySQL Performance Schema."
* Previously, the default value for the --bind-address option
was 0.0.0.0, which causes the server to accept TCP/IP
connections on all server host IPv4 interfaces. To make it
easier to use IPv6 connections without special configuration,
the default --bind-address value now is *. This is similar to
0.0.0.0, but causes the server to also accept TCP/IP
connections on all IPv6 interfaces if the server host supports
IPv6. (Another way to to accept IPv4 and IPv6 connections is
by using --bind-address=::, but in this case an error occurs
if the server host does not support IPv6.)
* The optimizer's cost model for disk-sweep Multi-Read Range
(DS-MRR) has been improved. The improved cost model makes it
more likely that DSMRR will be used for queries that read much
data from disk.
* For the WITH_SSL CMake option, "no" is no longer a permitted
value or the default value. The default is now bundled.
Consequently, MySQL now is always built with SSL support.
Bugs Fixed
* Performance: Partitioning: InnoDB: The statistics used by the
optimizer for queries against partitioned InnoDB tables were
based only on the first partition of each such table, leading
to use of the wrong execution plan. (Bug #13694811)
References: This bug was introduced by Bug #11756867.
* Performance: InnoDB: Improved the algorithm related to
adaptive flushing. This fix increases the rate of flushing in
cases where compression is used and the data set is larger
than the buffer pool, leading to eviction. (Bug #13990648, Bug
#65061)
* Performance: InnoDB: The order in which flushes are performed
when the innodb_flush_neighbors configuration option is
enabled was improved. The algorithm makes the
neighbor-flushing technique faster on HDD storage, while
reducing the performance overhead on SSD storage.
(innodb_flush_neighbors typically is not needed for SSD
hardware.) (Bug #13798956)
* Performance: InnoDB: This fix improves the speed of DROP TABLE
for InnoDB tables by removing a scan of the buffer pool to
remove entries for the adaptive hash index. This improvement
is most noticeable on systems with very large buffer pools and
the innodb_adaptive_hash_index option enabled. (Bug #13704145,
Bug #64284)
* Performance: Replication: All changes made as part of a given
transaction are cached; when the transaction is committed, the
contents of this cache are written to the binary log. When
using global transaction identifiers, the GTID identifying
this transaction must be the first event among all events in
the cache belonging to the transaction.
Previously, a portion of the cache was preallocated as a
buffer when the transaction began; upon commit it was
completed with a valid GTID. However, because it was not
possible to perform a seek in the cache, it was necessary to
flush it to a temporary file, and then seek within this file.
When the cache buffer is not big enough to accommodate all
changes comprising a given transaction, it swapped the data to
disk, then reinitialized the cache to have the buffer properly
filled with the correct data again. The buffer was actually
flushed and the cache reinitialized every time a GTID event
was written, even in those cases in which all events making up
a given transaction fit within the cache buffer, which could
negatively impact the performance of binary logging (and thus
replication) when using GTIDs.
Now the cache is reinitialized only when it is actually
necessary---in other words, only when the cache is in fact
swapped to disk.
In addition, the fix for this issue addresses a missing unlock
operation when the server failed to write an empty transaction
group and reduces the amount of code needed for prepending the
GTID to the contents of the cache before flushing the cache to
disk. (Bug #13877432)
References: See also Bug #13738296.
* Performance: Within stored programs, the overhead of making
statements log friendly was incurred even when the
corresponding log was not enabled. (Bug #12884336)
* Performance: The MD5() and SHA1() functions had excessive
overhead for short strings. (Bug #49491, Bug #11757443, Bug
#60227, Bug #14134662)
* Incompatible Change: Metadata was handled incorrectly for
objects such as tables or views that were used in a stored
program. Metadata for each such object was gathered at the
beginning of program execution, but not updated if DDL
statements modified the object during program execution (or
modified it between executions of the program if the program
remained in the stored program cache). This resulted in
mismatches between the actual object structure and the
structure the stored program believed the object to have
during execution, and caused problems such as data errors or
server crashes.
Now metadata changes to objects used in a stored program are
detected during execution and affected statements within the
program are reparsed so that they use the updated metadata.
Example: Suppose that a stored program executes this statement
in a loop and that the columns in the table t1 are altered
during loop execution:
SELECT * FROM t1;
Previously, errors occurred because program execution did not
detect that SELECT * evaluates to a different set of columns
after the change. Now the table change is detected and the
SELECT is reparsed to determine the new set of columns.
Reparsing occurs for other cases as well, such as t1 being
changed from a base table to a view or a TEMPORARY table. For
more information, see Section 8.9.4, "Caching of Prepared
Statements and Stored Programs."
There is a possible incompatibility regarding the new
behavior: Application code that assumed the previous behavior
and implemented a workaround may need to be changed.
Other instances of corrected problems:
+ SELECT * within a stored program could fail for TEMPORARY
tables created within the program using prepared
statements.
+ "Unknown column" errors or bad data could result from
changing the set of columns in a table used within a
stored program between executions of the program or while
the table was used within a program loop. Errors could
also occur under similar circumstances for a view if the
view definition was changed, for a TEMPORARY table if the
table was dropped.
+ Failure of triggers to notice metadata changes in objects
accessed within the program could cause trigger
malfunction.
+ Failure of a stored program to notice metadata changes in
objects accessed within the program could cause
replication to fail.
(Bug #61434, Bug #12652835, Bug #55678, Bug #11763018, Bug
#64574, Bug #13840615, Bug #33843, Bug #11747732, Bug #33289,
Bug #11747626, Bug #33255, Bug #11747619, Bug #33000, Bug
#11747566, Bug #27011, Bug #11746530, Bug #33083, Bug
#11747581, Bug #32868, Bug #11747537, Bug #12257, Bug
#11745236)
* Important Change: MySQL Cluster: mysqld_safe now traps Signal
13 (SIGPIPE) so that this signal no longer kills the MySQL
server process. (Bug #33984)
* InnoDB: Replication: When binary log statements were replayed
on the slave, the Com_insert, Com_update, and Com_delete
counters were incremented by BEGIN statements initiating
transactions affecting InnoDB tables but not by COMMIT
statements ending such transactions. This affected these
statements whether they were replicated or they were run using
mysqlbinlog. (Bug #12662190)
* InnoDB: Dropping an InnoDB temporary table could leave behind
the .ibd file if the table was created with the
innodb_file_per_table setting enabled. On Windows systems,
this could cause an additional problem: repeated attempts to
drop the file for 2000 seconds. In addition to resolving the
incorrect path name used to drop the file, this fix also
limits the retry loop to 10 seconds, for example if the file
cannot be removed because it is locked by a backup process.
(Bug #14169459)
* InnoDB: An assertion error could occur if an XA transaction
was created within a session designated as read-only. (Bug
#14108709)
* InnoDB: If a row was deleted from an InnoDB table, then
another row was re-inserted with the same primary key value,
an attempt by a concurrent transaction to lock the row could
succeed when it should have waited. This issue occurred if the
locking select used a WHERE clause that performed an index
scan using a secondary index. (Bug #14100254, Bug #65389)
* InnoDB: This fix improves the accuracy of the data in the
information_schema table innodb_metrics for systems with
innodb_buffer_pool_instances set to greater than 1. The
improved information applies to the number of pages flushed
from the buffer pool, specifically these entries in the table:
buffer_flush_batch_total_pages
buffer_flush_neighbor_total_pages
buffer_flush_adaptive_total_pages
buffer_flush_sync_total_pages
buffer_flush_background_total_pages
buffer_LRU_batch_total_pages
(Bug #14037167)
* InnoDB: In a transaction using the REPEATABLE READ isolation
level, an UPDATE or DELETE statement for an InnoDB table could
sometimes overlook rows recently committed by other
transactions. As explained in Section 14.2.4.3, "Consistent
Nonlocking Reads," DML statements within a REPEATABLE READ
transaction apply to rows committed by other transactions,
even if a query could not see those rows. (Bug #14007649, Bug
#65111)
* InnoDB: During an ANALYZE TABLE statement for an InnoDB table,
the server could hang (in non-debug builds), or an assertion
error could occur, indicating recursive acquisition of a lock
(in debug builds). (Bug #14007109)
* InnoDB: Further bug fixes:
Bug #14248833, Bug #65745; Bug #14213568; Bug #14106082;
Bug #14101563; Bug #13982017; Bug #13966453; Bug #13946118;
Bug #13940669, Bug #64901; Bug #13933132; Bug #13920437;
Bug #13907075; Bug #13867915; Bug #13847885; Bug #13838962;
Bug #13831840; Bug #13830371; Bug #13817703, Bug #61209;
Bug #13701973, Bug #64274; Bug #13641926; Bug #13641275;
Bug #12902967; Bug #12752572, Bug #61579;
Bug #11766634, Bug #59783; Bug #11758510, Bug #50723.
* Partitioning: If a partitioned table t1 was created using the
ROW_FORMAT option, attempting to perform ALTER TABLE t1
EXCHANGE PARTITION ... WITH TABLE t2 failed with the error
Tables have different definitions even if the definition for
table t2 was identical to that for t1. This occurred because a
check was made for an explicit ROW_FORMAT setting in the table
definition, and if this was set, the operation was rejected.
Now in such cases the row format actually used for each table
is checked explicitly and the EXCHANGE PARTITION operation is
permitted to execute if both row formats are the same. (Bug
#11894100)
* Partitioning: The PARTITION_COMMENT column of the
INFORMATION_SCHEMA.PARTITIONS table truncated partition
comments, displaying only the first 80 characters.
As part of the fix for this issue, the maximum length for a
partition comment is now set at 1024 characters, and this
width is honored by
INORMATION_SCHEMA.PARTITIONS.PARTITION_COMMENT. (Bug
#11748924, Bug #37728)
* Replication: When a complete global transaction spanned relay
logs such that only its GTID appeared in a given relay log
while the body of the transaction (including BEGIN and COMMIT
statements) appeared in the next relay log, the GTID was
interpreted incorrectly as belonging to an empty group. (Bug
#14136654)
* Replication: It was possible in some cases when using
semisynchronous replication for log rotation to take place
before an ongoing transaction was committed or rolled back.
(Bug #14123372)
* Replication: If the relay logs were removed after the server
was stopped, without stopping replication first, the server
could not be started correctly. (Bug #14029212, Bug #65152)
References: See also Bug #13971348.
* Replication: If errors were encountered while trying to
initialize the mysql.slave_master_info or
mysql.slave_relay_log_info tables, the server refused to
start. Now in such cases, the warning message Error while
checking replication metadata. This might also happen when
doing a live upgrade from a version that did not make use of
the replication metadata tables is issued to advise the user
that this has happened, but the server is permitted to
continue starting. (Bug #13893363)
* Replication: A CHANGE MASTER TO statement could alter the
effective value of relay_log_purge. In addition, the
relay_log_recovery system variable is now read-only, and can
be changed only by starting the server with
--relay-log-recovery. (Bug #13840948)
* Replication: When binlog_rows_query_log_events = 1 and a
statement is written to the binary log using the row-based
logging format, the server generates a an additional log event
containing the text of the original statement.
This was implemented with the assumption that such a statement
would consist of a single line, which meant that a statement
covering multiple lines was handled incorrectly.
(Bug #13799555)
* Replication: Replication locks and some of the protocols
controlling the use of these locks were not well implemented
or enforced. In particular, this fix improves lock handling
for statements such as CHANGE MASTER TO, SHOW SLAVE STATUS,
and FLUSH LOGS. (Bug #13779291)
* Replication: When logging transactions that affected both
transactional and nontransactional tables, the following
statements could sometimes be written into the binary log in
the wrong order or on the wrong side of a transaction
boundary:
+ SET,
+ CREATE FUNCTION,
+ SHOW BINLOG EVENTS,
+ REVOKE ALL PRIVILEGES.
(Bug #13627921)
* Replication: Setting binlog_checksum on the master to a value
that was unknown on the slave caused replication to fail. Now
in such cases, replication checksums are disabled on the slave
and replication stops with an appropriate error message. (Bug
#13553750, Bug #61096)
* Replication: To provide a crash-safe slave, it was previously
necessary to change the storage engine for the
slave_master_info, slave_relay_log_info, and slave_worker_info
tables from MyISAM to InnoDB manually, by issuing ALTER TABLE.
To simplify the setup of replication using these slave log
tables, they are now created using the InnoDB storage engine.
(Bug #13538891)
* Replication: When the slave had been set using CHANGE MASTER
TO with the MASTER_DELAY option equal to any permitted value
greater than zero, then stopped using STOP SLAVE, pointed at
the current relay log position (as shown by SHOW SLAVE
STATUS), and started again, START SLAVE failed with the error
Could not initialize master info structure. (Bug #12995174)
* Replication: The --relay-log-space-limit option was sometimes
ignored.
More specifically, when the SQL thread went to sleep, it
allowed the I/O thread to queue additional events in such a
way that the relay log space limit was bypassed, and the
number of events in the queue could grow well past the point
where the relay logs needed to be rotated. Now in such cases,
the SQL thread checks to see whether the I/O thread should
rotate and provide the SQL thread a chance to purge the logs
(thus freeing space).
Note that, when the SQL thread is in the middle of a
transaction, it cannot purge the logs; it can only ask for
more events until the transaction is complete. Once the
transaction is finished, the SQL thread can immediately
instruct the I/O thread to rotate. (Bug #12400313, Bug #64503)
References: See also Bug #13806492.
* Replication: An event whose length exceeded the size of the
master dump thread's max_allowed_packet caused replication to
fail. This could occur when updating many large rows and using
row-based replication.
As part of this fix, a new server option
--slave-max-allowed-packet is added, which permits
max_allowed_packet to be exceeded by the slave SQL and I/O
threads. Now the size of a packet transmitted from the master
to the slave is checked only against this value (available as
the value of the slave_max_allowed_packet server system
variable), and not against the value of max_allowed_packet.
(Bug #12400221, Bug #60926)
* Replication: Statements using AUTO_INCREMENT,
LAST_INSERT_ID(), RAND(), or user variables could be applied
in the wrong context on the slave when using statement-based
replication and replication filtering server options (see
Section 16.2.3, "How Servers Evaluate Replication Filtering
Rules"). (Bug #11761686, Bug #54201)
References: See also Bug #11754117, Bug #45670, Bug #11746146,
Bug #23894.
* Replication: An INSERT into a table that has a composite
primary key that includes an AUTO_INCREMENT column that is not
the first column of this composite key is not safe for
statement-based binary logging or replication. Such statements
are now marked as unsafe and fail with an error when using the
STATEMENT binary logging format. For more information, see
Section 16.1.2.3, "Determination of Safe and Unsafe Statements
in Binary Logging," as well as Section 16.4.1.1, "Replication
and AUTO_INCREMENT."
Note
Tables using the InnoDB storage engine are not affected by
this issue, since InnoDB does not allow the creation of a
composite key that includes an AUTO_INCREMENT column, where
this column is not the first column in the key.
(Bug #11754117, Bug #45670)
References: See also Bug #11761686, Bug #54201, Bug #11746146,
Bug #23894.
* Replication: After upgrading a replication slave to MySQL
5.6.2 or later, enabling the query cache eventually caused the
slave to fail. (Bug #64624, Bug #14005409)
* Replication: Further bug fixes:
Bug #13799489; Bug #13979418; Bug #13868465; Bug #13992602.
* Some errors in MySQL 5.6 had different numbers than in MySQL
5.5 (Bug #13833438)
* The range optimizer sometimes did not treat equivalent
expressions the same, depending on the order of the operands.
For example, it could treat a <= b and b >= a differently.
(Bug #13701206)
* A query executed with literal values in the WHERE clause could
return results different from the same query written to select
the same literal values from a separate table using a SELECT
statement in the WHERE clause. (Bug #13468414)
* yaSSL rejected valid SSL certificates that OpenSSL accepts.
(Bug #54348, Bug #11761822)
* Further bug fixes:
Bug #14116252; Bug #14136866; Bug #14167585; Bug #14069831;
Bug #14069810, Bug #14005353; Bug #14069132; Bug #14053325;
Bug #14039955; Bug #14028421; Bug #14001091;
Bug #13988413, Bug #14042545; Bug #13982125; Bug #13976233;
Bug #13974815; Bug #13966514; Bug #13966809; Bug #13958454;
Bug #13949068; Bug #13898343; Bug #13862186; Bug #13859866;
Bug #13848789; Bug #13837221; Bug #13822652; Bug #13820776;
Bug #13809293; Bug #13810048 (a regression of Bug #26106);
Bug #13803810; Bug #13805127; Bug #13793813; Bug #13799126;
Bug #13799348; Bug #13773979; Bug #13735712; Bug #13731380;
Bug #13731417; Bug #13685026; Bug #13485448; Bug #13485416;
Bug #13431226; Bug #13387020; Bug #13330886; Bug #13008220;
Bug #12845091; Bug #12713907; Bug #12667154;
Bug #12635232, Bug #14040277; Bug #12365385; Bug #12346211;
Bug #11766758; Bug #11766342;
Bug #11753779 (see also Bugs #38247, #43006, #45584, #45606);
Bug #64374, Bug #13737343 (see also Bug #11766752);
Bug #61713, Bug #12762885; Bug #61865, Bug #12766319;
Bug #63339, Bug #13417446; Bug #64211, Bug #13702397;
Bug #62136, Bug #13738989 (see also Bug #47485);
Bug #64310, Bug #13726075; Bug #63340, Bug #13417440;
Bug #62282, Bug #12951609; Bug #64345, Bug #13733221;
Bug #64617, Bug #13840553; Bug #65593, Bug #14197426;
Bug #60961, Bug #12427262; Bug #60858, Bug #12402882;
Bug #60114, Bug #11827404; Bug #60682, Bug #12636001;
Bug #59140, Bug #11766101; Bug #58785, Bug #11765785;
Bug #58731, Bug #11765737; Bug #56224, Bug #11763507;
Bug #55289, Bug #11762667; Bug #49539, Bug #11757486;
Bug #43353, Bug #11752226; Bug #43319, Bug #11752201;
Bug #43187, Bug #11752097; Bug #40344, Bug #11750045;
Bug #34364, Bug #11747876; Bug #34280, Bug #11747847;
Bug #31173, Bug #11747181, Bug #59107, Bug #11766072;
Bug #31149, Bug #11747177;
Bug #26040, Bug #11746399, Bug #54166, Bug #11761652;
Bug #25168, Bug #11746295; Bug #23790, Bug #11746142;
Bug #17392, Bug #11745578.