MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Bjorn Munch Date:September 25 2014 8:50pm
Subject:MySQL Community Server 5.7.5 has been released (part 1/3)
View as plain text  
Dear MySQL users, 

MySQL Server 5.7.5 (Milestone Release) is a new version of the world's 
most popular open source database. This is the fifth public milestone 
release of MySQL 5.7. 

[Due to length restrictions, this announcement is split into three parts.
This is part 1.] 

As with any other pre-production release, caution should be 
taken when installing on production level systems or systems with 
critical data. 

Note that 5.7.5 includes all features in MySQL 5.6. 

For information on installing MySQL 5.7.5 on new servers, please see the 
MySQL installation documentation at 

MySQL Server 5.7.5 is available in source and binary form for a number of 
platforms from the "Development Releases" selection of our download 
pages at 

Some Linux RPM package sets have changed since 5.7.4 in order to be
compatible with our repositories.

Since the previous milestone 5.7.4, packages for Debian 6, FreeBSD 9,
Red Hat Enterprise Linux/Oracle Linux 5 and OSX 10.6 and 10.7 have
been discontinued while packages for newer OS releases have been
addded: FreeBSD 10, OSX 10.8 and Red Hat Enterprise
Linux/Oracle Linux 7.

MySQL Server 5.7.5 is also available from our repository for Linux
platforms, go here for details: 

Windows packages are now available via the new Installer for Windows 
Installer or .ZIP (no-install) packages for more advanced needs. It 
should be noted that the previous MSI packaging is no longer available 
and the point and click configuration wizards and all MySQL products 
are now available in the unified Installer for Windows: 

5.7.5 also comes with a web installer as an alternative to the full 

The web installer doesn't come bundled with any actual products 
and instead relies on download-on-demand to fetch only the 
products you choose to install. This makes the initial download 
much smaller but increases install time as the individual products 
will need to be downloaded. 

We welcome and appreciate your feedback, bug reports, bug fixes, 
patches, etc.: 

The following section lists the changes in MySQL 5.7.5 since the 
previous milestone. 


On behalf of the MySQL Build Team at Oracle, 

- Bjorn Munch

Changes in MySQL 5.7.5 (2014-09-25, Milestone 15)


   This is a milestone release, for use at your own risk. Significant
   development changes take place in milestone releases and you may
   encounter compatibility issues, such as data format changes that
   require attention in addition to the usual procedure of running
   mysql_upgrade. For example, you may find it necessary to dump your
   data with mysqldump before the upgrade and reload it afterward.

   Due to the large number of changes in the milestone release, some
   may not have made it into this changelog at the time of the release.
   The complete changelog will be updated at this location:

   Compilation Notes

     * Important Change: 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)

     * Important Change: The atomic-operations API was simplified to
       use only the existing GCC/Clang built-in implementation or
       platform-provided implementations (for Windows, Solaris), and
       to remove the custom mutex-based fallback implementation. The
       retained implementations are those able to use CPU-native
       atomics. This simplifies the atomics APIs and related code and
       deals with bugs resulting from the fallback implementation.
       As part of this work, the (undocumented) WITH_ATOMIC_LOCKS and
       MY_ATOMIC_MODE_RWLOCKS CMake options were removed.
       On platforms where native atomics are supported, this change
       introduces no issues. For other platforms, here are potential
       MySQL compilation issues, and solutions:

          + 32-bit Linux variants that use GCC 4.1 will no longer
            work. This includes Red Hat 5, which is a supported
            platform. The solution to this problem is to use a new
            GCC or set the -march compiler option. For example, use
            GCC 4.4, which is available on Red Hat 5. For information
            about specifying compiler options, see Compiler Flags

          + There may be issues on unsupported platforms. For
            example, 64-bit PowerPC, 32-bit ARM, and 64-bit ARM will
            not compile with older compilers. The solution for these
            cases is to use GCC 4.7 or later.

     * CMake now checks for minimum versions of supported compilers:
       gcc 4.4 (Linux, Solaris); Sun Studio 12u2 (Solaris client
       library); Clang 3.3 (Mac OS X, FreeBSD). This check can be
       disabled with the -DFORCE_UNSUPPORTED_COMPILER=ON option. (Bug

     * Noisy compiler warnings on FreeBSD 10 were silenced. (Bug

     * CMake workarounds for older Mac OS X and XCode versions were
       removed. On Mac OS X, compilation always uses Clang, even for
       32-bit builds.
       Compilation on Mac OS X is now supported for Mac OS 10.8 and
       up, using XCode 5 and up. Compilation on older versions may
       work but is unsupported. (Bug #18510941)

     * Previously, the MYSQL_MAINTAINER_MODE CMake option was turned
       on by default for debug builds and off for release builds, and
       MYSQL_MAINTAINER_MODE caused -Werror to be enabled when
       building with GCC. This made it cumbersome to enable -Werror
       under certain conditions, such as when compiling with Clang.
       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. Enabling
       -Werror with Clang can be done simply by explicitly setting
       -DMYSQL_MAINTAINER_MODE=1 when running CMake. In addition,
       some compilation warnings reported by Clang 3.4 were fixed,
       making it possible to build the default debug build with
       -Werror. (Bug #18313717)

     * Build support was modified to produce the same warnings for
       Clang as for gcc. (Bug #17959689)

   DTrace Support

     * 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. For
       information about using DTrace on MySQL, see Tracing mysqld
       Using DTrace

   InnoDB Notes

     * 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. --debug='d,innodb_lock_no_retry' causes InnoDB to
       fail immediately during startup if locks cannot be acquired,
       rather than making 100 attempts before failing. This may be
       useful during testing or debugging to produce faster server
       exit when InnoDB cannot acquire its locks.
       One reason for disabling InnoDB is to enable starting a server
       instance using the same data directory as an existing
       instance. (MyISAM permits that, but InnoDB does not.) Because
       InnoDB can no longer be disabled, the workaround is to stop
       the existing instance before starting another so that there is
       only one active instance using a data directory at a time.

   Performance Schema Notes

     * 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 new limit is similar
       to the limit on the lengths of many other identifiers in MYSQL
       (see User-Defined Variables
       Queries that use very long user-defined variable names must be
       rewritten to user shorter names.
       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 performance_schema

   Optimizer Notes

     * The optimizer computes more accurate costs for semi-join
       materialization. (Bug #18558561)

     * Optimizer trace output for range access in the
       considered_access_path section has been improved: Instead of
       always printing "access_type": "ref" for index lookup types,
       "eq_ref", "ref", or "fulltext" is now printed. (Bug #18195373)

     * 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.
       There is also a new FLUSH variant, FLUSH OPTIMIZER_COSTS, that
       causes the server to reread the cost tables and apply any
       changed estimates to new sessions.
       For more information, see The Optimizer Cost Model
       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:

          + In many cases, better execution plans result for queries
            for which previously a less optimal join index or table
            join order was chosen.

          + The row estimates in EXPLAIN output are more accurate, as
            well as the filter values in some cases.

          + 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. This behavior is controlled
       by the condition_fanout_filter flag for the optimizer_switch
       system variable. This flag is on by default but can be
       disabled to suppress use of condition filtering.

   Performance Schema Notes

     * The Performance Schema stage event tables
       (events_stages_current, events_stages_history, and
       events_stages_history_long) contain two new columns that,
       taken together, provide a stage progress indicator for each

          + WORK_COMPLETED: The number of work units completed for
            the stage

          + WORK_ESTIMATED: The number of work units expected for the
       Each column is NULL if no progress information is provided for
       an instrument. Interpretation of the information, if it is
       available, is entirely up to the instrument implementation.
       Initially, to demonstrate the concept, the stage/sql/copy to
       tmp table instrument provides progress information if it is
       enabled. In this case, the unit for interpretation of the
       columns is number of rows copied.
       For more information, see Performance Schema Stage Event
       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 performance_schema

     * Previously, for the wait event tables (such as
       events_waits_current), the NUMBER_OF_BYTES column was NULL for
       table I/O waits; that is, for events for the
       wait/io/table/sql/handler instrument. For table I/O waits,
       this value now indicates the number of rows processed.
       In addition, for batch I/O operations (such as row fetches for
       table or index scans), the Performance Schema now can report a
       single event for N rows, rather than reporting a single-row
       event N times. This change significantly reduces Performance
       Schema overhead for table batch I/O by reducing the number of
       reporting calls. The tradeoff is lesser accuracy for event
       timing. Rather than time for an individual row operation as in
       per-row reporting, timing for batch I/O includes time spent
       for operations such as join buffering, aggregation, and
       returning rows to the client.
       For more information on the conditions under which batch I/O
       reporting occurs, see the description of the NUMBER_OF_BYTES
       column in The events_waits_current Table

   Security Notes

     * 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.
            Accounts that use this plugin are disabled at startup and
            the server writes an "unknown plugin" message to the
            error log. For instructions on upgrading accounts that
            use this plugin, see Migrating Away from Pre-4.1 Password
            Hashing and the mysql_old_password Plugin

          + 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

          + The secure_auth system variable permits only a value of
            1; a value of 0 is no longer permitted.

          + For the old_passwords system variable, a value of 1
            (produce pre-4.1 hashes) is no longer permitted.

          + The OLD_PASSWORD() function is removed.

   SQL Mode Notes

     * Incompatible Change: These SQL mode changes were made:

          + Strict SQL mode for transactional storage engines
            (STRICT_TRANS_TABLES) is now enabled by default.

          + Implementation for the ONLY_FULL_GROUP_BY SQL mode has
            been made more sophisticated, to no longer reject
            deterministic queries that previously were rejected. In
            consequence, this mode is now enabled by default, to
            prohibit only nondeterministic queries for which
            expressions are not guaranteed to be uniquely determined
            within a group.
            Checking for ONLY_FULL_GROUP_BY has also become more
            sophisticated and no longer rejects queries that are

          + The changes to the default SQL mode result in a default
            sql_mode system variable value of

          + The ONLY_FULL_GROUP_BY mode is now included in the the
            ANSI SQL mode.

          + A new function, ANY_VALUE(), is available. Its return
            value and type are the same as the return value and type
            of its argument, but the function result is not checked
            for the ONLY_FULL_GROUP_BY SQL mode. The function does
            not make a nondeterministic query deterministic, but it
            can be used to force MySQL to accept queries that it
            thinks should be rejected with ONLY_FULL_GROUP_BY
       For more information about SQL modes, see Server SQL Modes

   Security Notes

     * MySQL now includes a server-side authentication plugin named
       mysql_no_login for setting up accounts that accept no client
       connections. This plugin enables DBAs to implement the
       following use cases:

          + Stored program and view objects that perform sensitive or
            adminstrative operations must run with elevated
            privileges. Less-privileged users must be able to execute
            these objects but not be able to directly log in as the
            account that has the privileges. To implement this,
            create a no-login account using mysql_no_login, grant it
            the required privileges, define objects with a DEFINER of
            that account, and include SQL SECURITY DEFINER in the

          + Access to a proxy account must always be by the usual
            proxy mechanism, never by users logging in directly to
            the proxy account. To implement this, assign
            mysql_no_login as the authentication plugin when you
            create the proxy account.
       For more information, see The No-Login Authentication Plugin

   Spatial Data Support

     * 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.
       For more information, see Optimizing Spatial Analysis
       lysis.html). and Predicate Locking for Spatial Indexes
       .html). (Bug #18674219)

     * GeometryCollection() returned NULL if the argument contained
       nonsupported geometries. Now GeometryCollection() returns all
       the proper geometries contained in the argument even if a
       nonsupported geometry is present. (Bug #17168643)

     * The Open Geospatial Consortium guidelines document the use of
       open polygons (polygons where the start point is not equal to
       the end point) but the MySQL GIS implementation did not
       support them. Now MySQL supports open polygons: An open
       polygon is converted to a closed one by appending the starting
       point to the point sequence. Before:
mysql> SELECT AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 2
| AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))')) |
| NULL                                                          |
mysql> SELECT AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 2
| AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))')) |
| POLYGON((10 10,20 10,20 20,10 20,10 10))                      |
       (Bug #17168699)

     * MySQL now includes functions that enable manipulation of
       geohash values, which provides applications the capabilities
       of importing and exporting geohash data, and of indexing and
       searching geohash values:

          + ST_GeoHash() returns a geohash string given a return
            value length and either longitude and latitude values or
            a POINT value.

          + ST_LongFromGeoHash() and ST_LatFromGeoHash() return the
            longitude or latitude value, respectively, given a
            geohash string argument.

          + ST_PointFromGeoHash() produces a POINT value from a
            geohash string argument.

     * MySQL now includes functions for converting between GeoJSON
       documents and spatial values: ST_AsGeoJSON() and
       ST_GeomFromGeoJSON(). For more information, see Spatial
       GeoJSON Functions

     * Several previously unimplemented spatial functions are now
       available: The ST_ConvexHull function and the set operation
       functions ST_Difference(), ST_SymDifference(),
       ST_Intersection(), and ST_Union().

   Functionality Added or Changed

     * 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.
       In consequence of this change, mysql_upgrade now supports the
       --bind-address option enabling the network interface for
       connecting to the server to be chosen. It also supports
       --net-buffer-length and --max-allowed-packet options enabling
       the initial and maximum communication packet size to be
       Also in consequence of this change, mysql_upgrade no longer
       supports the --tmpdir option. This option specified the
       location of temporary files used to supply input to mysql, but
       it no longer has any purpose because mysql_upgrade no longer
       invokes mysql. Any upgrade scripts that invoke mysql_upgrade
       and use --tmpdir must be modified to remove that option.

     * 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)
       l). 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:

          + Previously, GET_LOCK() permitted acquisition of only one
            named lock at a time, and a second GET_LOCK() call
            released any existing lock. Now GET_LOCK() permits
            acquisition of more than one simultaneous named lock and
            does not release existing locks.
            Applications that rely on the behavior of GET_LOCK()
            releasing any previous lock must be modified for the new

          + The capability of acquiring multiple locks introduces the
            possibility of deadlock among clients. The MDL subsystem
            detects deadlock and returns an ER_USER_LOCK_DEADLOCK
            error when this occurs.

          + The MDL subsystem imposes a limit of 64 characters on
            lock names, so this limit now also applies to named
            locks. Previously, no length limit was enforced.

          + Locks acquired with GET_LOCK() now appear in the
            Performance Schema metadata_locks table. The OBJECT_TYPE
            column says USER LEVEL LOCK and the OBJECT_NAME column
            indicates the lock name.

          + A new function, RELEASE_ALL_LOCKS() permits release of
            all acquired named locks at once.
       For more information, see Miscellaneous Functions

     * 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.
       The executable binary version is located in the bin
       installation directory, whereas the Perl version is located in
       the scripts installation directory. For upgrades from an older
       version of MySQL, you may find a version in both directories.
       To avoid confusion, remove the version in the scripts

     * 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: 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
       See Resizing the InnoDB Buffer Pool Online
       ine-resize.html) for more information.

     * InnoDB: The FIL_PAGE_FLUSH_LSN field, written to the first
       page of each InnoDB system tablespace file and to InnoDB undo
       tablespace files, is now only written to the first file of the
       InnoDB system tablespace (page number 0:0).

     * 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. A new global configuration option,
       innodb_fill_factor, defines the percentage of space on each
       page that is filled with data during a sorted index build,
       with the remaining space reserved for future index growth.

     * InnoDB: InnoDB memory allocations now are instrumented for the
       Performance Schema
       l) 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

     * 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

     * Replication: When replicating from a master running a version
       earlier than MySQL 5.6.0 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)

     * 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.
       Because the mysql.gtid_executed table can become filled with
       many rows with single-transaction GTIDs having the same
       originating server and sequential transaction IDs, the server
       compresses this table periodically whenever GTIDs are enabled.
       You can control the frequency with which the table is
       compressed by setting the executed_gtids_compression_period
       system variable. This variable's default value is 1000, which
       means that compression of the table is applied following each
       1000 transactions. You can set the
       executed_gtids_compression_period to 0 to disable the
       compression altogether, but you should be aware that doing
       this may cause the space required by this table to increase
       significantly. (See mysql.gtid_executed Table Compression
       Compression of the mysql.gtid_executed table is performed by a
       dedicated thread. You can obtain information about the state
       of this thread in the Performance Schema threads table. (Bug

     * Replication: The new system variable
       binlogging_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
       binlogging_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, Bug #11758766)

     * 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: The new SQL function WAIT_FOR_EXECUTED_GTID_SET
       makes the current syncing option for the slave with master
       independent of the slave threads and improves the return

     * 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 rwlock used for the SAFE_HASH implementation is now
       instrumented for the Performance Schema. The instrument name
       is wait/synch/rwlock/mysys/SAFE_HASH::lock. (Bug #18991366)

     * CMake support was updated to handle CMake version 3. (Bug

     * 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. (Bug #19020385)

     * The (undocumented) script has been removed
       from MySQL distributions. (Bug #18694238)

     * RHEL 4 is not supported for 5.7, so the
       support-files/RHEL4-SElinux file was removed. (Bug #18651087)

     * Unused private fields reported by Clang's
       -Wunused-private-field compiler warning option were removed.
       (Bug #18489724)

     * thr_alarm.h and thr_alarm.c were removed because they contain
       dead code almost exclusively. The remaining live code was
       moved to my_alarm.h and my_alarm.c were also
       removed, and the code from them that is actually used was
       moved to my_lock.c. (Bug #18411456)

     * The deprecated timed_mutexes system variable has been removed.
       (Bug #18277305)

     * The obsolete and unmaintained charset2html utility has been
       removed from MySQL distributions. (Bug #71897, Bug #18352347)

     * A new status variable, Max_used_connections_time, indicates
       the time at which Max_used_connections reached its current
       value. Thanks to Jordi Prats for the patch. (Bug #59738, Bug

     * mysqld help text for --general_log was clarified. Thanks to
       Andrew Gaul for the patch. (Bug #71463, Bug #18127243)

     * The fill_help_tables.sql file that is used to load server-side
       help table content now contains the following statement to
       suppress binary logging and prevent table contents from
       replicating to slaves:
SET sql_log_bin=0;
       Because help table content is specific to the a particular
       server version, this prevents loading incorrect content into
       the slaves, which do not necessarily run the same version of
       MySQL as the master. For more information, see Replication of
       Server-Side Help Tables
       erver-side-help.html). (Bug #69564, Bug #17015822)

     * The empty string provided for numeric or enumeration options
       (for example, --port="") produced inconsistent or confusing
       behavior. Such empty option values now are rejected with an
       error. (Bug #68055, Bug #16102788)

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

          + Explicitly or implicitly started transactions that update
            any table (transactional or nontransactional) will block
            and be blocked by LOCK TABLES ... READ for that table.
            This is similar to how LOCK TABLES ... WRITE works.

          + Tables that are implicitly locked by LOCK TABLES now will
            be locked using metadata locks rather than THR_LOCK locks
            (for InnoDB tables), and locked using metadata locks in
            addition to THR_LOCK locks (for all other storage
            engines). Implicit locks occur for underlying tables of a
            locked view, tables used by triggers for a locked table,
            or tables used by stored programs called from such views
            and triggers.
            Multiple-table updates now will block and be blocked by
            concurrent LOCK TABLES ... READ statements on any table
            in the update, even if the table is used only for

          + HANDLER ... READ for any storage engine will block and be
            blocked by a concurrent LOCK TABLES ... WRITE, but now
            using a metadata lock rather than a THR_LOCK lock.
       The preceding changes are visible several ways. For example,
       when a DML statement such as INSERT INTO t1 in one session is
       blocked by LOCK TABLES t1 READ in another session:

          + In the Performance Schema, THR_LOCK acquisitions and
            waits will be registered in the metadata_locks table and
            for wait/lock/metadata/sql/mdl events rather than
            registered in the table_handles table and for
            wait/lock/table/sql/handler events.

          + In the process list (SHOW PROCESSLIST or
            INFORMATION_SCHEMA.PROCESSLIST), the state value will be
            Waiting for table metadata lock rather than Waiting for
            table level lock.

          + The Table_locks_immediate and Table_locks_waited status
            variables will no longer be incremented.
       Issues that went away as a result of these locking changes:

          + For debug builds, concurrent execution of LOCK TABLES ...
            READ and a DML statement affecting the same InnoDB table
            might lead to Found lock of type 6 that is write and read
            locked warnings in the error log.
       (Bug #42147, Bug #11751331)

     * CMake support was updated to handle the new directory layout
       for Sun C++ 5.13. (Bug #73034, Bug #19010286)

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

     * Previously, on Unix and Unix-like systems, MySQL support for
       sending the server error log to syslog was implemented by
       having mysqld_safe capture server error output and pass it to
       syslog. The server now includes native syslog support, which
       has been extended to include Windows. mysqld_safe still has
       syslog capability, but this is now deprecated and native
       server support should be used instead. For more information
       about sending server error output to syslog, see The Error Log
       ( (Bug
       #55370, Bug #11762739)

     * The deprecated storage_engine system variable has been
       removed. Use default_storage_engine instead.

     * The mysql client now indicates whether USE statements produced
       warnings. (Bug #29965, Bug #11746951)

     * The deprecated mysqlbug, mysql_waitpid, and mysql_zap
       utilities have been removed from MySQL distributions.

     * The deprecated mysqlhotcopy utility has been removed from
       MySQL distributions. Alternatives include mysqldump and MySQL
       Enterprise Backup.

     * The Boost library now is required to build MySQL. Two new
       CMake options enable control over the library source location,
       and whether to download it automatically:

          + -DWITH_BOOST=path_name specifies the Boost library
            directory location. It is also possible to specify the
            Boost location by setting the BOOST_ROOT or WITH_BOOST
            environment variable.

          + -DDOWNLOAD_BOOST=bool specifies whether to download the
            Boost source if it is not present in the specified
            location. The default is OFF.
       For example, if you normally build MySQL placing the object
       output in the bld subdirectory of your MySQL source tree, you
       can build with Boost like this:
mkdir bld
cd bld
       This causes Boost to be downloaded into the my_boost directory
       under your home directory. If the required Boost version is
       already there, no download is done. If the required Boost
       version changes, the newer version is downloaded.
       If Boost is already installed locally and your compiler finds
       the Boost header files on its own, it may not be necessary to
       specify the preceding CMake options. However, if the version
       of Boost required by MySQL changes and the locally installed
       version has not been upgraded, you may have build problems.
       Using the CMake options should give you a successful build.

     * The custom rwlock implementation for Windows was replaced with
       standard Windows API calls. As a result of this change,
       Windows binaries require Windows 7 / Windows Server 2008 R2 or
       newer. In particular, Windows binaries no longer work on
       Windows Vista or Windows Server 2008 (plain, not R2).

     * It is now possible to specify the storage engine the server
       uses for on-disk internal temporary tables (see How MySQL Uses
       Internal Temporary Tables
       les.html)), by setting the new
       internal_tmp_disk_storage_engine system variable. Permitted
       values are MYISAM (the default) and INNODB.

     * mysqlslap now has a --sql-mode option that enables the SQL
       mode to be set for the client session.

     * ALTER TABLE ... EXCHANGE PARTITION syntax now includes an
       optional {WITH|WITHOUT} VALIDATION clause. When WITHOUT
       does not perform row-by-row validation when exchanging a
       populated table with the partition, permitting database
       administrators to assume responsibility for ensuring that rows
       are within the boundaries of the partition definition. WITH
       VALIDATION is the default behaviour and need not be specified
       explicitly. For more information, see Exchanging Partitions
       and Subpartitions with Tables

     * MySQL Server now supports an "offline mode" with these

          + Connected client users who do not have the SUPER
            privilege are disconnected on the next request, with an
            appropriate error. Disconnection includes terminating
            running statements and releasing locks. Such clients also
            cannot initiate new connections, and receive an
            appropriate error.

          + Connected client users who have the SUPER privilege are
            not disconnected, and can initiate new connections to
            manage the server.

          + Replication slave threads are permitted to keep applying
            data to the server.
       Only users who have the SUPER privilege can control offline
       mode. To put a server in offline mode, change the value of the
       new offline_mode system variable from OFF to ON. To resume
       normal operations, change offline_mode from ON to OFF. In
       offline mode, clients that are refused access receive an

     * The server-side help tables and time zone tables in the mysql
       system database now are InnoDB (transactional) tables.
       Previously, these were MyISAM (nontransactional) tables. The
       affected tables are:
       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.
       START TRANSACTION and COMMIT statements have been added to the
       output from mysql_tzinfo_to_sql used to populate the time zone
       tables, to ensure that reload operations are permanent.

     * In the MySQL client/server protocol, EOF and OK packets serve
       the same purpose, to make the end of a query execution result.
       Due to recent changes in the OK packet (such as session state
       tracking), and to avoid repeating the changes in the EOF
       packet, the EOF packet is now deprecated.
MySQL Community Server 5.7.5 has been released (part 1/3)Bjorn Munch25 Sep