MySQL 8.0.30 发布

• Important Change: A previous change renamed character sets having deprecated names prefixed with utf8_ to use utf8mb3_ instead. In this release, we rename the utf8_ collations as well, using the utf8mb3_ prefix; this is to make the collation names consistent with those of the character sets, not to rely any longer on the deprecated collation names, and to clarify the distinction between utf8mb3 and utf8mb4. The names using the utf8mb3_ prefix are now used exclusively for these collations in the output of SHOW statements such as SHOW CREATE TABLE, as well as in the values displayed in the columns of Information Schema tables including the COLLATIONS and COLUMNS tables. (Bug #33787300)

  References: See also: Bug #30624990.

• Important Change: When more than one language had the same collation definition, MySQL implemented collations for only one of the languages. This meant that some languages were covered only by utf8mb4 Unicode 9.0 collations that are specific to other languages. This release fixes such issues by adding language-specific collations for those languages that were previously covered only by language-specific collations for other languages. The new collations are listed here:
  • Norwegian
    • (Bokmål) utf8mb4_nb_0900_ai_ci
    • (Bokmål) utf8mb4_nb_0900_as_cs
    • (Nynorsk) utf8mb4_nn_0900_ai_ci
    • (Nynorsk) utf8mb4_nn_0900_as_cs
  • Serbian with Latin characters:
    • utf8mb4_sr_latn_0900_ai_ci
    • utf8mb4_sr_latn_0900_as_cs
  • Bosnian with Latin characters:
    • utf8mb4_bs_0900_ai_ci
    • utf8mb4_bs_0900_as_cs
  • Bulgarian:
    • utf8mb4_bg_0900_ai_ci
    • utf8mb4_bg_0900_as_cs
  • Galician:
    • utf8mb4_gl_0900_ai_ci
    • utf8mb4_gl_0900_as_cs
  • Mongolian with Cyrillic letters:
    • utf8mb4_mn_cyrl_0900_ai_ci
    • utf8mb4_mn_cyrl_0900_as_cs

  For more information, see Language-Specific Collations. (Bug #31885256)

• On Enterprise Linux, fixed ADD_LINUX_RPM_FLAGS so that the initial values of CMAKE_C_FLAGS and CMAKE_CXX_FLAGS are used before modifying them. (Bug #34131794)

  References: This issue is a regression of: Bug #33730302.

• Added a new SHOW_SUPPRESSED_COMPILER_WARNINGS CMake option. Enable it to show suppressed compiler warnings, and do so without failing with -Werror. It defaults to OFF. (Bug #34046748)
• On Windows, deprecation warnings (C4996) were globally disabled with the /wd4996 command-line option; now deprecation warnings are disabled on the localized level where appropriate. (Bug #33975638)
• Improved GCC 8 support to include -lstdc++fs in order to use std::filesystem. (Bug #33939798)

• Replication: Setting the replica_parallel_workers system variable (or the equivalent server option --replica-parallel-workers) to 0 is now deprecated, and doing so now raises a warning.

  To achieve the same result (that is, use single threading) without the warning, set replica_parallel_workers=1 instead.

• The --skip-host-cache server option is now deprecated, and subject to removal in a future release.

  Use a statement such as SET GLOBAL host_cache_size = 0, or set host_cache_size in the my.cnf file, instead.

• The --old-style-user-limits option causes the server to enforce user limits as they were prior to MySQL 5.0.3, and is intended for backwards compatibility with very old releases. This option is now deprecated, and using it now raises a warning. You should expect this option to be removed in a future release of MySQL, and so you are advised to begin now to remove any dependency your MySQL applications might have on this option.

• MySQL 8.0.30 now supports GIPK mode, which causes a generated invisible primary key (GIPK) to be added to any InnoDB table that is created without an explicit primary key. This enhancement applies to InnoDB tables only.

  The definition of the generated key column added to an InnoDB table by GIPK mode is is shown here:

  my_row_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT INVISIBLE PRIMARY KEY

  The name of the generated primary key is always my_row_id; you cannot, while GIPK mode is in effect, use this as a column name in a CREATE TABLE statement that creates a new InnoDB table unless it includes an explicit primary key.

  GIPKs are not enabled by default. To enable them, set the sql_generate_invisible_primary_key server system variable (also introduced in this release) to ON. This setting has no effect on replication applier threads; this means that a replica never generates a primary key for a replicated table that was not created on the source with a primary key.

  You cannot alter a generated invisible primary key while GIPKs are in effect, with one exception: You can toggle the visibility of the GIPK using ALTER TABLE tbl CHANGE COLUMN my_row_id SET VISIBLE and ALTER TABLE tbl CHANGE COLUMN my_row_id SET INVISIBLE.

  By default, generated invisible primary keys can be seen in the output of SHOW CREATE TABLE and SHOW INDEX; they are also visible in MySQL Information Schema tables such as the COLUMNS and STATISTICS tables. You can make them hidden instead by setting show_gipk_in_create_table_and_information_schema to OFF.

  You can exclude generated invisible primary keys from the output of mysqldump using the --skip-generated-invisible-primary-key option added in this release. mysqlpump also now supports a --skip-generated-invisible-primary-key option which excludes GIPKs from its output.

  For more information and examples, see Generated Invisible Primary Keys. For general information on invisible column support in MySQL, see Invisible Columns. (Bug #34092605)

• The keyring_aws plugin has been updated to use the latest AWS Encryption SDK for C (version 1.9.186).

  The keyring_aws_region variable supports the additional AWS regions supported by the new SDK. Refer to the variable description for a list of supported AWS regions.

• The SASL LDAP plugin failed to properly parse Kerberos Key Distribution Center (KDC) host information read from the Kerberos configuration file, resulting in SASL authentication error. (Bug #31862170)

• It is now possible to compile the MySQL server package (mysqld + libmysql + client tools) using OpenSSL 3.0 on supported platforms, which should not change the behavior of the server or client programs. For additional information, see https://wiki.openssl.org/index.php/OpenSSL_3.0.

• Previously, the ST_TRANSFORM() function added in MySQL 8.0.13 did not support Cartesian Spatial Reference Systems. Beginning with this release, support is provided by this function for the Popular Visualisation Pseudo Mercator (EPSG 1024) projection method, used for WGS 84 Pseudo-Mercator (SRID 3857).

• It is now possible to determine whether a REVOKE statement which cannot be executed raises an error or a warning. This is implemented with the addition of two new statement options, listed here with brief descriptions:
  • IF EXISTS causes REVOKE to raise a warning rather than an error as long as the target user or role does not exist.
  • IGNORE UNKNOWN USER causes REVOKE to raise a warning instead of an error if the target user or role is not known, but the statement would otherwise succeed.

  For a single target user or role and a given privilege or role to be removed, using the IF EXISTS and IGNORE UNKNOWN USER options together in the same REVOKE statement means that the statement succeeds (albeit doing nothing, and with a warning), even if both the target user or role and the privilege or role to be removed are unknown, as long as the statement is otherwise valid. In the case of multiple targets, multiple privileges or roles to be removed, or both, the statement succeeds, performing those removals which are valid, and issuing warnings for those which are not.

  For more information, see REVOKE Statement. (Bug #102232, Bug #32495441)

• Replication: Previously, recovery was not guaranteed when a server node in a replication topology unexpectedly halted while executing XA PREPARE, XA COMMIT, or XA ROLLBACK. To address this problem, MySQL now maintains consistent XA transaction state across a topology using either MySQL “classic” Replication or MySQL Group Replication when a server node is lost from the topology and then regained. This also means that XA transaction state is now propagated so that nodes do not diverge while doing work within a given transaction in the event that a server node halts, recovers, and rejoins the topology.

  For any multi-server replication topology (including one using Group Replication), the XA transaction state propagates consistently, so that all servers remain in the same state at all times. For any such topology of any size (including a single server, as long as binary logging is enabled), it is now possible to recover any server to a consistent state after it has halted unexpectedly and been made to rejoin the topology after dropping out.

  This enhancement is implemented for the case of a single server by adding support for a two-phase XA prepare between the storage engine and the server’s internal transaction coordinator (ITC), with the state of the prepare retained by both. This means that the ITC can purge its internal logs safely, without the risk of losing state, should the server halt following the purge. In the single-node case, imposing order of execution between the storage engine and the binary log prevents externalization of GTIDs before the corresponding changes become visible to the storage engine; in a topology comprising multiple servers, this keeps the transaction state from being broadcast to the topology before it is guaranteed to be locally consistent and persistent. In all cases, the state of the XA transaction is extracted from the last binary log file to be written and synchronized with the transaction state obtained from the storage engine.

  A known issue in this release can be encountered when the same transaction XID has been used to execute XA transactions sequentially. If there a disruption in operation occurs while the server is processing XA COMMIT ... ONE PHASE using this same XID, after the transaction has been prepared in the storage engine, the state between the binary log and the storage engine can no longer be reliably synchronized. See

  For more information, see XA Transactions.

• Important Change: Binary packages that include curl rather than linking to the system curl library have been upgraded to use curl 7.83.1. (Bug #34138733)
• Important Change: For platforms on which OpenSSL libraries are bundled, the linked OpenSSL library for MySQL Server has been updated to version 1.1.1o. Issues fixed in OpenSSL version 1.1.1o are described at https://www.openssl.org/news/cl111.txt and https://www.openssl.org/news/vulnerabilities.html. (Bug #34133985)
• Important Change: The fido2 library included with MySQL, used with the authentication_fido plugin, has been upgraded to version 1.8.0. (Previously, version 1.5.0 was included with MySQL.)

  For more information, see FIDO Pluggable Authentication.

• InnoDB: The innodb_doublewrite system variable, which enables or disables the doublewrite buffer, has two new settings, DETECT_ONLY and DETECT_AND_RECOVER. With the DETECT_ONLY setting, database page content is not written to the doublewrite buffer, and recovery does not use the doublewrite buffer to fix incomplete page writes. This lightweight setting is intended for detecting incomplete page writes only. The DETECT_AND_RECOVER setting is equivalent to the existing ON setting. For more information, see Doublewrite Buffer.

  Thanks to Facebook for the contribution. (Bug #32727919, Bug #103211)

• InnoDB: InnoDB now supports dynamic configuration of redo log capacity. The innodb_redo_log_capacity system variable can be set at runtime to increase or decrease the total amount of disk space occupied by redo log files.

  With this change, the number of redo log files and their default location has also changed. From MySQL 8.0.30, InnoDB maintains 32 redo log files in an #innodb_redo directory in the data directory. Previously, InnoDB created two redo log files in the data directory by default, and the number and size of redo log files were controlled by the and innodb_log_files_in_group and innodb_log_file_size variables. These two variables are now deprecated.

  When an innodb_redo_log_capacity setting is defined, innodb_log_files_in_group and innodb_log_file_size settings are ignored; otherwise, those settings are used to compute the innodb_redo_log_capacity setting (innodb_log_files_in_group * innodb_log_file_size = innodb_redo_log_capacity). If none of those variables are set, redo log capacity is set to the innodb_redo_log_capacity default value, which is 104857600 bytes (100MB).

  Several status variables are provided for monitoring the redo log and redo log capacity resize operations.

  As is generally required for any upgrade, this change requires a clean shutdown before upgrading.

  For more information about this feature, see Redo Log.

• Added Ubuntu 22.04 support. (Bug #34123545)
• The order of the columns in the primary key definition for a few tables in the mysql schema has been changed, so that the columns containing the host name and user name are together in sequence at the start of the primary key. ACL queries on these tables are performed using only the host name and user name, and if those columns are not together in sequence, a full table scan must be performed to identify the relevant record. Placing the host name and user name together means that index lookup can be used, which improves performance for CREATE USER, DROP USER, and RENAME USER statements, and for ACL checks for multiple users with multiple privileges.

  The changed tables are mysql.db, mysql.tables_priv, mysql.columns_priv and mysql.procs_priv. When you upgrade to MySQL 8.0.30 or later, these tables are modified in the second step of the MySQL upgrade process. Use the --upgrade=FORCE option when performing logical upgrades using a backup or export utility such as mysqldump or mysqlpump, which ensures that the table structures are checked and rebuilt with the new column order. (Bug #33644645, Bug #33637244)

• The myisam_repair_threads system variable and myisamchk --parallel-recover option were removed. (Bug #31052408)
• A new mysqldump option --mysqld-long-query-time lets you set a custom value of the long_query_time system variable for mysqldump’s session. Use the new option to increase the elapsed time allowed for mysqldump’s queries before they are written to the slow query log file, in order to avoid unnecessary logging. Thanks to Facebook for the contribution. (Bug #96369, Bug #96369, Bug #30110717)
• Error log components can now be loaded implicitly at startup before the InnoDB storage engine is available. This new method of loading error log components loads and enables the components defined by the log_error_services variable.

  Previously, error log components had to be installed first using INSTALL COMPONENT and were only loaded after InnoDB was fully available, as the list of components to load was read from the mysql.components table, which is an InnoDB table.

  Implicit load of error log components has these advantages:

  • Log components are loaded early in the startup sequence, making logged information available sooner.
  • It helps avoid loss of buffered log information should a failure occur during startup.
  • Loading log components using INSTALL COMPONENT is not required, simplifying error log configuration.

  For more information about this feature, see Error Log Configuration.

  If you have previously installed loadable log components using INSTALL COMPONENT and you list those components in a log_error_services setting that is read at startup (from an option file, for example), your configuration should be updated to avoid startup warnings. For more information, see Error Log Configuration Methods.

• MySQL Enterprise Audit’s audit log file can now be extended with optional data fields to show the query time, the number of bytes sent and received, the number of rows returned to the client, and the number of rows examined. This data is available in the slow query log for qualifying queries, and in the context of the audit log it similarly helps to detect outliers for activity analysis. It is delivered to the audit log through new component services that you set up as an audit log filtering function. The extended data fields can only be added when the audit log is in JSON format (audit_log_format=JSON), which is not the default setting.
• MySQL Server’s AES_ENCRYPT() and AES_DECRYPT() functions now support the use of a key derivation function (KDF) to create a cryptographically strong secret key from information such as a password or a passphrase that you pass to the function. The derived key is used to encrypt and decrypt the data, and it remains in the MySQL Server instance and is not accessible to users. Using a KDF is highly recommended, as it provides better security than specifying your own premade key or deriving it by a simpler method when you use the function. The functions support HKDF (available from OpenSSL 1.1.0), for which you can specify an optional salt and context-specific information to include in the keying material, and PBKDF2 (available from OpenSSL 1.0.2), for which you can specify an optional salt and set the number of iterations used to produce the key.
• A new system status variable Tls_library_version shows the runtime version of the OpenSSL library that is in use for the MySQL instance. The version of OpenSSL affects features such as support for TLSv1.3.
• From MySQL 8.0.30, MySQL Enterprise Encryption’s functions are provided by a component, rather than being installed from the openssl_udf shared library. The new functions provided by the component use only the generally preferred RSA algorithm, not the DSA algorithm or the Diffie-Hellman key exchange method, and they follow current best practice on minimum key size. The component functions also add support for SHA3 for digests (provided that OpenSSL 1.1.1 is in use), and do not require digests for signatures, although they support them.

  If you upgrade to MySQL 8.0.30 from an earlier release where the functions are installed manually from the openssl_udf shared library file, the functions you created remain available and are supported. However, these legacy functions are deprecated from this release, and it is recommended that you install the component instead. The component functions are backward compatible, so RSA public and private keys, encrypted data, and signatures that were produced by the legacy functions can be used with the component functions. For the component functions to support decryption and verification for content produced by the legacy functions, you must set the new system variable enterprise_encryption.rsa_support_legacy_padding to ON (the default is OFF).

  The component functions generate public and private RSA keys in PKCS #8 format. They allow a minimum key size of 2048 bits, which is a suitable minimum RSA key length for current best practice. You can set a maximum key size up to 16384 bits using the system variable enterprise_encryption.maximum_rsa_key_size, which defaults to a maximum key size of 4096 bits.

• Connections whose users have the CONNECTION_ADMIN privilege are not terminated when MySQL Server is set to offline mode, which is done by changing the value of the offline_mode system variable to ON. Previously, checking for connections that had the CONNECTION_ADMIN privilege could cause a race condition because it involved accessing other threads. Now, a flag for each thread caches whether or not the user for the thread has the CONNECTION_ADMIN privilege. The flag is updated if the user privilege changes. When offline mode is activated for the server, this flag is checked for each thread, rather than the security context of another thread. This change makes the operation threadsafe.

  In addition, when offline mode is activated, connections whose users have the SYSTEM_USER privilege are now only terminated if the user that runs the operation also has the SYSTEM_USER privilege. Users that only have the SYSTEM_VARIABLES_ADMIN privilege, and do not have the SYSTEM_USER privilege, can set the offline_mode system variable to ON to activate offline mode. However, when they run the operation, any sessions whose users have the SYSTEM_USER privilege remain connected, in addition to any sessions whose users have the CONNECTION_ADMIN privilege. This only applies to existing connections at the time of the operation; users with the SYSTEM_USER privilege but without the CONNECTION_ADMIN privilege cannot make new connections to a system in offline mode.

• Performance Schema provides instrumentation for performance monitoring of Group Replication memory usage.

  See Monitoring Group Replication Memory Usage with Performance Schema Memory Instrumentation.

更多 MySQL :: MySQL 8.0 Release Notes :: Changes in MySQL 8.0.30 (2022-07-26, General Availability)