MySQL Community Server 8.0.21 has been released (part 1/2)
Posted by: Bjørn Munch
Date: July 13, 2020 05:42AM
Date: July 13, 2020 05:42AM
[ Due to size limitations, this post has been split in two. This is part 1. ]
Dear MySQL users,
MySQL Server 8.0.21, a new version of the popular Open Source
Database Management System, has been released. MySQL 8.0.21 is
recommended for use on production systems.
For an overview of what's new in MySQL 8.0, please see
http://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html
For information on installing MySQL 8.0.21 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.21 is available in source and binary form for a number of
platforms from our download pages at
http://dev.mysql.com/downloads/mysql/
MySQL Server 8.0.21 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.21 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.
Downgrade from MySQL 8.0 to MySQL 5.7, or from a MySQL 8.0 release to
a previous MySQL 8.0 release, is not supported. The only supported
alternative is to restore a backup taken before upgrading. It is
therefore imperative that you back up your data before starting the
upgrade process.
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.20. It may also be viewed
online at
http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-21.html
Enjoy!
==============================================================================
Dear MySQL users,
MySQL Server 8.0.21, a new version of the popular Open Source
Database Management System, has been released. MySQL 8.0.21 is
recommended for use on production systems.
For an overview of what's new in MySQL 8.0, please see
http://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html
For information on installing MySQL 8.0.21 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.21 is available in source and binary form for a number of
platforms from our download pages at
http://dev.mysql.com/downloads/mysql/
MySQL Server 8.0.21 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.21 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.
Downgrade from MySQL 8.0 to MySQL 5.7, or from a MySQL 8.0 release to
a previous MySQL 8.0 release, is not supported. The only supported
alternative is to restore a backup taken before upgrading. It is
therefore imperative that you back up your data before starting the
upgrade process.
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.20. It may also be viewed
online at
http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-21.html
Enjoy!
==============================================================================
Changes in MySQL 8.0.21 (2020-07-13) In the documentation for MySQL 8.0.21, we have started changing the term "master" to "source", the term "slave" to "replica", the term "whitelist" to "allowlist", and the term "blacklist" to "blocklist". There are currently no changes to the product's syntax, so these terms are still present in the documentation where the current code requires their use. See the blog post MySQL Terminology Updates (https://mysqlhighavailability.com/mysql-terminology-updates/) for more information. * Account Management Notes * C API Notes * Compilation Notes * Configuration Notes * Connection Management Notes * Deprecation and Removal Notes * JSON Notes * Optimizer Notes * Packaging Notes * Pluggable Authentication * Security Notes * Test Suite Notes * X Plugin Notes * Functionality Added or Changed * Bugs Fixed Account Management Notes * You can now set per-user comments and attributes when creating or updating MySQL user accounts. A user comment consists of arbitrary text passed as the argument to a COMMENT clause used with a CREATE USER or ALTER USER statement. A user attribute consists of data in the form of a JSON object passed as the argument to an ATTRIBUTE clause used with either of these two statements. The attribute can contain any valid key-value pairs in JSON object notation. For example, the first of the following two statements creates a user account bill@localhost with the comment text This is Bill's user account. The second statement adds a user attribute to this account, using the key email, with the value bill@example.com. CREATE USER 'bill'@'localhost' COMMENT 'This is Bill\'s user account'; ALTER USER 'mary'@'localhost' ATTRIBUTE '{"email":"bill@example.com"}'; Only one of COMMENT or ATTRIBUTE can be used in the same CREATE USER or ALTER USER statement. User comments and user attributes are stored together internally as a JSON object, with the comment text as the value of an element with the key comment. You can information retrieve user comments and user attributes from the ATTRIBUTE column of the INFORMATION_SCHEMA.USER_ATTRIBUTES table; since this data is in JSON format, you can work with it using MySQL's JSON function and operators (see JSON Functions (https://dev.mysql.com/doc/refman/8.0/en/json-functions.html)). Changes to an existing user attribute are merged with its current value, as you had used JSON_MERGE_PATCH(); new key-value pairs are appended to the attribute, and new values for existing keys overwrite their previous values. To remove a given key-value pair from a user attribute, use ALTER USER user ATTRIBUTE '{"key":null}'. For more information and examples, see CREATE USER Statement (https://dev.mysql.com/doc/refman/8.0/en/create-user.html), ALTER USER Statement (https://dev.mysql.com/doc/refman/8.0/en/alter-user.html), and The INFORMATION_SCHEMA USER_ATTRIBUTES Table (https://dev.mysql.com/doc/refman/8.0/en/information-schema-user-attributes-table.html). References: See also: Bug #31067575. C API Notes * Per OpenSSL recommendation, x509_check_host() and X509_check_ip_asc() calls in the C client library were replaced, respectively, with X509_VERIFY_PARAM_set1_host() and X509_VERIFY_PARAM_set1_ip_asc() calls. (Bug #29684791) * The MySQL C API now supports compression for asynchronous functions. This means that the MYSQL_OPT_COMPRESSION_ALGORITHMS and MYSQL_OPT_ZSTD_COMPRESSION_LEVEL options for the mysql_options() function now affect asynchronous operations, not just synchronous operations. See mysql_options() (https://dev.mysql.com/doc/refman/8.0/en/mysql-options.html). Compilation Notes * The minimum version of the Boost library for server builds is now 1.72.0. (Bug #30963985) Configuration Notes * tcmalloc is no longer a permitted value for the mysqld_safe --malloc-lib option. (Bug #31372027) Connection Management Notes * MySQL Server supports a "main" network interface for ordinary client connections, and optionally an administrative network interface for administrative client connections. Previously, the main and administrative interfaces used the same TLS configuration, such as the certificate and key files for encrypted connections. It is now possible to configure TLS material separately for the administrative interface: + There are new configuration parameters that apply specifically to the administrative interface. + The ALTER INSTANCE RELOAD TLS statement is extended with a FOR CHANNEL clause that enables specifying the channel (interface) for which to reload the TLS context. + The new Performance Schema tls_channel_status table exposes TLS context properties for the main and administrative interfaces. + For backward compatibility, the administrative interface uses the same TLS context as the main interface unless some nondefault TLS parameter value is configured for the administrative interface. For more information, see Administrative Interface Support for Encrypted Connections (https://dev.mysql.com/doc/refman/8.0/en/administrative-connection-interface.html#administrative-interface-encrypted-connections), ALTER INSTANCE Statement (https://dev.mysql.com/doc/refman/8.0/en/alter-instance.html), and The tls_channel_status Table (https://dev.mysql.com/doc/refman/8.0/en/performance-schema-tls-channel-status-table.html). Deprecation and Removal Notes * Partitioning: Columns with index prefixes are not supported as part of a table's partitioning key; previously such columns were simply omitted by the server when referenced in creating, altering, or upgrading a table that was partitioned by key, with no indication that this omission had taken place, except when the proposed partitioning function used only columns with prefixes, in which case the statement failed with an error message that did not identify the actual source of the problem. This behavior is now deprecated, and subject to removal in a future release in which using any such columns in the proposed partitioning key will cause the CREATE TABLE or ALTER TABLE statement in which they occur to be rejected. When one or more columns using index prefixes are specified as part of the partitioning key, a warning is now generated for each such column. In addition, when a CREATE TABLE or ALTER TABLE statement is rejected because all columns specified in the proposed partitioning key employ index prefixes, the error message returned now makes clear the reason the statement did not succeed. This includes cases in which the columns proposed the partitioning function are defined implicitly as those in the table's primary key by employing an empty PARTITION BY KEY() clause. For more information and examples, see Column index prefixes not supported for key partitioning (https://dev.mysql.com/doc/refman/8.0/en/partitioning-limitations.html#partitioning-limitations-prefixes), and KEY Partitioning (https://dev.mysql.com/doc/refman/8.0/en/partitioning-key.html). (Bug #29941932, Bug #29941959, Bug #31100205) References: See also: Bug #29942014. JSON Notes * Added the JSON_VALUE() function, which simplifies creating indexes on JSON columns. A call to JSON_VALUE(json_doc, path RETURNING type) is equivalent to calling CAST( JSON_UNQUOTE( JSON_EXTRACT(json_doc, path) ) AS type), where json_doc is a JSON document, path is a JSON path expression pointing to a single value within the document, and type is a data type compatible with CAST(). RETURNING type is optional; if no return type is specified, JSON_VALUE() returns VARCHAR(512). JSON_VALUE() also supports ON EMPTY and ON ERROR clauses similar to those used with JSON_TABLE(). You can create indexes on a JSON column using JSON_VALUE() as shown here: CREATE TABLE inventory( items JSON, INDEX i1 ( (JSON_VALUE(items, '$.name' RETURNING VARCHAR(50))) ), INDEX i2 ( (JSON_VALUE(items, '$.price' RETURNING DECIMAL(5,2))) ) , INDEX i3 ( (JSON_VALUE(items, '$.quantity' RETURNING UNSIGNED)) ) ); Assuming the items column contains values such as '{"name": "hat", "price": "22.95", "quantity": "17"}', you can issue queries, such as the following, that can use these indexes: SELECT items->"$.price" FROM inventory WHERE JSON_VALUE(items, '$.name' RETURNING VARCHAR(50)) = "hat"; SELECT * FROM inventory WHERE JSON_VALUE(items, '$.price' RETURNING DECIMAL(5,2)) <= 100.0 1; SELECT items->"$.name" AS item, items->"$.price" AS amount FROM inventory WHERE JSON_VALUE(items, '$.quantity' RETURNING UNSIGNED) > 500; For more information and examples, see the description of the JSON_VALUE() function. Optimizer Notes * MySQL attempts to use an ordered index for any ORDER BY or GROUP BY query that has a LIMIT clause, overriding any other choices made by the optimizer, whenever it determines that this would result in faster execution. Because the algorithm for making this determination makes certain assumptions about data distribution and other conditions, it may not always be completely correct, and it is possible in some cases that choosing a different optimization for such queries can provide better performance. To handle such occurrences, it is now possible to disable this optimization by setting the optimizer_switch system variable's prefer_ordering_index flag to off. For more information about this flag and examples of its use, see Switchable Optimizations (https://dev.mysql.com/doc/refman/8.0/en/switchable-optimizations.html), and LIMIT Query Optimization (https://dev.mysql.com/doc/refman/8.0/en/limit-optimization.html). Our thanks to Jeremy Cole for the contribution. (Bug #97001, Bug #30348211) * A single-table UPDATE or DELETE statement that uses a subquery having a [NOT] IN or [NOT] EXISTS predicate can now in many cases make use of a semijoin transformation or subquery materialization. This can be done when the statement does not use LIMIT or ORDER BY, and when semijoin or subquery materialization is allowed by any optimizer hints used in the subquery, or by the value of the optimizer_switch server system variable. You can see when the semijoin optimization or subquery materialization is used for an eligible single-table DELETE or UPDATE due to the presence of a join_optimization object in the optimizer trace. You can also see that the conversion is performed by checking the output of EXPLAIN FORMAT=TREE; if the optimization is not performed, this shows <not executable by iterator executor>, while a multi-table statement reports a full plan. As part of this work, semi-consistent reads are now supported by multi-table UPDATE of InnoDB tables, when the transaction isolation level is weaker than REPEATABLE READ. (Bug #35794, Bug #96423, Bug #11748293, Bug #30139244) * Added the optimizer_switch flag subquery_to_derived. When this flag is set to on, the optimizer transforms eligible scalar subqueries into left outer joins (and in some cases, inner joins) on derived tables. This optimization can be applied to a subquery which meets the following conditions: + It uses one or more aggregate functions but no GROUP BY. + It is part of a SELECT, WHERE, JOIN, or HAVING clause. + It is not a correlated subquery. + It does not make use of any nondeterminstic functions. ANY and ALL subqueries which can be rewritten to use MIN() or MAX() are also not affected. With subquery_to_derived=on, the optimization can also be applied to a table subquery which is the argument to IN, NOT IN, EXISTS, or NOT EXISTS, and which does not contain a GROUP BY clause. The subquery_to_derived flag is set to off by default, since it generally does not improve performance, and its intended use for the most part is for testing purposes. For more information, see Switchable Optimizations (https://dev.mysql.com/doc/refman/8.0/en/switchable-optimizations.html), for more information and examples. See also Optimizing Derived Tables, View References, and Common Table Expressions with Merging or Materialization (https://dev.mysql.com/doc/refman/8.0/en/derived-table-optimization.html), and LIMIT Query Optimization (https://dev.mysql.com/doc/refman/8.0/en/limit-optimization.html). * Building on work done in MySQL 8.0.18, the server now performs injection of casts into queries to avoid mismatches when comparing string data types with those of numeric or temporal types; as when comparing numeric and temporal types, the optimizer now adds casting operations in the item tree inside expressions and conditions in which the data type of the argument and the expected data type do not match. This makes queries in which string types are compared with numeric or temporal types equivalent to queries which are compliant with the SQL standard, while maintaining backwards compatibility with previous releases of MySQL. Such casts are now performed whenever string values are compared to numeric or temporal values using any of the standard numeric comparison operators (=, >=, >, <, <=, <>/!=, and <=>). Such implicit casts are now performed between a string type (CHAR, VARCHAR, BINARY, VARBINARY, BLOB, TEXT, ENUM, or SET) and a numeric type (SMALLINT, TINYINT, MEDIUMINT, INT/INTEGER, BIGINT; DECIMAL/NUMERIC; FLOAT, DOUBLE, REAL; and BIT) by casting the string value to DOUBLE; if the numeric value is not already of type DOUBLE, FLOAT, or REAL, it is also cast to DOUBLE. A YEAR value is also cast to DOUBLE when compared with a string value (as is the string value). For such comparisons between string types and TIMESTAMP or DATETIME values, the arguments are cast as DATETIME; when a string type is compared with a DATE value, the string is cast to DATE. For example, a query such as SELECT * FROM t1 JOIN t2 ON t1.char_col = t2.int_col is rewritten and executed as SELECT * FROM t1 JOIN t2 ON CAST(t1.char_col AS DOUBLE) = CAST(t2.int_col AS DOUBLE), and SELECT * FROM t1 JOIN t2 ON t1.varchar_col = t2.timestamp_col is transformed to SELECT * FROM t1 JOIN t2 ON CAST(t1.varchar_col AS DATETIME) = CAST(t2.timestamp_col AS DATETIME) prior to execution. You can see when casts are injected into a given query by viewing the output of EXPLAIN ANALYZE, EXPLAIN FORMAT=JSON, or EXPLAIN FORMAT=TREE. EXPLAIN [FORMAT=TRADITIONAL] can also be used, but in this case it is necessary, following execution of the EXPLAIN statement, to issue SHOW WARNINGS to view the rewritten query. This change is not expected to cause any difference in query results or performance. Packaging Notes * For RPM and Debian packages, client-side plugins were moved from the server package to the client package. Additionally, debug versions of client-side plugins were moved to the test package. (Bug #31123564, Bug #31336340) * MSI packages for Windows no longer include the legacy server data component. (Bug #31060177) * The libevent library bundled with MySQL was upgraded to version 2.1.11. (Bug #30926742) * The ICU (International Components for Unicode) library bundled with MySQL has been upgraded to version 65.1. Pluggable Authentication * The MySQL Enterprise Edition authentication_ldap_sasl plugin that implements SASL LDAP authentication supports multiple authentication methods, but depending on host system configuration, they might not all be available. The new Authentication_ldap_sasl_supported_methods status variable provides discoverability for the supported methods. Its value is a string consisting of supported method names separated by spaces. Example: "SCRAM-SHA1 GSSAPI" Security Notes * For platforms on which OpenSSL libraries are bundled, the linked OpenSSL library for MySQL Server has been updated to version 1.1.1g. Issues fixed in the new OpenSSL version are described at https://www.openssl.org/news/cl111.txt and https://www.openssl.org/news/vulnerabilities.html. (Bug #31296697) * Previously, LOCAL data loading capability for the LOAD DATA statement could be controlled on the client side only by enabling it for all files accessible to the client, or by disabling it altogether. The new MYSQL_OPT_LOAD_DATA_LOCAL_DIR option for the mysql_options() C API function enables clients to restrict LOCAL data loading to files located in a designated directory. See Security Considerations for LOAD DATA LOCAL (https://dev.mysql.com/doc/refman/8.0/en/load-data-local-security.html). Test Suite Notes * mysql-test-run.pl no longer accepts unique prefixes of command options. Complete option names must be given. (Bug #31390127) * MySQL tests were updated to use googletest 1.10.0. (Bug #31364750) * mysql-test-run.pl now supports an --mtr-port-exclude option for specifying the range of ports to exclude when searching for available port ranges to use. The MTR_PORT_EXCLUDE environment variable may also be set to achieve the same effect. Thanks to Facebook for the contribution. (Bug #30809607) * In addition to aborting on receipt of CTRL+C (SIGINT), mysql-test-run.pl now also displays a list of test cases that failed up to that point. (Bug #30407014) X Plugin Notes * Where a dollar sign ($) was used to reference an entire document, X Plugin handled the reference differently depending on the context in which it was used. This has now been standardized. (Bug #31374713) * With certain settings for the global SQL mode, X Plugin's authentication process failed to accept a correct user password. The authentication process now operates independently from the global SQL mode's setting to ensure consistency. (Bug #31086109) Functionality Added or Changed * Important Change: By default, a replication source server writes a checksum for each event in the binary log, as specified by the system variable binlog_checksum, which defaults to the setting CRC32. Previously, Group Replication did not support the presence of checksums in the binary log, so binlog_checksum had to be set to NONE when configuring a server instance that would become a group member. This requirement is now removed, and the default can be used. The setting for binlog_checksum does not have to be the same for all members of a group. Note that Group Replication does not use checksums to verify incoming events on the group_replication_applier channel, because events are written to that relay log from multiple sources and before they are actually written to the originating server's binary log, which is when a checksum is generated. Checksums are used to verify the integrity of events on the group_replication_recovery channel and on any other replication channels on group members. * Performance: Improved the implementation of the UNHEX() function by introducing a lookup table for mapping a hexadecimal digit string to its binary representation. This change speeds up execution of the function by a factor of 8 or more in testing. (Bug #31173103) * InnoDB: Redo logging can now be enabled and disabled using ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG syntax. This functionality is intended for loading data into a new MySQL instance. Disabling redo logging helps speed up data loading by avoiding redo log writes. The new INNODB_REDO_LOG_ENABLE privilege permits enabling and disabling redo logging. The new Innodb_redo_log_enabled status variable permits monitoring redo logging status. * InnoDB: Truncating an undo tablespace on a busy system could affect performance due to associated flushing operations that remove old undo tablespace pages from the buffer pool and flush the initial pages of the new undo tablespace to disk. To address this issue, the flushing operations were removed. Old undo tablespace pages are now released passively as they become least recently used, or are removed at the next full checkpoint. The initial pages of the new undo tablespace are now redo logged instead of being flushed to disk during the truncate operation, which also improves durability of the undo tablespace truncate operation. To prevent potential issues caused by an excessive number of undo tablespace truncate operations, truncate operations on the same undo tablespace between checkpoints are now limited to 64. If the limit is exceeded, an undo tablespace can still be made inactive, but it is not truncated until after the next checkpoint. INNODB_METRICS counters associated with defunct undo truncate flushing operations were removed. Removed counters include: undo_truncate_sweep_count, undo_truncate_sweep_usec, undo_truncate_flush_count, and undo_truncate_flush_usec. See Undo Tablespaces (https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html). * InnoDB: At startup, InnoDB validates the paths of known tablespace files against tablespace file paths stored in the data dictionary in case tablespace files have been moved to a different location. The new innodb_validate_tablespace_paths variable permits disabling tablespace path validation. This feature is intended for environments where tablespaces files are not moved. Disabling tablespace path validation improves startup time on systems with a large number of tablespace files. * InnoDB: Table and partition data files created outside of the data directory using the DATA DIRECTORY clause are now restricted to directories that are known to InnoDB. This change permits database administrators to control where tablespace data files are created and ensures that the data files can be found during recovery. General and file-per-table tablespaces data files (.ibd files) can no longer be created in the undo tablespace directory (innodb_undo_directory) unless that directly is known to InnoDB. Known directories are those defined by the datadir, innodb_data_home_dir, and innodb_directories variables. * InnoDB: To improve concurrency for operations that require access to lock queues for table and row resources, the lock system mutex (lock_sys->mutex) was replaced by sharded latches, and lock queues were grouped into table and page lock queue shards, with each shard protected by a dedicated mutex. Previously, the single lock system mutex protected all lock queues, which was a point of contention on high-concurrency systems. The new sharded implementation permits more granular access to lock queues. The lock system mutex (lock_sys->mutex) was replaced by the following sharded latches: + A global latch (lock_sys->latches.global_latch) consisting of 64 read-write lock objects (rw_lock_t). Access to an individual lock queue requires a shared global latch and a latch on the lock queue shard. Operations that require access to all lock queues take an exclusive global latch, which latches all table and page lock queue shards. + Table shard latches (lock_sys->latches.table_shards.mutexes), implemented as an array of 512 mutexes, with each mutex dedicated to one of 512 table lock queue shards. + Page shard latches (lock_sys->latches.page_shards.mutexes), implemented as an array of 512 mutexes, with each mutex dedicated to one of 512 page lock queue shards. The Performance Schema wait/synch/mutex/innodb/lock_mutex instrument for monitoring the single lock system mutex was replaced by instruments for monitoring the new global, table shard, and page shard latches: + wait/synch/sxlock/innodb/lock_sys_global_rw_lock + wait/synch/mutex/innodb/lock_sys_table_mutex + wait/synch/mutex/innodb/lock_sys_page_mutex * Previously, the --disabled-storage-engines option did not ignore spaces around storage engines listed in the option value. Spaces around engine names are now ignored. (Bug #31373361, Bug #99632) * The new HANDLE_FATAL_SIGNALS CMake option enables configuring whether Address Sanitizer and Undefined Behavior Sanitizer builds use the sanitizer runtime library to handle fatal signals rather than a MySQL-internal function. The option default is ON for non-sanitizer builds, OFF for sanitizer builds. If the option is OFF, the default action is used for SIGBUS, SIGILL and SIGSEGV, rather than the internal function. (Bug #31068443) * Using a column that is repeated twice or more in GROUP BY (through an alias), combined with ROLLUP, had behavior differing from MySQL 5.7. Example: SELECT a, b AS a, COUNT(*) FROM t1 GROUP BY a, b WITH ROLLUP; Behavior of such queries has been changed to better match MySQL 5.7. They should be avoided, however, because behavior may change again in the future or such queries may become illegal. (Bug #30921780, Bug #98663) * EXPLAIN ANALYZE now supports the FORMAT option. Currently, TREE is the only supported format. (Bug #30315224) * ALTER INSTANCE ROTATE INNODB MASTER KEY is no longer permitted when read_only or super_read_only are enabled. (Bug #30274240) * LOAD XML now supports CDATA sections in the XML file to be imported. (Bug #98199, Bug #30753708) * X Plugin's mysqlx_bind_address system variable now accepts multiple IP addresses like MySQL Server's bind_address system variable does, enabling X Plugin to listen for TCP/IP connections on multiple network sockets. An important difference in behavior is that for MySQL Server, any error in the list of addresses prevents the server from starting, but X Plugin (which is not a mandatory plugin) does not do this. With X Plugin, if one of the listed addresses cannot be parsed or if X Plugin cannot bind to it, the address is skipped, an error message is logged, and X Plugin attempts to bind to each of the remaining addresses. X Plugin's Mysqlx_address status variable displays only those addresses from the list for which the bind succeeded. If none of the listed addresses results in a successful bind, X Plugin logs an error message stating that X Protocol cannot be used. * On storage engines that support atomic DDL, the CREATE TABLE ... SELECT statement is now executed as an atomic operation by the replica applier thread in row-based replication. Previously, in row-based replication, the CREATE TABLE ... SELECT statement was written to the binary log as two transactions. * ENGINE_ATTRIBUTE and SECONDARY_ENGINE_ATTRIBUTE options were added to CREATE TABLE, ALTER TABLE, and CREATE INDEX syntax. The ENGINE_ATTRIBUTE option was also added to CREATE TABLESPACE and ALTER TABLESPACE syntax. The new options, which permit defining storage engine attributes for tables, columns, indexes, and tablespaces, are reserved for future use. The following INFORMATION_SCHEMA tables were added for querying storage engine attributes for tables, columns, indexes, and tablespaces. Values are stored in the data dictionary. The tables are reserved for future use. + INFORMATION_SCHEMA.TABLES_EXTENSIONS + INFORMATION_SCHEMA.COLUMNS_EXTENSIONS + INFORMATION_SCHEMA.TABLE_CONSTRAINTS_EXTENSIONS + INFORMATION_SCHEMA.TABLESPACES_EXTENSIONS * Group Replication group members can now advertise a list of IP addresses that joining members can use to make connections to them for state transfer during distributed recovery. Previously, the existing member's standard SQL client connection was used for this purpose as well as for client traffic. Advertising distributed recovery endpoints instead gives you improved control of distributed recovery traffic (comprising remote cloning operations and state transfer from the binary log) in your network infrastructure. The list of distributed recovery endpoints for a member is specified using the new group_replication_advertise_recovery_endpoints system variable, and the same SSL requirements are applied that would be in place if the SQL client connection was used for distributed recovery. * The default logging level for MySQL Server omits informational log messages, which previously included some significant lifecycle events for Group Replication that were non-error situations, such as a group membership change. Messages about significant events for a replication group have now been reclassified as system messages, so they always appear in the server's error log regardless of the server logging level. Operators can therefore review a complete history of the server's membership in a replication group. Also, socket bind errors on the group communication layer have been reclassified from information to error messages. * You can now specify user credentials for distributed recovery on the START GROUP_REPLICATION statement using the USER, PASSWORD, and DEFAULT_AUTH options. These credentials are used for distributed recovery on the group_replication_recovery channel. When you specify user credentials on START GROUP_REPLICATION, the credentials are saved in memory only, and are removed by a STOP GROUP_REPLICATION statement or server shutdown. These credentials can replace user credentials set using a CHANGE MASTER TO statement, which are stored in the replication metadata repositories, and can therefore help to secure the Group Replication servers against unauthorized access. The new method of providing user credentials is not compatible with starting Group Replication automatically on server start. If user credentials have previously been set using a CHANGE MASTER TO statement, credentials that you specify on START GROUP_REPLICATION take precedence over these. However, the credentials from the replication metadata repositories are used if START GROUP_REPLICATION is specified without user credentials, which happens on automatic starts if the group_replication_start_on_boot system variable is set to ON (including after a remote cloning operation for distributed recovery). To gain the security benefits of specifying user credentials on START GROUP_REPLICATION, ensure that group_replication_start_on_boot is set to OFF (the default is ON), and use a CHANGE MASTER TO statement to clear any user credentials previously set for the group_replication_recovery channel. * The minimum setting for the maximum size for the XCom message cache in Group Replication, specified by the group_replication_message_cache_size system variable, has been reduced from approximately 1 GB to 134217728 bytes, or approximately 128 MB. Note that this size limit applies only to the data stored in the cache, and the cache structures require an additional 50 MB of memory. The same cache size limit should be set on all group members. The default XCom message cache size of 1 GB, which was formerly also the minimum setting, is unchanged. The smaller message cache size is provided to enable deployment on a host that has a restricted amount of available memory and good network connectivity. Having a very low group_replication_message_cache_size setting is not recommended if the host is on an unstable network, because a smaller message cache makes it harder for group members to reconnect after a transient loss of connectivity. If some messages that were exchanged during a member's temporary absence have been deleted from the other members' XCom message caches because their maximum size limit was reached, the member cannot reconnect using the message cache. It must leave the group and rejoin in order to retrieve the transactions through distributed recovery, which is a slower process than using the message cache, although the member still can rejoin in this way without operator intervention. Note that from MySQL 8.0.21, by default an expel timeout of 5 seconds is added before a member is expelled from the group (specified by the group_replication_member_expel_timeout system variable). With this default setting the XCom message cache therefore now needs to store the messages exchanged by the group in a 10-second period (the expel timeout plus the initial 5-second detection period), rather than in a 5-second period as previously (the initial 5-second detection period only). * group_replication_member_expel_timeout specifies the period of time in seconds that a Group Replication group member waits after creating a suspicion, before expelling from the group the member suspected of having failed. The initial 5-second detection period before a suspicion is created does not count as part of this time. Previously, the waiting period specified by group_replication_member_expel_timeout defaulted to 0, meaning that a suspected member was liable for expulsion immediately after the 5-second detection period ended. Following user feedback, the waiting period now defaults to 5 seconds, giving a member that loses touch with the group 10 seconds in total to reconnect itself to the group. If the member does reconnect in this time, it can recover missed messages from the XCom message cache and return to ONLINE state automatically, rather than being expelled from the group and needing the auto-rejoin procedure or manual operator intervention to rejoin. If you previously tuned the size of the XCom message cache with reference to the expected volume of messages in the previous default time before a member was expelled (the 5-second detection period only), increase your group_replication_message_cache_size setting to account for the new expel timeout, which doubles the default time to 10 seconds. With the new default expel timeout you might start to see warning messages from GCS on active group members, stating that a message that is likely to be needed for recovery by a member that is currently unreachable has been removed from the message cache. This message shows that a member has had a need to use the message cache to reconnect, and that the cache size might not be sufficient to support the current waiting period before a member is expelled. * Group Replication's auto-rejoin feature is now activated by default. The group_replication_autorejoin_tries system variable, which is available from MySQL 8.0.16, makes a member that has been expelled or reached its unreachable majority timeout try to rejoin the group automatically. This system variable, which originally defaulted to 0 so auto-rejoin was not activated, now defaults to 3, meaning that a member makes three attempts to rejoin the group in the event of its expulsion or unreachable majority timeout. Between each attempt the member waits for 5 minutes. If the specified number of tries is exhausted without the member rejoining or being stopped, the member proceeds to the action specified by the group_replication_exit_state_action system variable. The auto-rejoin feature minimizes the need for manual intervention to bring a member back into the group, especially where transient network issues are fairly common. During and between auto-rejoin attempts, a member remains in super read only mode and does not accept writes. However, reads can still be made on the member, with an increasing likelihood of stale reads over time. If you want to intervene to take the member offline, the member can be stopped manually at any time by using a STOP GROUP_REPLICATION statement or shutting down the server. If you cannot tolerate the possibility of stale reads for any period of time, set the group_replication_autorejoin_tries system variable to 0, in which case operator intervention is required whenever a member is expelled from the group or reaches its unreachable majority timeout. * MySQL Server Docker containers now support server restart within a client session (which happens, for example, when the RESTART (https://dev.mysql.com/doc/refman/8.0/en/restart.html) statement is executed by a client or during the configuration of an InnoDB cluster instance (https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-working-with-cluster.html#configuring-local-instances)). To enable this important feature, containers should be started with the docker run option --restart set to the value on-failure. See Starting a MySQL Server Instance (https://dev.mysql.com/doc/refman/8.0/en/docker-mysql-getting-started.html#docker-starting-mysql-server) for details. (Bug #30750730)
Subject
Views
Written By
Posted
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.