MySQL Community Server 5.7.6 has been released (part 1/3)
- Date: Tue, 10 Mar 2015 18:35:59 +0100
- From: Bjorn Munch <bjorn.munch@xxxxxxxxxx>
- Subject: MySQL Community Server 5.7.6 has been released (part 1/3)
Dear MySQL users,
MySQL Server 5.7.6-m16 (Milestone Release) is a new version of the world's
most popular open source database. This is the sixth public milestone
release of MySQL 5.7.
[Due to size limitations on email/forum and the sheer number of changes
since 5.7.5, this announcement had to be 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.6-m16 includes all features in MySQL 5.6.
For information on installing MySQL 5.7.6-m16 on new servers, please see
the MySQL installation documentation at
MySQL Server 5.7.6-m16 is available in source and binary form for a number of
platforms from the "Development Releases" selection of our download
MySQL Server 5.7.6-m16 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.6-m16 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,
The following section lists the changes in MySQL 5.7.6-m16 since the
- Bjorn Munch
MySQL Release Engineering
Changes in MySQL 5.7.6 (2015-03-09, Milestone 16)
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.
Account Management Notes
* Incompatible Change: The CREATE USER and ALTER USER
statements have gained user-management capabilities.
Together, they now can be used to fully establish or
modify authentication, SSL, and resource-limit
properties, as well as manage password expiration and
account locking and unlocking. For example, ALTER USER
can assign passwords, and it can modify the
authentication plugin for users with no need for direct
manipulation of the mysql.user table. For details, see
CREATE USER Syntax
, and ALTER USER Syntax
Account locking control is a new feature that permits
administrators to completely disable an account from
being used to connect to the server. Account locking
state is recorded in the account_locked column of the
mysql.user table. See User Account Locking
A new statement, SHOW CREATE USER, shows the CREATE USER
statement that creates the named user. The accompanying
Com_show_create_user status variable indicates how many
times the statement has been executed.
A new system variable,
log_backward_compatible_user_definitions, if enabled,
causes the server to log CREATE USER, ALTER USER, and
GRANT statements in backward-compatible (pre-5.7.6)
fashion. Enabling this variable promotes compatibility
for cross-version replication.
The authentication_string column in the mysql.user table
now stores credential information for all accounts. The
Password column, previously used to store password hash
values for accounts authenticated with the
mysql_native_password and mysql_old_password plugins, is
If you upgrade to this release of MySQL from an earlier
version, you must run mysql_upgrade (and restart the
server) to incorporate the changes to the mysql database.
mysql_upgrade moves Password column values to the
authentication_string column and removes the Password
column. For nonupgraded installations that have no
account_locked column, the server treats all accounts as
unlocked, and attempts to lock or unlock and account
produce an error.
The preceding changes make the following features
obsolete. They are now deprecated and support for them
will be removed in a future MySQL release:
+ Using GRANT to create users. Instead, use CREATE
USER. Following this practice makes the
NO_AUTO_CREATE_USER SQL mode immaterial for GRANT
statements, so it too is deprecated.
+ Using GRANT to modify account properties other than
privilege assignments. This includes authentication,
SSL, and resource-limit properties. Instead,
establish such properties at account-creation time
with CREATE USER or modify them afterward with ALTER
+ IDENTIFIED BY PASSWORD 'hash_string' syntax for
CREATE USER and GRANT. Instead, use IDENTIFIED BY
auth_plugin AS 'hash_string' for CREATE USER and
ALTER USER, where the 'hash_string' value is in a
format compatible with the named plugin.
+ The SET PASSWORD statement and the PASSWORD()
function. Instead, use ALTER USER to change account
passwords, and avoid using PASSWORD() in any
The changes in this release result in a semantic
incompatibility for one SET PASSWORD syntax:
SET PASSWORD ... = 'literal string';
Previously, SET PASSWORD interpreted the string as a
password hash value to be stored directly. Now, SET
PASSWORD interprets the string as a plaintext string
and hashes it appropriately for the account
authentication plugin before storing it.
Any application that uses PASSWORD() to create hash
values (a practice that has been discouraged for
some time) should be modified to use a different
hash-generation method. For suggestions, see the
description of PASSWORD() in Encryption and
+ The old_passwords system variable. Account
authentication plugins can no longer be left
unspecified in the mysql.user table, so any
statement that assigns a password from a plaintext
string can unambiguously determine the hashing
method to use on the string before storing it in the
mysql.user table. This renders old_passwords
It is a known bug in this release that the following SET
PASSWORD syntax produces an error:
SET PASSWORD ... = PASSWORD('auth_string');
That syntax was to be deprecated, not removed. It will be
restored in the next release, but generate a warning due
to its deprecated status. These alternatives are
available, the first of which is the preferred form:
ALTER USER ... IDENTIFIED BY 'auth_string';
SET PASSWORD ... = 'auth_string';
The change in mysql.user table structure has
compatibility implications for upgrading and downgrading:
+ You cannot use mysqldump to dump the user table from
a version of MySQL older than 5.7.6 and reload the
dump file into MySQL 5.7.6 or later. Instead,
perform a binary (in-place) upgrade to MySQL 5.7.6
or later and run mysql_upgrade to migrate the
Password column contents to the
+ Because the Password column is gone in 5.7.6 and up,
downgrading to a version older than 5.7.6 requires a
special procedure. See Downgrading to MySQL 5.6
* MySQL now supports the specification of generated columns
in CREATE TABLE and ALTER TABLE statements. Values of a
generated column are computed from an expression
specified at column creation time. Generated columns can
be virtual (computed "on the fly" when rows are read) or
stored (computed when rows are inserted or updated). The
INFORMATION_SCHEMA.COLUMNS table shows information about
Uses for generated columns include simplifing queries
when applications select from a table using a complex
expression, simulating functional indexes, or
substituting for views. For more information, see
* Previously, for a new MySQL installation on Unix and
Unix-like systems, initialization of the data directory
(including the tables in the mysql system database) was
done using mysql_install_db. On Windows, MySQL
distributions included a data directory with prebuilt
tables in the mysql database.
mysql_install_db functionality now has been integrated
into the MySQL server, mysqld. To use this capability to
initialize a MySQL installation, if you previously
invoked mysql_install_db manually, invoke mysqld with the
--initialize or --initialize-insecure option, depending
on whether you want the server to generate a random
password for the initial 'root'@'localhost' account.
As a result of this change, mysql_install_db is
deprecated, as is the special --bootstrap option that
mysql_install_db passes to mysqld. These will be removed
in a future MySQL release. Also, the $HOME/.mysql_secret
file written by mysql_install_db is no longer needed. If
it is present on your system, you can remove it.
Initializing a MySQL installation using mysqld works on
all platforms, including Windows. In particular, it is
possible to initialize a Windows installation without the
set of prebuilt tables for the mysql database. (However,
it is unnecessary to do so for this release because
Windows distributions still include the pre-built
For more information, see Initializing the Data Directory
* The optimizer now minimizes differences in handling of
views and subqueries in the FROM clause. One effect of
this is that subqueries in the FROM clause, previously
always materialized to an internal temporary table, now
may be merged into the outer query. This can improve
performance. Avoiding materialization also can enable the
optimizer to push down conditions to the subquery and
produce a more efficient execution plan. For an example,
see Optimizing Subqueries with Subquery Materialization
References: See also Bug #20073366, Bug #59203, Bug
* Packaging scripts such as those included in RPM or Debian
packages have been modified per the principle that files
installed from MySQL distributions should have the most
restrictive permissions possible. In the following
description, assume that the account used to administer
MySQL has owner (user) = mysql, group = mysql.
+ Installers that create the mysql account do so with
a shell of /bin/false to prevent direct login to the
+ The data directory and its contents are owned by and
accessible only to owner/group mysql/mysql, with
permissions of 750 for directories, 755 for
executable files, 640 for other files.
+ Others files (including executables and libraries)
have owner/group of root/root, with these
o Executables: 755
o Man pages, character set files, header files,
test suite files: 644
o Library files: Conventions appropriate for the
Packaging scripts that perform the preceding actions for
installation also perform them for upgrades, with the
exceptions that if the mysql account exists, it is left
unchanged, and if the data directory exists, its
permissions and ownership are left unchanged.
Performance Schema Notes
* The Performance Schema now incorporates these changes:
+ Previously, the Performance Schema enabled
instrumentation for new foreground threads if there
was a row in the setup_actors table that matched the
thread user and host. Now, the setup_actors table
has an ENABLED column that indicates whether or not
to enable instrumentation for matching foreground
threads. This permits instrumentation for matching
threads to be disabled explicitly. For more
information, see Pre-Filtering by Thread
+ Two previously hardcoded limits on SQL statement
handling are now configurable:
o The maximum number of bytes from SQL statements
to display in the SQL_TEXT column of statement
event tables, such as
o The number of bytes used for computing
statement digests. Digests appear in the
DIGEST_TEXT and DIGEST columns of statement
Previously, both values were fixed at 1024. It is
now possible to change them at server startup using
the performance_schema_max_sql_text_length and
max_digest_length system variables. (The name
max_digest_length does not begin with
performance_schema_ because statement digesting is
now done at the SQL level even if the Performance
Schema is disabled and is available to other aspects
of server operation that could benefit from it. For
example, query rewrite plugins now make use of
statement digests, even if the Performance Schema is
The defaults remain at 1024, but the values can be
reduced to use less memory or increased to permit
longer statements to be distinguished for display
and digesting purposes. Each variable has a range
from 0 to 1024 x 1024.
Any bytes in excess of
performance_schema_max_sql_text_length are discarded
and do not appear in the SQL_TEXT column. Statements
differing only after that many initial bytes are
indistinguishable in this column.
Any bytes in excess of max_digest_length during
digest computation do not factor into digest values.
Statements differing only after that many bytes of
parsed statement tokens produce the same digest and
are aggregated for digest statistics.
For applications that generate very long statements
that differ only at the end, the ability to change
max_digest_length variables enables computation of
digests that distinguish statements that previously
were aggregated to the same digest. Conversely,
administrators can devote less server memory to
digest storage by reducing the values of this
variable. Administrators should keep in mind that
larger values result in correspondingly increased
memory requirements, particularly for workloads that
involve large numbers of simultaneous sessions.
(max_digest_length bytes are allocated per session.)
For more information, see Performance Schema
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
* The secure_file_priv system variable is used to limit the
effect of data import and export operations. The
following changes have been made to how the server
handles this variable:
+ The server checks the value of secure_file_priv at
startup and writes a warning to the error log if the
value is insecure. The setting is considered
insecure if secure_file_priv has an empty value, or
the value is the data directory or a subdirectory of
it, or a directory that is accessible by all users.
If secure_file_priv is set to a nonexistent path,
the server writes an error message to the error log
+ secure_file_priv can be set to NULL to disable all
import and export operations.
+ Previously, the secure_file_priv system variable was
empty by default. Now the default value is platform
specific and depends on the value of the
INSTALL_LAYOUT CMake option, as shown in the
INSTALL_LAYOUT Value Default secure_file_priv Value
STANDALONE, WIN empty
DEB, RPM, SLES, SVR4 /var/lib/mysql-files
Otherwise mysql-files under the CMAKE_INSTALL_PREFIX value
+ To specify the default secure_file_priv value
explicitly if you are building from source, use the
new INSTALL_SECURE_FILE_PRIVPATH CMake option.
References: See also Bug #18140348.
* MySQL Server from Community Edition distributions now
tries to deploy with SSL support enabled automatically if
no SSL options are specified explicitly and it finds any
of the ca.pem, server-cert.pem, and server-key.pem files
in the data directory. In this case, clients can use a
secure connection merely by specifying --ssl on the
To make it easier to produce the files required to
support secure connections (for both SSL and RSA), MySQL
distributions now include the mysql_ssl_rsa_setup
utility. This utiliy uses the openssl command, so its use
is contingent on having OpenSSL installed on your
machine. When invoked, mysql_ssl_rsa_setup checks the
data directory for SSL/RSA files and uses openssl to
create them if they are missing. For more information,
see mysql_ssl_rsa_setup --- Create SSL/RSA Files
If the server automatically uses SSL files at startup, it
writes a message to the error log. If the server finds
that the CA certificate is self-signed, it writes a
warning to the error log. (The certificate will be
self-signed if created by mysql_ssl_rsa_setup.)
Spatial Data Support
* Spatial functions now allocate memory in larger chunks to
reduce number of allocation calls and reduce overhead.
* A new set of spatial convenience functions is available:
+ ST_Distance_Sphere(): Returns the mimimum distance
between two geometries.
+ ST_IsValid(): Checks whether a geometry is valid.
+ ST_MakeEnvelope(): Returns the rectangle that forms
the envelope around two points.
+ ST_Simplify(): Returns a simplified geometry.
+ ST_Validate(): Returns a validated geometry, or NULL
if it is invalid.
For details, see Spatial Convenience Functions
* GIS code now uses Boost.Geometry.Rtree to improve
handling of geometry collection arguments in binary GIS
functions. The minimum bounding rectangles (MBRs) of
geometry collection components are used to set up an
rtree index, which is used to search for possible
matching components using each MBR of the components of
the other geometry collection. The results from the rtree
index search are provided to precise computation
algorithms to avoid unnecessary (and much more expensive)
precise computation. As a result, the time complexity of
handling geometry collection arguments in GIS algorithms
is reduced from O(N^2) to O(NlogN).
* Functions for checking spatial relations now use
functionality available in Boost.Geometry 1.56 and up:
ST_Contains(), ST_Crosses(), ST_Disjoint(), ST_Equals(),
ST_Intersects(), ST_Overlaps(), ST_Touches(),
ST_Within(). Specifically, these functions:
+ Now are able to test the relationship between all
pairs of argument types handled by Boost.Geometry.
+ Raise an exception for invalid argument types when
the previous implementation may not have.
This work also corrected issues that ST_Overlaps()
returned 1 and ST_Intersects() returned 0 for two
polygons that shared only a boundary, and that
ST_Intersects() sometimes incorrectly calculated the
result for intersections of LineString and Polygon.
References: See also Bug #68091, Bug #16174580, Bug
#71076, Bug #17894858.
* The spatial function namespace is being made more
consistent, with the ultimate goal that each spatial
function name begins with ST_ if it performs an exact
operation, or with MBR if it performs an operation based
on minimum bounding rectangles.
Currently, some functions have two implementations and up
to three related names: A name with an ST_ prefix, and a
name with an MBR prefix, and a name with no prefix:
+ The name with an ST_ prefix performs an exact
+ The name with an MBR prefix performs an operation
based on minimum bounding rectangles.
+ The name with neither prefix sometimes is an alias
for the ST_ name (as with Area() and ST_Area()),
sometimes an alias for the MBR name (as with
Contains() and MBRContains()),
This release implements the following changes in spatial
+ A function with an ST_ prefix is added for each
non-MBR function that has no ST_ name.
+ Each function that does not begin with ST_ or MBR is
+ The exceptions are the geometry object construction
functions, which remain unchanged: Point(),
LineString(), Polygon(), MultiPoint(),
MultiLineString(), MultiPolygon(), and
+ These functions are deprecated in favor of the MBR
names: Contains(), Disjoint(), Equals(),
Intersects(), Overlaps(), Within().
+ These functions are deprecated in favor of the ST_
names: Area(), AsBinary(), AsText(), AsWKB(),
AsWKT(), Buffer(), Centroid(), ConvexHull(),
Crosses(), Dimension(), Distance(), EndPoint(),
Envelope(), ExteriorRing(), GeomCollFromText(),
GeomCollFromWKB(), GeomFromText(), GeomFromWKB(),
GeometryFromWKB(), GeometryN(), GeometryType(),
InteriorRingN(), IsClosed(), IsEmpty(), IsSimple(),
LineFromText(), LineFromWKB(), LineStringFromText(),
MLineFromWKB(), MPointFromText(), MPointFromWKB(),
NumGeometries(), NumInteriorRings(), NumPoints(),
PointFromText(), PointFromWKB(), PointN(),
PolyFromText(), PolyFromWKB(), PolygonFromText(),
PolygonFromWKB(), SRID(), StartPoint(), Touches(),
+ These ST_ names are added and are preferred over the
corresponding non-ST_ names, which now are
+ ST_Length() is added to implement the same operation
as the now-deprecated GLength(), which has a
nonstandard name because a function named Length()
already existed (to calculate string lengths).
Use of deprecated functions produces a warning. The
deprecated functions will be removed in a future MySQL
* These changes have been made for spatial functions that
operate on minimum bounding rectangles (MBRs) of geometry
+ Two new functions test the covering relationship of
two geometries using their MBRs. MBRCovers()
indicates whether the MBR of one geometry covers
that of another. MBRCoveredBy() tests the opposite,
indicating whether the MBR of one geometry is
covered by that of another.
+ The spatial function MBREquals() has been
implemented. It should be used in preference to
MBREqual(), which is now deprecated. (The new name
is more consistent with the similar Equals()
+ MBRTouches() now correctly uses the geometry MBRs,
not the geometries themselves.
+ MBRTouches() and MBRWithin() better conform to the
Open Geospatial Consortium specification: When a
point lies on the boundary of a line segment or
polygon, or when a line segment lies totally on the
boundary of a polygon, it is not considered "within"
but instead "touches." Also, two identical points
are not considered "touches."
Functionality Added or Changed
* Incompatible Change: A new C API function,
mysql_real_escape_string_quote(), has been implemented as
a replacement for mysql_real_escape_string() because the
latter function can fail to properly encode characters
when the NO_BACKSLASH_ESCAPES SQL mode is enabled. In
this case, mysql_real_escape_string() cannot escape quote
characters except by doubling them, and to do this
properly, it must know more information about the quoting
context than is available.
mysql_real_escape_string_quote() takes an extra argument
for specifying the quoting context. For usage details,
Applications should be modified to use
mysql_real_escape_string_quote(), instead of
mysql_real_escape_string(), which now fails and produces
an CR_INSECURE_API_ERR error if NO_BACKSLASH_ESCAPES is
References: See also Bug #19211994.
* InnoDB: InnoDB system tablespace data is now exposed in
the INNODB_SYS_TABLESPACES and INNODB_SYS_DATAFILES
Information Schema tables.
* InnoDB: CHECK TABLE functionality was enhanced for InnoDB
SPATIAL indexes. Previously, CHECK TABLE only performed
minimal checks on InnoDB SPATIAL indexes. Enhanced
functionality includes an R-tree validity check and a
check to ensure that the R-tree row count matches the
* InnoDB: To modularize and decouple the partitioning
engine from the server code base, partitioning operations
in the storage engine handler class were moved to a new
partition_handler base class, which is now the interface
for partitioning-specific storage engine functionality.
* InnoDB: The MERGE_THRESHOLD value for index pages is now
configurable using a COMMENT clause with CREATE TABLE,
ALTER TABLE, and CREATE INDEX statements. If the
page-full percentage for an index page falls below the
MERGE_THRESHOLD value when a row is deleted or when a row
is shortened by an UPDATE operation, InnoDB attempts to
merge the index page with a neighboring index page. The
default MERGE_THRESHOLD value is 50, which is the
previously hard-coded value.
For more information, see Configuring the Merge Threshold
for Index Pages
* InnoDB: InnoDB now supports native partitioning.
Previously, InnoDB relied on the ha_partition handler,
which creates a handler object for each partition. With
native partitioning, a partitioned InnoDB table uses a
single partition-aware handler object. This enhancement
reduces the amount of memory required for partitioned
The following changes accompany InnoDB native
+ Partition definition (.par) files are no longer
created. Partition definitions are stored in the
internal data dictionary.
+ For partitioned InnoDB tables, FLUSH TABLES does not
reset the "next" AUTO_INCREMENT value. Instead, the
next AUTO_INCREMENT value is kept and used after the
FLUSH TABLES operation. If the highest
AUTO_INCREMENT value is deleted before a FLUSH
TABLES operation, it is not reused afterwards.
+ Minor changes to statistics could result in changed
+ The minimum number of rows estimated for a
partitioned InnoDB table is 1 instead of 2.
+ The minimum number of rows estimated for range read
on a partitioned InnoDB table index is 0 per
partition instead of 1.
+ Instead of only including the largest partitions
when calculating matching rows in an index range,
all partitions in the read set (after pruning is
completed) are included. As a result, statistics for
matching index rows are more accurate, but time
spent during the Optimizer phase may increase for
tables with numerous partitions.
* InnoDB: All remaining code related to the
innodb_file_io_threads system variable, which was removed
in MySQL 5.5, was removed from the source code.
* InnoDB: To support future development, the code that
initializes, validates and handles tablespace and table
flags was refactored. Also, the fil_create_ibd_tablespace
function was refactored, and some functions and variables
related to single tablespaces were renamed.
* InnoDB: InnoDB now supports the creation of general
tablespaces using CREATE TABLESPACE syntax.
CREATE TABLESPACE `tablespace_name`
ADD DATAFILE 'file_name.ibd'
[FILE_BLOCK_SIZE = n]
General tablespaces can be created outside of the MySQL
data directory, are capable of holding multiple tables,
and support tables of all row formats.
Tables are added to a general tablespace using CREATE
TABLE tbl_name ... TABLESPACE [=] tablespace_name or
ALTER TABLE tbl_name TABLESPACE [=] tablespace_name
For more information about this feature, see CREATE
* InnoDB: Replication-related support was added to InnoDB
that enables prioritization of slave applier transactions
over other transactions in deadlock scenarios. This
transaction prioritization mechanism is reserved for
* InnoDB: The default setting for the
internal_tmp_disk_storage_engine option, which defines
the storage engine the server uses for on-disk internal
temporary tables, is now INNODB. With this change, the
Optimizer uses the InnoDB storage engine instead of
MyISAM for internal temporary tables. For related
information,see (see How MySQL Uses Internal Temporary
* InnoDB: The following buffer pool flushing-related
enhancements are included in MySQL 5.7.6:
+ The adaptive flushing algorithm flushes all pages at
the end of the flush list if there is a high
distribution of pages associated with the oldest
+ The adaptive flushing algorithm gives flushing
priority to old modified pages in the buffer pool
instance that contains the greatest number of old
+ On platforms where it is possible, page_cleaner
threads are given priority over other MySQL/InnoDB
threads to help page flushing keep pace with the
+ When the oldest modification LSN is close to the
defined maximum (max_modified_age_sync), a
synchronous preflush of buffer pool pages is
initiated which may result in a "flush wait"
scenario for user threads. To smooth throughput,
user threads are now only required to wait for a
target LSN to be reached instead of waiting for an
entire flushing batch to finish.
+ A block was added to prevent the log write mechanism
from overwriting last checkpoint LSN.
+ A message is printed to the server error log if the
innodb_io_capacity_max setting is too high.
+ New metrics for monitoring page_cleaner thread
activity were added to the INNODB_METRICS table:
o buffer_flush_adaptive_avg_pass: Number of
adaptive flushes passed during the recent Avg
o buffer_flush_adaptive_avg_time_est: Estimated
time (ms) spent for adaptive flushing recently.
o buffer_flush_adaptive_avg_time_slot: Avg time
(ms) spent for adaptive flushing recently per
o buffer_flush_adaptive_avg_time_thread: Avg time
(ms) spent for adaptive flushing recently per
o buffer_flush_avg_pass: Number of flushes passed
during the recent Avg period.
o buffer_flush_avg_time: Avg time (ms) spent for
o buffer_flush_n_to_flush_by_age: Number of pages
targeted by LSN Age for flushing.
o buffer_LRU_batch_flush_avg_pass: Number of LRU
batch flushes passed during the recent Avg
o buffer_LRU_batch_flush_avg_time_est: Estimated
time (ms) spent for LRU batch flushing
o buffer_LRU_batch_flush_avg_time_slot: Avg time
(ms) spent for LRU batch flushing recently per
o buffer_LRU_batch_flush_avg_time_thread: Avg
time (ms) spent for LRU batch flushing recently
o buffer_LRU_get_free_loops: Total loops in LRU
o buffer_LRU_get_free_waits: Total sleep waits in
LRU get free.
* InnoDB: InnoDB now provides a built-in full-text ngram
parser plugin that supports Chinese, Japanese, and Korean
(CJK), and an installable MeCab full-text parser plugin
For more information see InnoDB ngram Full-Text Parser
and InnoDB MeCab Full-Text Parser Plugin
* InnoDB: The Performance Schema now instruments stage
events for monitoring InnoDB ALTER TABLE and buffer pool
load operations. The new stage events include:
+ stage/innodb/alter table (read PK and internal sort)
+ stage/innodb/alter table (merge sort)
+ stage/innodb/alter table (insert)
+ stage/innodb/alter table (flush)
+ stage/innodb/alter table (log apply index)
+ stage/innodb/alter table (log apply table)
+ stage/innodb/alter table (end)
+ stage/innodb/buffer pool load
For more information, see InnoDB Integration with MySQL
and Preloading the InnoDB Buffer Pool for Faster Restart
* InnoDB: InnoDB now supports 32KB and 64KB page sizes. For
both page sizes, the maximum record size is 16KB.
ROW_FORMAT=COMPRESSED is not supported when
innodb_page_size is set to 32k or 64k. For
innodb_page_size=32k, extent size is 2MB. For
innodb_page_size=64k, extent size is 4MB.
* Replication: The variable binlogging_impossible_mode has
been renamed binlog_error_action.
binlogging_impossible_mode is now deprecated. (Bug
* Replication: When using InnoDB with binary logging
enabled, concurrent transactions written in the InnoDB
redo log are now grouped together before synchronizing to
disk when innodb_flush_log_at_trx_commit is set to 1,
which reduces the amount of synchronization operations.
This can lead to improved performance. (Bug #19424075)
* Replication: There is now a Previous_gtids event in every
binary log, regardless of the value of gtid_mode. In
previous versions, it was only generated when
gtid_mode=on. Similarly, there is now an Anonymous_gtid
event before every transaction when gtid_mode=off. These
changes ensure that similar per-transaction events are
generated regardless of the type of binary logging in
use. As well as enabling the newly added ability to
change gtid_mode online, this also has a positive impact
on the recovery of gtid_purged and gtid_executed.
* Replication: It is now possible to change replication
mode without having to shut down the server or
synchronize the topology. As part of this feature, the
following changes have been made:
+ The variable gtid_mode is now dynamic. It can be set
by SUPER from a top-level statement. The states
OFF_PERMISSIVE and ON_PERMISSIVE have been added.
+ The variable enforce_gtid_consistency is now
dynamic. It can be set by SUPER from a top-level
+ The status variable
Ongoing_anonymous_transaction_count has been
introduced. This shows the number of ongoing
transactions which have been marked as anonymous.
+ The status variables
have been introduced in debug-enabled builds. They
are not available in non-debug builds. These
variables count the number of ongoing transactions
that violate GTID consistency, which use
gtid_next=ANONYMOUS and gtid_next=AUTOMATIC,
* Replication: A new more general purpose parallelization
algorithm is now used when
slave_parallel_type=LOGICAL_CLOCK, replacing the previous
algorithm that was limited to transactions on different
databases. This improves throughput when transactions on
the master do not depend on each other. Now even two
concurrent transactions on a master can execute in
parallel on a slave, if they hold all of their locks on
the master. Additionally, transaction dependency is now
tracked on the slave through extra fields added to
replication transactions in the binary log.
* Undocumented functions in the C client library now are
hidden. This help minimize namespace pollution, and
permits linking for applications that require functions
both from yaSSL (in the client library) and from OpenSSL.
* CMake support was updated to handle CMake version 3.1.
* Previously, debug builds on Windows were built with /Ob0,
which disables function inlining. Builds now use /Ob1 to
enable inlining. The new WIN_DEBUG_NO_INLINE CMake option
can be used to control inlining. The default value is OFF
(inlining enabled); if set to ON, inlining is disabled.
* yaSSL was upgraded to version 2.3.7. (Bug #19695101, Bug
* The new -DWITH_UBSAN=ON CMake option enables the
Undefined Behavior Sanitizer. This feature is supported
by GCC 4.9 and up, and Clang 3.4 and up. (Bug #19587393)
* The valid date range of the SSL certificates in
mysql-test/std_data has been extended to the year 2029.
* Overhead was reduced for queries such as tested by the
sysbench "order-by-range" test. (Bug #75390, Bug
* The mysql client program now supports \C in the prompt
command to signify the current connection identifier.
Thanks to Tsubasa Tanaka for the patch. (Bug #75242, Bug
* The server now includes its version number when it writes
the initial "starting" message to the error log, to make
it easier to tell which server instance error log output
applies to. This value is the same as that available from
the version system variable. (Bug #74917, Bug #20052694)
* The required version of the Boost library for server
builds has been raised from 1.55.0 to 1.57.0. (Bug
#74666, Bug #19940297, Bug #73432, Bug #19320102)
* Previously, the auth_socket authentication plugin checked
the socket user name only against the MySQL user name
specified by the client program to the server. Now, if
those names do not match, the plugin also checks whether
the socket user name matches the name specified in the
authentication_string column of the mysql.user table row.
The plugin permits the connection for a match in either
case. Thanks to Daniël van Eeden for the patch. (Bug
#74586, Bug #20041925)
* The libmysqlclient version number has been incremented to
20.0.0. (Bug #74206, Bug #19729266)
* A new CMake option, WITH_MSCRT_DEBUG, is available to
control Visual Studio CRT memory leak tracing. The
default is OFF. (Bug #73064, Bug #19031370)
* Beginning with MySQL 5.7.2, the server disables at
startup any account that has no authentication plugin.
The server now writes a more extensive message to the
error log in this case to indicate how to reenable such
accounts. (Bug #73026, Bug #19011337)
* ALTER TABLE did not take advantage of fast alterations
that might otherwise apply to the operation to be
performed, if the table contained temporal columns found
to be in pre-5.6.4 format (TIME, DATETIME, and TIMESTAMP
columns without support for fractional seconds
precision). Instead, it upgraded the table by rebuilding
it. Two new system variables enable control over
upgrading such columns and provide information about
+ avoid_temporal_upgrade controls whether ALTER TABLE
implicitly upgrades temporal columns found to be in
pre-5.6.4 format. This variable is disabled by
default. Enabling it causes ALTER TABLE not to
rebuild temporal columns and thereby be able to take
advantage of possible fast alterations.
+ show_old_temporals controls whether SHOW CREATE
TABLE output includes comments to flag temporal
columns found to be in pre-5.6.4 format. Output for
the COLUMN_TYPE column of the
INFORMATION_SCHEMA.COLUMNS table is affected
similarly. This variable is disabled by default.
Both variables are deprecated and will be removed in a
future MySQL release. (Bug #72997, Bug #18985760)
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql