[Due to size limitations, the announcement is split in 2. This is part 1.]

Dear MySQL users,

MySQL Server 8.0.3-rc (Release Candidate) is a new version of the world's
most popular open source database. This is the first release candidate
of MySQL 8.0.

http://dev.mysql.com/doc/mysql-development-cycle/en/development-milestone-releases.html

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

Note that 8.0.3-rc includes all features in MySQL 5.7.

For information on installing MySQL 8.0.3-rc on new servers, please see
the MySQL installation documentation at

http://dev.mysql.com/doc/refman/8.0/en/installing.html

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

http://dev.mysql.com/downloads/mysql/

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

http://dev.mysql.com/downloads/repo/

Windows packages are available via the Installer for Windows:

http://dev.mysql.com/downloads/installer/

along with .ZIP (no-install) packages for more advanced needs.

8.0.3-rc also comes with a web installer as an alternative to the full
installer.

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

http://bugs.mysql.com/report.php

The following link lists the changes in the MySQL 8.0 since
the release of MySQL 8.0.2. It may also be viewed
online at

http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-3.html

Enjoy!


=============================================================================Changes in MySQL 8.0.3 (2017-09-21, Release Candidate)

Note

This is a milestone release, for use at your own risk.
Upgrades between milestone releases (or from a milestone
release to a GA release) are not supported. 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.

* C API Notes

* Character Set Support

* Compilation Notes

* Configuration Notes

* Data Dictionary Notes

* Deprecation and Removal Notes

* InnoDB Notes

* Optimizer Notes

* Packaging Notes

* Performance Schema Notes

* Security Notes

* Spatial Data Support

* SQL Syntax Notes

* X Plugin Notes

* Functionality Added or Changed

* Bugs Fixed

C API Notes

* The MySQL C API now enables clients to specify that
metadata transfer for result sets is optional.
Suppression of metadata transfer can improve performance,
particularly for sessions that execute many queries that
return few rows each. For more information, see C API
Optional Result Set Metadata
(http://dev.mysql.com/doc/refman/8.0/en/c-api-optional-metadata.html).

Character Set Support

* MySQL now supports Russian collations for the utf8mb4
Unicode character set:

+ utf8mb4_ru_0900_ai_ci is accent insensitive and case
insensitive.

+ utf8mb4_ru_0900_as_cs is accent sensitive and case
sensitive.

Compilation Notes

* For debug builds, the SAFE_MUTEX compilation flag was
disabled if the memcached plugin was included in the
build. This no longer occurs; SAFE_MUTEX is always
enabled for debug builds. Some code issues found as a
result of this change were corrected. (Bug #26442367, Bug
#87068)

* Binary packages on EL6 and EL7 now are compiled using
Devtoolset 6 rather than Devtoolset3 and GCC 6.2.1 rather
than 4.9.2. (Bug #26436968, Bug #87061)

* MySQL now compiles for SPARC on Oracle Linux. (Bug
#26306331, Bug #86745)

* MySQL compilation on macOS using Clang now requires a
Clang version different from 8.0, which has problems with
certain inline constructs. (Bug #26279510, Bug #86711)

* Work was done to clean up the source code base,
including: Removing unneeded CMake checks; removing
unused macros from source files; reorganizing header
files to reduce the number of dependencies and make them
more modular, removing function declarations without
definitions, replacing locally written functions with
equivalent functions from industry-standard libraries.

Configuration Notes

* The performance_schema_max_mutex_classes system variable
default value was increased from 220 to 250. The
performance_schema_max_thread_classes system variable
default value was increased from 50 to 100. (Bug
#26193630)

* The new cte_max_recursion_depth system variable
implements a common table expression (CTE) maximum
recursion depth. The server terminates execution of any
CTE that recurses more levels than the value of this
variable. For more information, see Limiting Common Table
Expression Recursion
(http://dev.mysql.com/doc/refman/8.0/en/with.html#common-table-expressions-recursion-limits).
(Bug #26136509, Bug #86444)

* The back_log system variable default value is now the
value of max_connections, which enables the permitted
backlog to adjust to the maximum permitted number of
connections.

* To enable the Event Scheduler by default, the
event_scheduler system variable default value was changed
from OFF to ON.

* The max_allowed_packet system variable default value was
increased from 4194304 (4M) to 67108864 (64M).

* The max_error_count system variable default variable was
increased from 64 to 1024.

Data Dictionary Notes

* These INFORMATION_SCHEMA tables have been reimplemented
as views on data dictionary tables:
FILES
PARTITIONS
REFERENTIAL_CONSTRAINTS

Queries on those tables are now more efficient because
they obtain information from data dictionary tables
rather than by other, slower means. For example, the
server no longer must create a temporary table for each
query of the INFORMATION_SCHEMA table.
Also as a result of this change, foreign key information
is retrieved from the data dictionary, not from InnoDB.
If you upgrade to this MySQL release from an earlier
version, you must run mysql_upgrade (and restart the
server) to incorporate these changes. (Bug #25583288)

* Crash safety was improved for CREATE and DROP operations,
and, if applicable, ALTER operations for stored programs
(other than triggers), views, and user-defined functions
(UDFs). The exception for triggers is made because
trigger operations are already atomic. A behavior change
for DROP VIEW occurs if any named views do not exist.
Previously, the statement returned an error indicating
which views did not exist and it was unable to drop, but
also dropped the views that did exist. Now the statement
still indicates which views did not exist, but fails with
an error and no changes are made.

Deprecation and Removal Notes

* Replication: The deprecated global scope for the
sql_log_bin system variable has been removed. sql_log_bin
now has session scope only. Applications that rely on
accessing @@global.sql_log_bin should be adjusted.

* These encryption-related deprecated items have been
removed:

+ The ENCODE() and DECODE() functions.

+ The ENCRYPT function.

+ The DES_ENCRYPT(), and DES_DECRYPT() functions, the
--des-key-file option, the have_crypt system
variable, the DES_KEY_FILE option for the FLUSH
statement, and the HAVE_CRYPT CMake option.
In place of the removed encryption functions, consider
using AES_ENCRYPT() and AES_DECRYPT() instead. (Bug
#26493987)

* The deprecated tx_isolation and tx_read_only system
variables have been removed. Use transaction_isolation
and transaction_read_only instead.

* The deprecated query cache has been removed. Removal
includes these items:

+ The FLUSH QUERY CACHE and RESET QUERY CACHE
statements.

+ These system variables: query_cache_limit,
query_cache_min_res_unit, query_cache_size,
query_cache_type, query_cache_wlock_invalidate.

+ These status variables: Qcache_free_blocks,
Qcache_free_memory, Qcache_hits, Qcache_inserts,
Qcache_lowmem_prunes, Qcache_not_cached,
Qcache_queries_in_cache, Qcache_total_blocks.

+ These thread states: checking privileges on cached
query, checking query cache for query, invalidating
query cache entries, sending cached result to
client, storing result in query cache, Waiting for
query cache lock.
These deprecated query cache items remain deprecated, but
have no effect, and will be removed in a future MySQL
release:

+ The SQL_CACHE and SQL_NO_CACHE SELECT modifiers.

+ The ndb_cache_check_time system variable.
The have_query_cache system variable remains deprecated,
always has a value of NO, and will be removed in a future
MySQL release.

* The deprecated EXTENDED and PARTITIONS keywords for the
EXPLAIN statement have been removed. These keywords are
unnecessary because their effect is always enabled.

* The unused date_format, datetime_format, time_format, and
max_tmp_tables system variables have been removed.

* The deprecated multi_range_count system variable has been
removed.

* The deprecated log_warnings system variable and
--log-warnings server option have been removed. Use the
log_error_verbosity system variable instead.

* The deprecated secure_auth system variable and
--secure-auth client option have been removed. The
MYSQL_SECURE_AUTH option for the mysql_options() C API
function was removed.

* The deprecated --ignore-builtin-innodb server option and
ignore_builtin_innodb system variable have been removed.

InnoDB Notes

* Renaming of columns in a parent foreign key is
temporarily disabled due to ongoing work on foreign key
locking. This restriction will be lifted in MySQL 8.0.4.
(Bug #26334071)
References: See also: Bug #26659110.

Optimizer Notes

* The optimizer now supports a SET_VAR hint that sets the
session value of a system variable for the duration of a
single statement. Examples:
SELECT /*+ SET_VAR(sort_buffer_size = 16M) */ name FROM people ORDER B
Y name;
INSERT /*+ SET_VAR(foreign_key_checks=OFF) */ INTO t2 VALUES(2);

For more information, see Optimizer Hints
(http://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html).

* The optimizer now uses column-value histogram statistics
stored in the column_statistics data dictionary table to
construct query execution plans. Histogram use applies to
predicates involving comparison of a column to a
constant. See Optimizer Statistics
(http://dev.mysql.com/doc/refman/8.0/en/optimizer-statistics.html).

* Previously, there was no way of skipping the use of index
dives to estimate index usefulness, except by using the
eq_range_index_dive_limit system variable. Now index dive
skipping is possible for single-table queries under
certain query conditions (see Range Optimization
(http://dev.mysql.com/doc/refman/8.0/en/range-optimization.html)).

* The optimizer_switch system variable has a new flag named
use_invisible_indexes to control whether the optimizer
uses invisible indexes for query execution plan
construction. If the flag is off (the default), the
optimizer ignores invisible indexes (the same behavior as
prior to the introduction of this flag). If the flag is
on, invisible indexes remain invisible but the optimizer
takes them into account for execution plan construction.

Packaging Notes

* mysqlcheck was missing in the MySQL Server Docker image,
which prevented mysql_upgrade from running. (Bug
#26400146, Bug #86968)

* For Debian, non-debug binaries were moved from the
mysql-server package to the mysql-server-core package.
(Bug #26382333)

* The Debian/Ubuntu mysql-community-source package is no
longer produced because the MySQL source tarball it
contained is provided by other packages at dev.mysql.com.
(Bug #26201482)

Performance Schema Notes

* As of MySQL 8.0.2, Performance Schema table definitions
are maintained internally to the server. In consequence
of that change, CREATE TABLE and DROP TABLE are no longer
possible for Performance Schema tables. (Bug #26136994)

* The events_statements_summary_by_digest table now
provides, for each row, a sample statement that produces
the digest value in the row. Applications can use this
information as a more efficient means of capturing
statement samples than alternatives such as probing the
xxx_history_long tables. The latter approach requires
enabling the corresponding xxx_history_long consumers,
which is additional overhead for applications that do not
otherwise need those tables. For more information, see
Performance Schema Statement Digests and Sampling
(http://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-digests.html),
and Statement Summary Tables
(http://dev.mysql.com/doc/refman/8.0/en/statement-summary-tables.html).
Additionally, the FIRST_SEEN and LAST_SEEN timestamp
columns of the events_statements_summary_by_digest table
now have a fractional seconds part.

* The Performance Schema setup_instruments table now has
columns for instrument metadata: Instrument properties,
instrument volatility, and a documentation string
describing the the instrument purpose. Also, the TIMED
column now can be NULL, indicating that the instrument
does not support timing. See The setup_instruments Table
(http://dev.mysql.com/doc/refman/8.0/en/setup-instruments-table.html).
The new Performance Schema setup_threads table exposes
instrumented thread class names and attributes. See The
setup_threads Table
(http://dev.mysql.com/doc/refman/8.0/en/setup-threads-table.html).

Security Notes

* A new caching_sha2_password authentication plugin is
available. Like the sha256_password plugin,
caching_sha2_password implements SHA-256 password
hashing, but uses caching to address latency issues at
connect time. It also supports more connection protocols
and does not require linking against OpenSSL for RSA
password-exchange capabilities. See SHA-2 Pluggable
Authentication
(http://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authentication.html).

* MySQL now maintains information about password history,
enabling DBAs to require that new passwords not reuse old
ones for some number of password changes or period of
time. It is possible to establish password-reuse policy
globally using the password_history and
password_reuse_interval system variables, as well as on a
per-account basis using the CREATE USER and ALTER USER
statements. Together with existing password-expiration
capabilities to require that passwords be changed
periodically, the new password-history capabilities
provide DBAs more complete control over password
management. For more information, see Password Management
(http://dev.mysql.com/doc/refman/8.0/en/password-management.html).
Important
MySQL implements password-reuse restrictions by means of
new columns in the mysql.user system table and a new
mysql.password_history system table. If you upgrade to
this MySQL release from an earlier version, you must run
mysql_upgrade (and restart the server) to incorporate
these system database changes. Until this is done,
password changes will not be possible.

* If the server is started with the --skip-grant-tables
option to disable authentication checks, the server now
enables --skip-networking to prevent remote connections.

Spatial Data Support

* Incompatible Change: Previously, these functions that
test geometry relationships supported only Cartesian
spatial reference systems (SRSs): ST_Contains(),
ST_Crosses(), ST_Disjoint(), ST_Equals(),
ST_Intersects(), ST_Overlaps(), ST_Touches(),
ST_Within(), MBRContains(), MBRCoveredBy(), MBRCovers(),
MBRDisjoint(), MBREquals(), MBRIntersects(),
MBROverlaps(), MBRTouches(), MBRWithin().
These functions now detect geometry arguments in a
geographic (ellipsoidal) SRS and return geographic
results. Calculations for projected SRSs and SRID 0
remain the same. For more information, see Spatial
Relation Functions That Use Object Shapes
(http://dev.mysql.com/doc/refman/8.0/en/spatial-relation-functions-object-shapes.html),
and Spatial RelationFunctions That Use Minimum Bounding Rectangles
(http://dev.mysql.com/doc/refman/8.0/en/spatial-relation-functions-mbr.html).
Note
If spatial data contains SRID values that refer to a
geographic spatial reference system, existing queries
using these functions will return different results,
compared to previous MySQL versions.

* InnoDB: Spatial reference identifier (SRID) support was
added for InnoDB spatial indexes.

* Spatial data types now permit an SRID attribute, to
explicitly indicate the spatial reference system (SRS)
for values stored in the column. See Spatial Data Types
(http://dev.mysql.com/doc/refman/8.0/en/spatial-datatypes.html).
To indicate each column's SRID attribute value, if there
is one, the INFORMATION_SCHEMA.COLUMNS table now has an
SRS_ID column.
A spatial column with an explicit SRID attribute is
SRID-restricted: The column takes only values with that
ID, and SPATIAL indexes on the column become subject to
use by the optimizer. The optimizer ignores SPATIAL
indexes on spatial columns with no SRID attribute. See
SPATIAL Index Optimization
(http://dev.mysql.com/doc/refman/8.0/en/spatial-index-optimization.html).

SQL Syntax Notes

* ALTER TABLE now supports easier column renaming using
RENAME COLUMN old_name TO new_name syntax. See ALTER
TABLE Syntax
(http://dev.mysql.com/doc/refman/8.0/en/alter-table.html).
For changing a column name but not its definition,
RENAME COLUMN is more convenient than CHANGE, which
requires respecifying the current column definition. With
CHANGE, you must look up the definition if you do not
know it, and if you do not respecify it exactly, there is
a possibility of data change or loss. (Bug #11746522, Bug
#26949, Bug #11747473, Bug #32497, Bug #11765084, Bug
#58006, Bug #14031617)

X Plugin Notes

* The X Plugin could not be installed when the server was
started with the --skip-grant-tables option. (Bug
#26516678)

* X Plugin socket connections were not working correctly.
(Bug #26427112, Bug #87019)

* When compiling MySQL from source, certain infrequently
used CMake arguments caused issues for the X Plugin
build. (Bug #26141933)

* A Mysqlx.Connection.CapabilitiesGet request using MySQL X
Protocol did not return the complete list of available
authentication mechanisms. (Bug #26044113)

* For mixed case or uppercase schema names, the statement
list_objects could incorrectly report a collection as a
table. (Bug #25769683)

* The X Plugin was omitted from the list of plugins to
include for testing data directory permissions. (Bug
#24823999)

Functionality Added or Changed

* InnoDB: InnoDB now supports atomic DDL, which ensures
that DDL operations are either committed in their
entirety or rolled back in case of an unplanned server
stoppage.
This feature applies to the following statements:

+ ALTER TABLE

+ CREATE INDEX

+ CREATE TABLE

+ CREATE TABLESPACE

+ DROP INDEX

+ DROP TABLE

+ DROP TABLESPACE

+ RENAME TABLE

+ TRUNCATE TABLE
Recovery logs for atomic DDL operations are written to
the mysql.innodb_ddl_log data dictionary table. Enabling
the innodb_print_ddl_logs configuration option prints DDL
recovery logs to the error log.
The introduction of atomic DDL prevents orphan temporary
or intermediate tables from being left behind by failed
ALTER TABLE operations. (Bug #24620918)

* InnoDB: A new type of backup lock permits DML on InnoDB
tables during an online backup while preventing
operations on InnoDB files that could result in an
inconsistent snapshot. The new backup lock is supported
by LOCK INSTANCE FOR BACKUP and UNLOCK INSTANCE syntax.
The BACKUP_ADMIN privilege is required to use these
statements.

* InnoDB: The new innodb_dedicated_server configuration
option, which is disabled by default, causes InnoDB to
automatically configure the following options according
to the amount of memory detected on the server:

+ innodb_buffer_pool_size

+ innodb_log_file_size

+ innodb_flush_method
This option is intended for MySQL server instances that
run on a dedicated server. For more information, see
Enabling Automatic Configuration for a Dedicated MySQL
Server
(http://dev.mysql.com/doc/refman/8.0/en/innodb-dedicated-server.html).

* InnoDB: Renaming a general tablespace is now supported by
ALTER TABLESPACE ... RENAME TO syntax.
The ALTER TABLESPACE and DROP TABLESPACE ENGINE clause is
deprecated and will be removed in a future release.

* InnoDB: Code related to obsoleted InnoDB system tables
was removed. INFORMATION_SCHEMA views based on InnoDB
system tables were replaced by internal system views on
data dictionary tables. Affected InnoDB
INFORMATION_SCHEMA views were renamed:
Table 1 Renamed InnoDB Information Schema Views

Old Name New Name
INNODB_SYS_COLUMNS INNODB_COLUMNS
INNODB_SYS_DATAFILES INNODB_DATAFILES
INNODB_SYS_FIELDS INNODB_FIELDS
INNODB_SYS_FOREIGN INNODB_FOREIGN
INNODB_SYS_FOREIGN_COLS INNODB_FOREIGN_COLS
INNODB_SYS_INDEXES INNODB_INDEXES
INNODB_SYS_TABLES INNODB_TABLES
INNODB_SYS_TABLESPACES INNODB_TABLESPACES
INNODB_SYS_TABLESTATS INNODB_TABLESTATS
INNODB_SYS_VIRTUAL INNODB_VIRTUAL
After upgrading to MySQL 8.0.3 or later, update any
scripts that reference previous InnoDB INFORMATION_SCHEMA
view names.
INNODB_TABLESPACES_BRIEF, a new INFORMATION_SCHEMA view,
provides space, name, path, flag, and space type data for
InnoDB tablespaces.

* InnoDB: When InnoDB was integrated with the global data
dictionary, file-per-table tablespace names in the data
dictionary were created in the form of
innodb_file_per_table_x, where x is the InnoDB tablespace
ID. For ease of use, file-per-table tablespace names in
the data dictionary are once again the same as the table
name.
Upgrade from MySQL 5.7 to MySQL 8.0 appends MySQL 5.7
innodb_table_stats and innodb_index_stats tabelspace
names in the data dictionary with "_backup57" to
differentiate them from their MySQL 8.0 counterparts.

* InnoDB: The default innodb_autoinc_lock_mode setting was
changed from 1 (consecutive) to 2 (interleaved).
Interleaved lock mode permits the execution of multi-row
inserts in parallel, which improves concurrency and
scalability. The new innodb_autoinc_lock_mode default
setting reflects the change from statement-based
replication to row based replication as the default
replication type in MySQL 5.7. Statement-based
replication requires the consecutive auto-increment lock
mode to ensure that auto-increment values are assigned in
a predictable and repeatable order for a given sequence
of SQL statements, whereas row-based replication is not
sensitive to the execution order of SQL statements. For
more information, see InnoDB AUTO_INCREMENT Lock Modes
(http://dev.mysql.com/doc/refman/8.0/en/innodb-auto-increment-handling.html#innodb-auto-increment-lock-modes).
For systems that use statement-based replication, the new
innodb_autoinc_lock_mode default setting may break
applications that depend on sequential auto-increment
values. To restore the previous default, set
innodb_autoinc_lock_mode to 1.

* InnoDB: Serialized Dictionary Information (SDI) is now
present in all InnoDB tablespace files except for
temporary tablespace and undo tablespace files. SDI is
serialized metadata for schema, table, and tablespace
objects. The presence of SDI data provides metadata
redundancy. For example, dictionary object metadata may
be extracted from tablespace files if the data dictionary
becomes unavailable. SDI extraction is performed using
the ibd2sdi tool. SDI data is stored in JSON format.
The inclusion of SDI data in tablespace files increases
tablespace file size. An SDI record requires a single
index page, which is 16k in size by default. However, SDI
data is compressed when it is stored to reduce the
storage footprint.

* InnoDB: The innodb_flush_neighbors default value was
changed from 1 to 0, which disables flushing of
neighboring pages from the buffer pool. A setting of 0 is
optimal for non-rotational storage (SSD) devices where
seek time is not a significant factor. For systems that
use rotational storage (HDD), it is recommended to change
the setting back to the previous default value of 1.

* InnoDB: Default values for configuration options that
affect buffer pool preflushing and flushing behavior were
modified:

+ The innodb_max_dirty_pages_pct_lwm default value was
changed to 10. The previous default value of 0
disables buffer pool preflushing. A value of 10
enables preflushing when the percentage of dirty
pages in the buffer pool exceeds 10%. Enabling
preflushing improves performance consistency.

+ The innodb_max_dirty_pages_pct default value was
changed from 75 to 90. InnoDB attempts to flush data
from the buffer pool so that the percentage of dirty
pages does not exceed this value. The increased
default value permits a greater percentage of dirty
pages in the buffer pool.

* InnoDB: The minimum innodb_undo_tablespaces value changed
from 0 to 2. In previous releases, the system tablespace
is used for rollback segments if innodb_undo_tablespaces
is set to 0. A minimum value of 2 ensures that rollback
segments are created in undo tablespaces instead of the
system tablespace. For more information about undo
tablespaces, see Configuring Undo Tablespaces
(http://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespace.html).

* Replication; JSON: Added the binlog_row_value_options
system variable. Currently this variable can be unset, or
set to the value PARTIAL_JSON. This causes MySQL's
row-based replication to use a compact binary log format
for each update modifying only a small portion of a JSON
document and using any combination of JSON_SET(),
JSON_REPLACE(), and JSON_REMOVE(). The compact format
includes only the modified parts of the JSON document,
not the full document, in the after-image used for the
update in the binary log. If the modification requires
more space than the full document, or if it is not
possible to generate a partial update, the full document
is used instead.
See the description of the variable as well as Partial
Updates of JSON Values
(http://dev.mysql.com/doc/refman/8.0/en/json.html#json-partial-updates),
for more information.

* Replication: The IGNORE_SERVER_IDS option of the CHANGE
MASTER TO statement is now deprecated when using
GTID-based replication (gtid_mode=ON). With GTIDs,
transactions that have already been applied are
automatically ignored, so this function is not needed.
Before starting GTID-based replication, check for and
clear all ignored server ID lists that have previously
been set on the servers involved. The SHOW_SLAVE_STATUS
statement, which can be issued for individual channels,
displays the list of ignored server IDs if there is one.
If there is no list, the Replicate_Ignore_Server_Ids
field is blank.
If gtid_mode=ON is set for the server, a deprecation
warning is now issued if you include the
IGNORE_SERVER_IDS option in a CHANGE MASTER TO statement.
A deprecation warning is also issued if you issue a SET
GTID_MODE=ON statement when any channel has existing
server IDs set with IGNORE_SERVER_IDS. If you do receive
the deprecation warning, you can still clear a list after
gtid_mode=ON is set by issuing a CHANGE MASTER TO
statement containing the IGNORE_SERVER_IDS option with an
empty list.

* Replication: The following obsolete mysqlbinlog options
are now deprecated and will be removed in a future
release:

+ --short-form, which could be used for testing to
limit the output to statements alone.

+ --stop-never-slave-server-id, which provided a
server ID for connections using the --stop-never
option. If you require this function, use the
--connection-server-id option instead.
The deprecation warnings for these options are sent to
standard error, rather than to standard output, so that
they do not interfere with the operation of tools that
use the output of mysqlbinlog.

* Replication: The log_slave_updates system variable is now
set to ON by default, so you do not need to specify
--log-slave-updates explicitly when you start a
replication slave.
The log_slave_updates system variable is read-only. If
you need to prevent a replication slave from logging the
updates performed by its SQL thread to its own binary
log, specify --skip-log-slave-updates when you start the
slave, or specify log_slave_updates=OFF in the
configuration file for the slave.

* Replication: The Group Replication thread states are now
shown in the Performance Schema tables.

* Replication: The
group_replication_communication_debug_options variable
has been added which enables you to dynamically filter
out debugging and tracing messages per Group Replication
component, such as GCS, XCOM, and so on. (Bug #10200)

* JSON: The JSON_MERGE() function is renamed to
JSON_MERGE_PRESERVE().
This release also adds the JSON_MERGE_PATCH() function,
an RFC 7396 compliant version of JSON_MERGE_PRESERVE();
its behavior is the same as that of
JSON_MERGE_PRESERVE(), except that JSON_MERGE_PATCH()
removes any member in the first object with a matching
key in the second object, provided that the value
associated with the key in the second object is not JSON
null. This example compares the results of merging the
same 3 JSON objects, each having a matching key "a", with
each of these functions:
mysql> SET @x = '{ "a": 1, "b": 2 }',
> @y = '{ "a": 3, "c": 4 }',
> @z = '{ "a": 5, "d": 6 }';

mysql> SELECT JSON_MERGE_PRESERVE(@x, @y, @z) AS Preserve,
-> JSON_MERGE_PATCH(@x, @y, @z) AS Patch\G
*************************** 1. row ***************************
Preserve: {"a": [1, 3, 5], "b": 2, "c": 4, "d": 6}
Patch: {"a": 5, "b": 2, "c": 4, "d": 6}

JSON_MERGE() is still supported as an alias of
JSON_MERGE_PRESERVE(), but is now deprecated and subject
to removal in a future MySQL release.
See Functions That Modify JSON Values
(http://dev.mysql.com/doc/refman/8.0/en/json-modification-functions.html),
for more information. (Bug #81283, Bug #23255346)

* InnoDB now uses Variance-Aware Transaction Scheduling
(VATS) for scheduling the release of transaction locks
when the system is highly loaded, which helps reduce lock
sys wait mutex contention. Lock scheduling uses VATS when
>= 32 threads are suspended in the lock wait queue.
For more information about Variance-Aware Transaction
Scheduling (VATS), see Identifying the Major Sources of
Variance in Transaction Latencies: Towards More
Predictable Databases
(https://arxiv.org/pdf/1602.01871.pdf).
Thanks to Jiamin Huang for the contribution. (Bug
#25290971, Bug #84266)

* The binary log is now enabled by default at server
startup. The log_bin system variable is set to ON by
default, instead of OFF, even if the --log-bin option has
not been specified. Binary logging is standard practice
for production installations, so enabling it by default
removes configuration and planning steps that were
usually required.
To enable the server to start with log_bin = ON, the
server_id system variable is now set to 1 by default,
instead of 0. For servers in a replication topology, you
must still change this setting to specify a unique server
ID for each replication server. Previously, the server
could not start with log_bin = ON if no server ID was
specified. Now, the server can start, but a warning
message is issued if you did not set an explicit server
ID.
With binary logging enabled for a server, all statements
that change data are logged to the server's binary log,
which is a sequence of files with a base name and numeric
extension. By default, the server creates binary log
files and an index file in the data directory, with base
names of host_name-bin.xxxxxx and host_name-bin.index,
using the value of the pid-file option, which by default
is the name of the host machine. You can choose the names
and locations of the files by specifying the --log-bin
and --log-bin-index options. You are recommended to
specify a base name explicitly, so that if the host name
changes, you can easily continue to use the same binary
log file names. The log_bin_basename system variable
holds the base name and any specified path for the binary
log files.
The relay log and relay log index on a replication slave,
whose names are specified by the --relay-log and
--relay-log-index options, cannot be given the same names
as the binary log and binary log index. From MySQL 8.0.3,
the server issues an error message and does not start if
the binary log and relay log file base names would be the
same.
The server creates a new binary log file in the series
each time it starts or flushes the logs. The server also
creates a new binary log file automatically after the
current file's size reaches max_binlog_size, which
defaults to the maximum permitted value of 1GB. In MySQL
8.0.3, binary log files expire by default after 30 days,
and can then be automatically removed at startup or when
the binary log is flushed. You can purge binary log files
manually using the PURGE BINARY LOGS statement, or
specify a different binary log expiration period using
the binlog_expire_logs_seconds system variable.
Many other options are available to modify the behavior
of binary logging. For more information, see The Binary
Log
(http://dev.mysql.com/doc/refman/8.0/en/binary-log.html)
and Binary Logging Options and Variables
(http://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html).
To disable binary logging, you can specify the
--skip-log-bin or --disable-log-bin option at startup. If
either of these options is specified and --log-bin is
also specified, the option specified later takes
precedence. If you disable binary logging, you must also
specify --skip-log-slave-updates, as the
--log-slave-updates option is enabled by default from
MySQL 8.0.3 and requires binary logging. If you use
mysqld to initialize the data directory manually by
invoking it with the --initialize or
--initialize-insecure option, binary logging is disabled
by default, but can be enabled by specifying the
--log-bin option with or without a base name.
References: See also: Bug #26730000.

* The expire_logs_days system variable, which specifies the
binary log expiration period in days, is now deprecated
and will be removed in a future release. expire_logs_days
does not provide sufficient flexibility for defining the
binary log expiration period.
binlog_expire_logs_seconds can be used to set the binary
log expiration period in seconds. In MySQL 8.0.3, the
effects of the two variables are currently cumulative.
For example, if expire_logs_days is 1 and
binlog_expire_logs_seconds is 43200, then the binary log
is purged every 1.5 days. This produces the same result
as setting binlog_expire_logs_seconds to 129600 and
expire_logs_days to 0. Note that the default
expire_logs_days setting of 30 days is currently added to
the binary log expiration period if expire_logs_days is
not specified. To use binlog_expire_logs_seconds alone,
set expire_logs_days=0 explicitly.
To disable automatic purging of the binary log, you must
set both expire_logs_days and binlog_expire_logs_seconds
explicitly to 0.
References: See also: Bug #26483363.

* The new get_sysvar_source plugin service enables plugins
to retrieve the source of system variable settings.

* The zlib library version bundled with MySQL was raised
from version 1.2.3 to version 1.2.11. MySQL implements
compression with the help of the zlib library.
The zlib compressBound() function in zlib 1.2.11 returns
a slightly higher estimate of the buffer size required to
compress a given length of bytes than it did in zlib
version 1.2.3. The compressBound() function is called by
InnoDB functions that determine the maximum row size
permitted when creating compressed InnoDB tables or
inserting rows into compressed InnoDB tables. As a
result, CREATE TABLE ... ROW_FORMAT=COMPRESSED or INSERT
operations with row sizes very close to the maximum row
size that were successful in earlier releases could now
fail.
If you have compressed InnoDB tables with large rows, it
is recommended that you test compressed table CREATE
TABLE statements on a MySQL 8.0.3 test instance prior to
upgrading.

* In MySQL 8.0.2, the system variables for the slave status
logs, master_info_repository and
relay_log_info_repository, were set to TABLE instead of
FILE by default. In MySQL 8.0.3, the FILE setting for
both these system variables is deprecated, and a warning
is issued if it is used. The FILE setting will be removed
in a future release.
The TABLE setting ensures that replication repository
information is stored in InnoDB tables, rather than in
files in the data directory. The use of tables makes
replication resilient to unexpected halts.
The default names for the slave status logs when stored
as files were master.info and relay-log.info. The names
could be changed using the --master-info-file and
--relay-log-info-file options, respectively. As InnoDB
tables, the slave status logs are named
mysql.slave_master_info and mysql.slave_relay_log_info.
To modify an existing replication slave that is using a
FILE repository for the slave status logs to use TABLE
repositories, convert the existing replication
repositories dynamically by running the following
commands:

STOP SLAVE;
SET GLOBAL master_info_repository = 'TABLE';
SET GLOBAL relay_log_info_repository = 'TABLE';

The master info log table mysql.slave_master_info should
be protected because it contains the password for
connecting to the master. When you back up the
replication slave's data, ensure that you back up the
mysql.slave_master_info and mysql.slave_relay_log_info
tables containing the slave status logs, because they are
needed to resume replication after you restore the data
from the slave.

[ to be continued ]

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql