Web lists-archives.com

MySQL Community Server 8.0.3-rc has been released (part 1/2)

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


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


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


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


Windows packages are available via the Installer for Windows:


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

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

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


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



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


   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

   Character Set Support

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

          + utf8mb4_ru_0900_ai_ci is accent insensitive and case

          + utf8mb4_ru_0900_as_cs is accent sensitive and case

   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

     * 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

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

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

       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

          + 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

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


          + 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

          + 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

     * 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

     * 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

     * 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

     * 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
       and Statement Summary Tables
       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
       The new Performance Schema setup_threads table exposes
       instrumented thread class names and attributes. See The
       setup_threads Table

   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

     * 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
       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
       and Spatial RelationFunctions That Use Minimum Bounding Rectangles
       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
       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

   SQL Syntax Notes

     * ALTER TABLE now supports easier column renaming using
       RENAME COLUMN old_name TO new_name syntax. See ALTER
       TABLE Syntax
       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

     * 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

   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
       This feature applies to the following statements:

          + ALTER TABLE

          + CREATE INDEX

          + CREATE TABLE


          + DROP INDEX

          + DROP TABLE


          + 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
       The BACKUP_ADMIN privilege is required to use these

     * 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

     * InnoDB: Renaming a general tablespace is now supported by
       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
       After upgrading to MySQL 8.0.3 or later, update any
       scripts that reference previous InnoDB INFORMATION_SCHEMA
       view names.
       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
       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
       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

          + 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

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

          + --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
       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
       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
       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
       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
       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
       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
       and Binary Logging Options and Variables
       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
       operations with row sizes very close to the maximum row
       size that were successful in earlier releases could now
       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

     * 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

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