オリジナル版：http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-4.html
MySQL 5.7.4(マイルストーンリリース)は世界でもっともポピュラーなオープンソースデータベースの新しいバージョンです。これはMySQL 5.7の4番目のマイルストーンリリースです。
このリリースの新機能はベータ品質です。他のプロダクションリリース前と同様にプロダクションレベルのシステムやクリティカルなデータを持つシステムにインストールする場合には十分に注意すべきです。
MySQL 5.7.4はMySQL 5.6のすべての機能を含んでいます
新しいサーバへMySQL 5.7.4をインストールする情報として、以下のMySQLのインストールドキュメントを参照してください。
http://dev.mysql.com/doc/refman/5.7/en/installing.html
MySQL Server 5.7.4は、ダウンロード・ページの開発リリースセクションから、ソースコードと多くのプラットフォームのためのバイナリをご利用いただけます。
http://dev.mysql.com/downloads/
MySQL 5.7.4で利用できるプラットフォームとパッケージのフォーマットはMySQL 5.6と同じです。
WindowsパッケージはWindowsインストーラーのための新しいインストーラ、もしくはZIP(ノンインストール)パッケージが利用いただけます。以前のMSIパッケージはもう利用できず、ポイントアンドクリック設定ウィザードと全てのMySQL製品でWindows向けの統一インストーラが利用可能なことに注意してください：
http://dev.mysql.com/downloads/installer/
新規リリースされたMySQl 5.6.20と同様、5.7.4は完全なインストーラーの代替としてWebインストーラーも同梱されています
Webインストーラーは実際の製品すべてにバンドルされているわけではなく、インストールのために洗濯したダウンロードオンデマンドの製品を選択したときにのみ同梱されます。これは最初にダウンロードするサイズを小さくしますが、個々のプロダクトをダウンロードする必要があるため、インストール時間は長くなります。
私たちはフィードバック、バグレポート、バグ修正パッチ等を歓迎します
http://bugs.mysql.com/report.php
次の節では、開発開始から、そして5.6.10には含まれていないバグの修正、MySQL 5.7の変更を記載しています。これはオンラインでも閲覧できます。
http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-1.html
Changes in MySQL 5.7.4 (2014-03-31, Milestone 14)
Note
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.
Performance Schema Notes
* The Performance Schema now instruments prepared statements
(for both the binary and text protocols):
+ Information about prepared statements is available in the
prepared_statements_instances table. This table enables
inspection of prepared statements used in the server and
provides aggregated statistics about them.
+ The performance_schema_max_prepared_statements_instances
system variable controls the size of the table.
+ The Performance_schema_prepared_statements_lost status
variable indicates how many prepared statements could not
be insrumented.
For more information, see The prepared_statements_instances
Table
(http://dev.mysql.com/doc/refman/5.7/en/prepared-statements-in
stances-table.html).
If you upgrade to this release of MySQL from an earlier
version, you must run mysql_upgrade (and restart the server)
to incorporate these changes into the performance_schema
database.
Security Notes
* Incompatible Change: MySQL deployments installed using RPM
packages now are secure by default. The following changes have
been implemented as the default deployment characteristics:
+ The installation process creates only a single root
account, 'root'@'localhost', automatically generates a
random password for this account, and marks the password
expired. The MySQL administrator must connect as root
using the random password and use SET PASSWORD to select
a new password. (The random password is found in the
$HOME/.mysql_secret file.)
+ Installation creates no anonymous-user accounts.
+ Installation creates no test database.
Those changes are implemented by modifying the default mode of
operation for mysql_install_db, which is invoked automatically
during RPM installation operations. Therefore, the changes
also affect non-RPM installation methods for which you invoke
mysql_install_db manually.
Because mysql_install_db deployment now is secure by default,
the --random-passwords option is unnecessary and has been
removed. It has been replaced by the --skip-random-passwords
option. You can use this option to explicitly produce a
deployment that is not secure by default:
+ Installation creates a single root account,
'root'@'localhost', that has no password.
+ A test database is created that is accessible by any
user.
Note
mysql_install_db no longer creates anonymous-user accounts,
even with --skip-random-passwords.
The mysql_secure_installation program now has a --use-default
option, which causes the program to execute noninteractively.
It can be used for unattended install operations.
* Incompatible Change: MySQL now enables database administrators
to establish a policy for automatic password expiration: Any
user who connects to the server using an account for which the
password is past its permitted lifetime must change the
password. The implementation has these components:
+ The default_password_lifetime system variable defines
global password expiration policy. A value of N greater
than zero means that passwords have a lifetime of N days.
A value of 0 disables automatic password expiration. The
default is 360; passwords must be changed approximately
once per year.
+ The mysql.user table has new columns that store
expiration policy information for individual accounts:
o password_last_changed indicates when the password
was last changed. The server uses this column when
clients connect to determine whether the password is
past its lifetime and must be changed per the
expiration policy in effect.
o password_lifetime indicates the account password
lifetime. A value of N greater than zero means that
the password has a lifetime of N days. 0 disables
automatic password expiration. NULL (the default)
means that the global expiration policy applies.
+ The ALTER USER statement has new options to set password
expiration policy for individual accounts.
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.user table. For each
account, mysql_upgrade uses the time at which it executes to
set the password_last_changed column and sets
password_lifetime to NULL. This causes the default global
expiration policy to go into effect (passwords have a lifetime
of 360 days).
For more information, see Password Expiration Policy
(http://dev.mysql.com/doc/refman/5.7/en/password-expiration-po
licy.html), and ALTER USER Syntax
(http://dev.mysql.com/doc/refman/5.7/en/alter-user.html).
Functionality Added or Changed
* Performance; InnoDB: InnoDB now supports multiple page_cleaner
threads for flushing dirty pages from buffer pool instances. A
new system variable, innodb_page_cleaners, is used to specify
the number of page_cleaner threads. The default value of 1
maintains the pre-MySQL 5.7.4 configuration in which there is
only a single page_cleaner thread. This enhancement builds on
work completed in MySQL 5.6.2, which introduced a single page
cleaner thread to offload buffer pool flushing work from the
InnoDB master thread.
* Incompatible Change: The AES_ENCRYPT() and AES_DECRYPT()
functions now permit control of the block encryption mode and
take an optional initialization vector argument:
+ The new block_encryption_mode system variable controls
the mode for block-based encryption algorithms. Its
default value is aes-128-ecb, which signifies encryption
using a key length of 128 bits and ECB mode.
+ An optional init_vector argument provides an
initialization vector for encryption modes that require
it:
AES_ENCRYPT(str,key_str[,init_vector])
AES_DECRYPT(crypt_str,key_str[,init_vector])
+ A random string of bytes to use for the initialization
vector can be produced by calling the new RANDOM_BYTES()
function.
For more information, see Encryption and Compression Functions
(http://dev.mysql.com/doc/refman/5.7/en/encryption-functions.h
tml).
These changes make statements that use AES_ENCRYPT() or
AES_DECRYPT() unsafe for statement-based replication and they
cannot be stored in the query cache. Queries that use
RANDOM_BYTES() are unsafe for statement-based replication and
cannot be stored in the query cache.
* Incompatible Change: The deprecated
ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE
SQL modes now do nothing. Instead, their previous effects are
included in the effects of strict SQL mode (STRICT_ALL_TABLES
or STRICT_TRANS_TABLES). In other words, strict mode now means
the same thing as the previous meaning of strict mode plus the
ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE
modes. This change reduces the number of SQL modes with an
effect dependent on strict mode and makes them part of strict
mode itself.
To prepare for the SQL mode changes in this version of MySQL,
it is advisable before upgrading to read SQL Mode Changes in
MySQL 5.7
(http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-mode
-changes). That discussion provides guidelines to assess
whether your applications will be affected by these changes.
The deprecated ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and
NO_ZERO_IN_DATE SQL modes are still recognized so that
statements that name them do not produce an error, but will be
removed in a future version of MySQL. To make advance
preparation for versions of MySQL in which these modes do not
exist, applications should be modified to not refer to those
mode names.
* InnoDB: InnoDB now supports the Transportable Tablespace
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_tra
nsportable_tablespace) feature for partitioned InnoDB tables
and individual InnoDB table partitions. This enhancement eases
backup procedures for partitioned tables and enables copying
of partitioned tables and individual table partitions between
MySQL instances. For additional information, see Copying
Tablespaces to Another Server (Transportable Tablespaces)
(http://dev.mysql.com/doc/refman/5.7/en/tablespace-copying.htm
l). (Bug #18121824, Bug #70196, Bug #18304194, Bug #71784)
* InnoDB: Parameters used to identify an InnoDB pages are
replaced by two new classes, and fold value and zip_size value
calculations have been optimized. These changes simplify code
by reducing the number of page identifier parameters passed to
functions. (Bug #18073495)
* InnoDB: The Fusion-io Non-Volatile Memory (NVM) file system on
Linux provides atomic
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_ato
mic) write capability, which makes the InnoDB doublewrite
buffer
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_dou
blewrite_buffer) redundant. For system tablespace files
(ibdata files
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_ibd
ata_file)) located on Fusion-io devices that support atomic
writes, the InnoDB doublewrite buffer is automatically
disabled. (Bug #18069105)
* InnoDB: Reverse index leaf page scan has been optimized.
btr_pcur_restore_position_func() can now perform optimistic
restoration for reverse cursors, which reduces block->mutex
contention on the root page, especially for concurrent reverse
scans. (Bug #17666170)
* InnoDB: A new system variable, innodb_log_write_ahead_size,
allows you to configure the write-ahead block size for redo
logs to a value that matches the operating system or file
system cache block size in order to avoid "read-on-write" for
redo log writes. Read-on-write occurs when redo log blocks are
not entirely cached to the operating system or file system due
to a mismatch between write-ahead block size for redo logs and
operating system or file system cache block size. Avoiding
read-on-write improves throughput stability for redo log
writes. (Bug #17571371)
* InnoDB: MySQL now supports rebuilding regular and partitioned
InnoDB tables using online DDL
(http://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl.html
) (ALGORITHM=INPLACE) for the following operations:
+ OPTIMIZE TABLE
+ ALTER TABLE ... FORCE
+ ALTER TABLE ... ENGINE=INNODB (when run on an InnoDB
table)
Online DDL
(http://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl
.html) support reduces table rebuild time and permits
concurrent DML, which helps reduce user application
downtime. For additional information, see Overview of
Online DDL
(http://dev.mysql.com/doc/refman/5.7/en/innodb-create-ind
ex-overview.html).
(Bug #13975225)
* InnoDB: New global configuration parameters,
innodb_status_output and innodb_status_output_locks, allow you
to dynamically enable and disable the standard InnoDB Monitor
and InnoDB Lock Monitor for periodic output. Previously,
enabling and disabling these monitors for periodic output
required creating and dropping specially named tables
(innodb_monitor and innodb_lock_monitor). For additional
information, see InnoDB Monitors
(http://dev.mysql.com/doc/refman/5.7/en/innodb-monitors.html).
* InnoDB: The InnoDB Tablespace Monitor and InnoDB Table Monitor
are removed in MySQL 5.7.4. For the Tablespace Monitor,
equivalent functionality will be introduced before the GA
release of MySQL 5.7. For the Table Monitor, equivalent
information can be obtained from InnoDB INFORMATION_SCHEMA
tables.
* InnoDB: MySQL now includes a gb18030 character set that
supports the China National Standard GB18030 character set.
For more information about MySQL character set support, see
Character Set Support
(http://dev.mysql.com/doc/refman/5.7/en/charset.html).
* Replication: The binary log dump thread has been optimized by
removing unnecessary reallocation of the send buffer.
Previously, memory was allocated then freed for every event
sent to the slave, even when this was not strictly necessary.
Following this optimization, the MySQL Server can make better
use of hardware resources by having the dump thread employ
adaptative memory allocation, which can also result in less
CPU usage. (Bug #11747349, Bug #31932, Bug #11752288, Bug
#43426, Bug #13727951)
* Replication: Implemented separate threads for sending and
receiving semisynchronous replication acknowledgement signals,
so that event streams and ACK streams can be sent and received
simultaneously. This should reduce many common delays and thus
improve performance with semisynchronous replication in a
number of settings.
* Replication: It is now possible in many cases to execute
CHANGE MASTER TO without first issuing STOP SLAVE. This
capability is added by implementing the following changes in
the behavior of the CHANGE MASTER TO statement, which now
depends only on whether the slave SQL thread or slave I/O
thread is stopped, as described here:
+ If the SQL thread is stopped, you can execute CHANGE
MASTER TO using the RELAY_LOG_FILE, RELAY_LOG_POS, and
MASTER_DELAY options, even if the slave I/O thread is
running. No other options may be used with this statement
when the I/O thread is running.
+ If the I/O thread is stopped, you can execute CHANGE
MASTER TO using any of the options for this statement
except RELAY_LOG_FILE, RELAY_LOG_POS, or MASTER_DELAY,
even when the SQL thread is running. These three options
cannot be used when the I/O thread is running.
+ Both the SQL thread and the I/O thread must be stopped
before issuing CHANGE MASTER TO with MASTER_AUTO_POSITION
= 1.
If you are using statement-based replication and temporary
tables, it is possible for a CHANGE MASTER TO statement
following a STOP SLAVE statement to leave behind temporary
tables on the slave. As part of this set of improvements, a
warning is now issued whenever this occurs. You can avoid this
in such cases by making sure that Slave_open_temp_tables is
equal to 0 prior to executing these statements.
For more information, see CHANGE MASTER TO Syntax
(http://dev.mysql.com/doc/refman/5.7/en/change-master-to.html)
, and Switching Masters During Failover
(http://dev.mysql.com/doc/refman/5.7/en/replication-solutions-
switch.html).
* Performance Schema performance was improved in the following
ways:
+ When a thread connects, reset of all per-thread
statistics is now delayed until a statistic is actually
collected. This lazy initialization benefits workloads
with very short-lived sessions, for which instrumentation
is disabled.
+ When a thread disconnects, the per-thread statistics are
aggregated to a parent only for statistics that actually
collected data. This optimization benefits workloads with
very short-lived sessions, for which instrumentation is
disabled.
+ For statement instrumentation, reset of an individual
EVENT_NAME statistic is also now delayed until a
statistic is actually collected. This benefits all
workloads that contain only a few types of statements
(SELECT, INSERT, UPDATE, DELETE, and so forth) from the
very large set statements supported in MySQL. Only
statements for event names actually executed are
aggregated on disconnect.
+ The memory footprint of internal memory buffers is
reduced, by removing some attributes reserved for future
use, that were in fact not used. In particular,
statistics for mutexes, rwlocks and conditions now need
less memory.
(Bug #18324285)
* On Windows, NOMINMAX is set using the ADD_DEFINITIONS() CMake
macro rather than in config.h.cmake so that it is set even
without including my_config.h. (Bug #18192896)
* On Solaris, mysql_config --libs now includes
-R/path/to/library so that libraries can be found at runtime.
(Bug #18235669)
* CMake support for compiling MySQL with gcc on Solaris was
improved. Binary distributions for Solaris now are built using
gcc rather than Sun Studio, to enable compilation of code not
handled by Sun Studio. The client programs and the client
libraries except the embedded library are still built using
Sun Studio.
A consequence of this change is that on Solaris, mysql_config
no longer provides arguments for linking with the embedded
library, since this is now built using gcc instead of Sun
Studio. To get linking arguments for the embedded library, use
the alternative script mysql_server_config instead. (Bug
#18146422, Bug #17826757)
* The CHECK_FUNCTION_REPLACEMENT() CMake macro was removed from
Windows.cmake and replacement functions are set explicitly
instead since the result of the check was already hard coded
in WindowsCache.cmake. (Bug #18116661)
* MySQL now compiles using Clang 3.4. (Bug #18047020)
* In MySQL 5.7.1, the MySQL test suite mysql-test-run.pl program
was modified to start the server with InnoDB rather than
MyISAM as the default storage engine. All tests in the MySQL
test suite were modified to include a force_default_myisam.inc
file. This had to be done because most legacy test results
were recorded with the MyISAM engine and failed with a result
difference if run with InnoDB. A project is underway to
migrate these tests and remove force_default_myisam.inc for
tests that do not need MyISAM. In 5.7.4, the rpl and binlog
suites and parts of the main suite were migrated. (Bug
#17902011)
* Performance Schema instrumentation was added to capture GTIDs
for transaction events. (Bug #17799147)
* Performance Schema overhead was reduced for the pfs_lock
implementation and the uses of atomic operations in general.
(Bug #17766582)
* CMake now aborts the configuration process on Windows if a
Visual Studio version earlier than 2010 is used. (Bug
#17730320)
* A new CMake option, WITH_MSAN, permits enabling
MemorySanitizer for compilers that support it. (Bug #17632319)
* Previously, ALTER TABLE in MySQL 5.6 could alter a table such
that the result had temporal columns in both 5.5 and 5.6
format. Now ALTER TABLE upgrades old temporal columns to 5.6
format for ADD COLUMN, CHANGE COLUMN, MODIFY COLUMN, ADD
INDEX, and FORCE operations. This conversion cannot be done
using the INPLACE algorithm, so specifying ALGORITHM=INPLACE
in these cases results in an error. (Bug #17246318)
* Overhead was reduced for filesort comparison operations. (Bug
#14635144)
* Overhead was reduced for metadata lock acquisition for DML
statements. (Bug #58627, Bug #11765641)
* CMake now supports a -DTMPDIR=dir_name option to specify the
default tmpdir value. If unspecified, the value defaults to
P_tmpdir in . Thanks to Honza Horak for the patch.
(Bug #68338, Bug #16316074)
* Based on community feedback, the default value of 10 for the
eq_range_index_dive_limit system variable has proven to be too
low. The default has been raised to 200. (Bug #70586, Bug
#17587952)
* Code instrumented with Valgrind did not preallocate memory in
alloc_root(), to help find bugs. This behavior is now also
enabled if ASAN (address sanitizer) is used. (Bug #44582, Bug
#11753184)
* mysql_install_db provides a more informative diagnostic
message when required Perl modules are missing. (Bug #69844,
Bug #18187451)
* MySQL now supports server-side timeouts for execution of
SELECT statements:
+ SELECT supports a MAX_STATEMENT_TIME option to specify a
timeout for individual queries. For example:
SELECT MAX_STATEMENT_TIME = 5000 id, name FROM my_table WHERE ...
+ The max_statement_time system variable specifies the
timeout value for SELECT statements executed within the
session that include no MAX_STATEMENT_TIME option. If the
value is 0, timeouts are not enabled.
+ The Max_statement_time_exceeded, Max_statement_time_set,
and Max_statement_time_set_failed status variables
provide information about SELECT statements affected by
timeouts.
Timeout values are in milliseconds.
For more information, see SELECT Syntax
(http://dev.mysql.com/doc/refman/5.7/en/select.html), and
Server System Variables
(http://dev.mysql.com/doc/refman/5.7/en/server-system-variable
s.html).
Thanks to Davi Arnaut for the patch on which this feature is
based. (Bug #68252, Bug #16271666)
* The metadata locking subsystem implementation now uses
lock-free hashing rather than a hash protected by a mutex. An
implication of this change is that the
metadata_locks_cache_size and metadata_locks_hash_instances
system variables no longer have any effect, so they are
deprecated and will be removed in a future MySQL release.
* The deprecated IGNORE clause for ALTER TABLE has been removed
and its use produces an error.
* The metadata locking subsystem now uses a lock-free algorithm
for acquiring and releasing locks typical for DML statements.
This gives better performance/scalability on multi-core
machines in workloads involving lots of small read-only
transactions.
* To make it possible to change connections in a load-balanced
environment, it is necessary to detect in the response packet
whether there is session state to take into consideration when
deciding whether a switch can be made. For this purpose,
session state consists of these values:
+ The default schema (database)
+ Session-specific values for system variables
+ User-defined variables
+ Temporary tables
+ Prepared statements
The OK response packet of the MySQL client/server protocol now
includes tracker information so that session state changes can
be detected. The tracker mechanism provides a means for MySQL
Connectors, Fabric, and client applications to determine
whether any session context is available to ensure session
migration from one server to another. The user interface to
control the tracker and retrieve state-change information from
it has the following components, which enable implementation
of state-change tracking on the client side:
+ Clients can request notification when there is a change
to any of the session state-related values just listed,
in the form of a flag that is set in the OK packet
received from the server after the change occurs. To
control notification, enable or disable the
session_track_state_change system variable. This variable
is disabled by default.
+ Clients can request notification of changed values for
certain specific types of session state information:
o The default schema name. To control notification,
enable or disable the session_track_schema system
variable. This variable is enabled by default.
o The session values of system variables. Notification
occurs for the system variables named by the
session_track_system_variables system variable. By
default, notification is enabled for time_zone,
autocommit, character_set_client,
character_set_results, and character_set_connection.
(The latter three variables are those affected by
SET NAMES.)
+ To enable applications to extract the state-change
information returned in the OK packet by the server, the
MySQL C API includes a pair of functions:
o mysql_session_track_get_first() fetches the first
state-change information received from the server.
o mysql_session_track_get_next() fetches any remaining
state-change information received from the server.
Following a successful call to
mysql_session_track_get_first(), call this function
repeatedly as long as it returns success.
+ The mysqltest program has enable_session_track_info and
disable_session_track_info commands to enable and disable
tracking of session state-change information.
For more information, see Server System Variables
(http://dev.mysql.com/doc/refman/5.7/en/server-system-variable
s.html) and mysql_session_track_get_first()
(http://dev.mysql.com/doc/refman/5.7/en/mysql-session-track-ge
t-first.html). For information about the structure of the OK
packet itself, see OK_Packet
(http://dev.mysql.com/doc/internals/en/packet-OK_Packet.html).
* MySQL Yum Repository: mysqlbug
(http://dev.mysql.com/doc/refman/5.7/en/mysqlbug.html), an
obsolete program for generating bug reports, has been removed
from the RPM packages delivered by the MySQL Yum Repository
for installing the MySQL Server on EL5, EL6, and EL7-based
platforms.
Bugs Fixed
* Incompatible Change: Old clients (older than MySQL 5.5.7)
failed to parse authentication data correctly if the server
was started with the
--default-authentication-plugin=sha256_password option.
Note
As a result of this bug fix, MySQL 5.6.16 clients cannot
connect to a 5.6.17 server using an account that authenticates
with the sha256_password plugin. Similarly, MySQL 5.7.3
clients cannot connect to a 5.7.4 server using an account that
authenticates with the sha256_password plugin.
(Bug #17495562)
* Important Change; InnoDB; Partitioning: The FLUSH TABLES
statement's FOR EXPORT option is now supported for partitioned
InnoDB tables. (Bug #16943907)
* InnoDB; Replication: Using the InnoDB memcached plugin (see
InnoDB Integration with memcached
(http://dev.mysql.com/doc/refman/5.7/en/innodb-memcached.html)
) with innodb_api_enable_binlog set to 1 caused the server to
leak memory. (Bug #70757, Bug #17675622)
* InnoDB: trx_undo_truncate_start would write to the redo log
for temporary undo log segments, resulting in a purge thread
assertion. (Bug #18252937)
* InnoDB: A !sync_check_iterate(check) assertion occurred in
fts_create_doc_id() during an INSERT operation. (Bug
#18253210)
* InnoDB: The GCC 4.4 Compiler would emit a bogus warnings about
InnoDB parsing functions, indicating that output is
uninitialized. (Bug #18192536)
* InnoDB: log_mutex_exit should be called before
log_buffer_extend when the log buffer mutex is held. (Bug
#18202904)
* InnoDB: InnoDB would write to the redo log for some operations
on temporary tablespaces. (Bug #18226934)
* InnoDB: Doublewrite buffer error messages referenced page
numbers in an inconsistent manner. (Bug #18242594)
* InnoDB: The truncate_t::drop_indexes and
truncate_t::create_indexes methods would disable redo logging
when modifying the system tablespace. (Bug #18236000)
* InnoDB: Unused parameters and variables along with disabled
functionality has been removed from redo log code. This patch
also includes redo log code improvements including test
enablement, addition of Valgrind instrumentation, and minor
code refactoring. (Bug #18251675)
* InnoDB: An invalid memmove in fts_query_fetch_document would
cause a serious error. (Bug #18229433)
* InnoDB: For full-text queries, a failure to check that
num_token is less than max_proximity_item could result in an
assertion. (Bug #18233051)
* InnoDB: InnoDB would perform unnecessary redo log writes and
flushing for temporary tablespaces. (Bug #18236692)
* InnoDB: The user defined type, xid_t, was defined multiple
times. (Bug #18251254)
* InnoDB: To simplify code and reduce memory usage, InnoDB redo
log scan records for file-level operations, previously stored
in a hash table, are now processed immediately. (Bug
#18180875)
* InnoDB: The loader in some Solaris versions would refuse to
start a GCC-compiled binary (such as the mysqld binary) that
uses the PAUSE assembler instruction. (Bug #18122171)
* InnoDB: Temporary tablespace file size did not match the file
size specified by --innodb-temp-data-file-path due to an error
in file size allocation logic. (Bug #18141070)
* InnoDB: innodb_ft_result_cache_limit now has a hardcoded
maximum value of 4294967295 bytes or (2**32 -1). The maximum
value was previously defined as the maximum value of ulong.
(Bug #18180057, Bug #71554)
* InnoDB: InnoDB would fail to restore a corrupt first page of a
system tablespace data file from the doublewrite buffer,
resulting in a startup failure. (Bug #18144349, Bug #18058884)
* InnoDB: An UPDATE resulted in a memory access error in
lock_rec_other_trx_holds_expl. The transaction list
(trx_sys->rw_trx_list) was traversed without acquiring the
transaction subsystem mutex (trx_sys->mutex). (Bug #18161853)
* InnoDB: TRUNCATE TABLE on Windows would report multiple
'chsize' returned OS error 71 errors. (Bug #18176071, Bug
#71173)
* InnoDB: A regression introduced by Bug #14329288 would result
in a performance degradation when a compressed table does not
fit into memory. (Bug #18124788, Bug #71436)
* InnoDB: In the case of a corrupted clustered index on a
temporary table, the server would crash on an INSERT instead
of returning an error. In the case of a corrupted clustered
index on a normal table, an error was not returned and the
INSERT would succeed. (Bug #18064548)
* InnoDB: Specifying an alternate directory for InnoDB tables
using datadir and then moving .ibd files
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_ibd
_file) to the default MySQL data directory would result in a
serious error when attempting a DROP TABLE operation. (Bug
#18063570)
* InnoDB: The UNIV_LOG_DEBUG debug flag, which is no longer
fully functional, has been removed. (Bug #18080537)
* InnoDB: A compilation error (unable to find string literal
operator) was returned when building in c++11 mode. (Bug
#18082139)
* InnoDB: INFORMATION_SCHEMA.INNODB_TRX contained a bogus
transaction ID that did not match transaction ID values
printed elsewhere. The method used to retrieve transaction IDs
was inconsistent. (Bug #18111007)
* InnoDB: The maximum value for innodb_thread_sleep_delay is now
1000000 microseconds. The previous maximum value (4294967295
microseconds on 32-bit and 18446744073709551615 microseconds
on 64-bit) was unnecessarily large. Because the maximum value
of innodb_thread_sleep_delay is limited by the value set for
innodb_adaptive_max_sleep_delay (when set to a non-zero
value), the maximum value for innodb_thread_sleep_delay is now
the same as the maximum value for
innodb_adaptive_max_sleep_delay. (Bug #18117322)
* InnoDB: The fil_node_create function would perform an
unnecessary hash table lookup. (Bug #18116588)
* InnoDB: When starting the server, unnecessary "checking space"
log messages would be printed when processing the doublewrite
buffer
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_dou
blewrite_buffer). (Bug #18101380)
* InnoDB: A full-text tokenizer thread would terminate with an
incorrect error message. (Bug #18021306)
* InnoDB: Attempting to uninstall the InnoDB memcached plugin
while the InnoDB memcached plugin is still initializing would
kill the InnoDB memcached daemon thread. Uninstall should wait
until initialization is complete. (Bug #18038948)
* InnoDB: In debug builds, creating a unique index on a binary
column, with input data containing duplicate keys, would cause
an assertion. (Bug #18010711)
* InnoDB: Logging functions were not used consistently. The bug
fix replaces occurrences of fprintf(stderr, message) and
fputs() with ib_logf(). Also, because ib_logf() emits a
timestamp with each message, the bug fix removes unnecessary
occurrences of ut_print_timestamp(). (Bug #17935793, Bug
#17534737)
* InnoDB: A boolean mode full-text search query would result in
a memory access violation during parsing. (Bug #17978763)
* InnoDB: The srv_monitor_thread would crash in the
lock_print_info_summary() function due to a race condition
between the srv_monitor_thread and purge coordinator thread.
(Bug #17980590, Bug #70430)
* InnoDB: On Windows, a regression introduced in 5.7.3 would
allow log writes during sync operations, which should not be
allowed due to an issue in some Windows environments. (Bug
#17824101)
* InnoDB: Due to a parser error, full-text search queries that
include a sub-expression could return the wrong result. (Bug
#17840768)
* InnoDB: The innochecksum tool did not use a Windows-specific
API to retrieve file size information, which resulted in an
incorrect error message (Error: ibdata1 cannot be found) when
the MySQL 5.6 innochecksum 2GB file size limit was exceeded.
innochecksum now provides support for files larger than 2GB in
both MySQL 5.6 and MySQL 5.7. (Bug #17810862, Bug #70936)
* InnoDB: Due to a regression introduced by the fix for
Bug#17371537, memory was not allocated for the default
memcached engine when using the default memcached engine as
the backstore for data instead of InnoDB. (Bug #17800829)
* InnoDB: If a crash occurred while temporary tables are active,
InnoDB would report an invalid error message on restart
indicating that a temporary table does not exist in the InnoDB
internal data dictionary. (Bug #17779729)
* InnoDB: A page allocation for an undo log due would fail with
a "table is full" error message instead of an "undo log is
full" error message. (Bug #17779822)
* InnoDB: ut_free could be called more than once in succession.
(Bug #17763472)
* InnoDB: An index tree modification could result in a deadlock.
(Bug #17754767)
* InnoDB: Manipulating a table after discarding its tablespace
using ALTER TABLE ... DISCARD TABLESPACE could result in a
serious error. (Bug #17700280)
* InnoDB: A race condition in DebugPolicy::enter() would cause a
segmentation fault in sync_array_cell_print. (Bug #17713784)
* InnoDB: Persistent optimizer statistics would cause stalls due
to latch contention. (Bug #17699331, Bug #70768)
* InnoDB: MATCH() ... AGAINST queries that use a long string as
an argument for AGAINST() could result in an error when run on
an InnoDB table with a full-text search index. (Bug #17640261)
* InnoDB: An InnoDB full-text search failure would occur due to
an "unended" token. The string and string length should be
passed for string comparison. (Bug #17659310)
* InnoDB: Databases names beginning with a digit or special
character would cause a full-text search (FTS) parser error.
(Bug #17607687)
References: See also Bug #17607956.
* InnoDB: For debug builds, the table rebuilding variant of
online ALTER TABLE, when run on tables with BLOB columns,
would cause an assertion in the row_log_table_apply_update
function. For normal builds, a DB_PRODUCTION error would be
returned. (Bug #17661919)
* InnoDB: Under certain conditions, a regression introduced by
the fix for Bug #11758237 would cause an assertion error when
INSERT ... ON DUPLICATE KEY UPDATE or REPLACE statements
encounter a DB_DUPLICATE_KEY error. (Bug #17604730)
* InnoDB: In debug builds, a merge insert buffer during a page
read would cause a memory access violation. (Bug #17561188)
* InnoDB: The patch for Bug #16852278, which simplifies and
optimizes comparison functions in InnoDB, caused a query
performance regression. (Bug #17543588)
* InnoDB: Truncating a memcached InnoDB table while memcached is
performing DML operations would result in a serious error.
(Bug #17468031)
* InnoDB: In sync0rw.ic, rw_lock_x_lock_func_nowait would
needlessly call os_thread_get_curr_id. (Bug #17509710, Bug
#70417)
* InnoDB: Attempting to rename a table to a missing database
would result in a serious error. (Bug #17447500)
* InnoDB: If a tablespace data file path is updated in a .isl
file and then a crash recovery is performed, the updated
tablespace data file path is read from the .isl file but the
SYS_DATAFILES table would not be not updated. The
SYS_DATAFILES table is now updated with the new data file path
after crash recovery. (Bug #17448389)
* InnoDB: The server could fail to restart if a crash occurred
immediately following a RENAME TABLE in an ALTER TABLE, RENAME
TABLE sequence. (Bug #17463290)
* InnoDB: If the first page (page 0) of file-per-table
tablespace data file was corrupt, recovery would be halted
even though the doublewrite buffer contained a clean copy of
the page. (Bug #17335427, Bug #70087)
* InnoDB: The InnoDB memcached Readme file
(README-innodb_memcached) incorrectly stated that libevent
1.6.0 is linked statically into daemon memcached. The bundled
version of libevent is 1.4.12, not 1.6.0. (Bug #17324419, Bug
#70034)
* InnoDB: Attempting to reset a replication slave while
innodb_force_recovery is greater than 0 would return a cryptic
error message: ERROR(1030) HY000: Got error -1 from storage
engine. The error message has been changed to: ERROR HY000:
Operation not allowed when innodb_force_recovery > 0.
Replication options such as --relay-log-info-repository=TABLE
and --master-info-repository=TABLE store information in tables
in InnoDB. When innodb_force_recovery is greater than 0,
replication tables cannot be updated which may cause
replication administration commands to fail. (Bug #17287443,
Bug #69907)
* InnoDB: When creating a table there are a minimum of three
separate inserts on the mysql.innodb_index_stats table. To
improve CREATE TABLE performance, there is now a single COMMIT
operation instead of one for each insert. (Bug #17323202, Bug
#70063)
* InnoDB: The server would halt with an assertion in
lock_rec_has_to_wait_in_queue(lock) due to a locking-related
issue and a transaction being prematurely removed from
trx_sys->rw_trx_set. (Bug #17320977)
* InnoDB: The ALTER TABLE INPLACE algorithm would fail to
decrease the auto-increment value. (Bug #17250787, Bug #69882)
* InnoDB: Comments in btr0cur.cc incorrectly stated that
btr_cur_pessimistic_update() and btr_cur_optimistic_update()
would accept a NULL value. (Bug #17231743, Bug #69847)
* InnoDB: dict_table_schema_check would call dtype_sql_name
needlessly. (Bug #17193801, Bug #69802)
* InnoDB: The function os_file_get_status would not work with
raw devices. (Bug #17023438, Bug #69424)
* InnoDB: fil_check_first_page() failed to check if
fsp_flags_get_zip_size() returned a valid value, which
resulted in a segmentation fault when starting mysqld. (Bug
#17033182)
* InnoDB: The lock_rec_other_has_expl_req function in
lock0lock.cc would perform unnecessary work. (Bug #17016214,
Bug #69576)
* InnoDB: Valgrind would report uninitialized values while
running a rollback debug test. The Valgrind warnings should
only appear in Valgrind-instrumented builds. (Bug #16969876)
* InnoDB: During crash recovery, an incorrect transaction active
time would result in rolling back an uncommitted transaction.
(Bug #16936961, Bug #69438)
* InnoDB: Heap block debugging information (file_name, lineno),
used for logging diagnostics, would appear in release builds.
This information should only appear in debug builds. (Bug
#16924719, Bug #69422)
* InnoDB: Renaming a column while also adding or dropping
columns in the same ALTER TABLE operation would cause an
error. (Bug #16864981)
* InnoDB: An online ALTER TABLE operation would consume more
memory than expected. During an online ALTER TABLE operation,
an online log buffer containing a head and tail buffer is
created for each index that is created or rebuilt. The tail
buffer is the writer context and is only required for
concurrent write operations on an index while the ALTER TABLE
operation is in progress. The head buffer is the reader
context and is only required during the log apply phase. To
reduce memory consumption, the tail buffer is now allocated
when the first DML statement is run on the index, and the head
buffer is only allocated in the log apply phase and freed
afterwards. (Bug #16868967, Bug #69325, Bug #17911720)