MySQL 5.6.6 がリリースされました


MySQL 5.6.6(マイルストーンリリース)は世界でもっともポピュラーなオープンソースデータベースの新バージョンです。


5.6.6はMySQL 5.5の全機能を含んでいます。MySQL 5.6の新機能の概要については、以下の"MySQL 5.6の何が新しくなったのか"を参照してください。


新しいサーバにMySQL 5.6.6をインストールする情報として、以下のMySQLのインストールドキュメントを参照してください。






MySQL Server 5.6は、ダウンロード・ページの「開発版リリース」からソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。



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はサポート対象からはずされました)

オペレーティングシステムのより新しいバージョンを使用するのであれば、バイナリ互換性アプローチ(より古いバージョンのためにビルドされたアプリケーションのサポート)によってMySQL 5.6の使用が保障されるはずです。




もしプロダクションレベルのシステムでMySQLを稼動させるならば、MySQL製品、バックアップ、モニタリング、モデリング、開発、管理ツールを含むMySQL Enterprise Editionに注目してください。MySQLのパフォーマンス、セキュリティ、稼働時間を高いレベルで達成します。

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

       + 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

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
    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:
    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
         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, "Command-Line Options that Affect Option-File

       + 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, "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
            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, "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

       + 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
         For more information, see Section, "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,
         "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
    the CREATE TABLE and ALTER TABLE statements. See Section, "Persistent Optimizer Statistics for InnoDB
    Tables" for usage details.

  * Incompatible Change: The --safe-mode server option has been

  * 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, "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

  * 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

  * 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

       + 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
         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

      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, "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, "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, "Improvements to Buffer Pool

  * 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, "Using PROCEDURE ANALYSE.") One consequence
    of removing the procedure interface is that EXPLAIN SELECT ...
    PROCEDURE ANALYSE() now works where previously it produced an

  * 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
    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
    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, 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, 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

  * 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:
    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

       + "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

       + 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

  * 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

  * 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:
    (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, "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

  * 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

  * 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
    #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

  * 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

       + SET,



    (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
    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, "Determination of Safe and Unsafe Statements
    in Binary Logging," as well as Section, "Replication
    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.