1.3 What Is New in MySQL 8.3

This section summarizes what has been added to, deprecated in, and removed from MySQL 8.3. A companion section lists MySQL server options and variables that have been added, deprecated, or removed in MySQL 8.3; see Section 1.4, “Server and Status Variables and Options Added, Deprecated, or Removed in MySQL 8.3”.

• Features Added in MySQL 8.3

• Features Deprecated in MySQL 8.3

• Features Removed in MySQL 8.3

Features Added in MySQL 8.3

The following features have been added to MySQL 8.3:

• MySQL Replication: tagged GTIDs.  The format of global transaction identifiers (GIDs) used in MySQL Replication and Group Replication has been extended to enable identification of groups of transactions, making it possible to assign a unique name to the GTIDs which belong to a specific group of transactions. For example, transactions containing data operations can easily be distinguished from those arising from administrative operations simply by comparing their GTIDs.

  The new GTID format is UUID:TAG:NUMBER, where TAG is a string of up to 8 characters, which is enabled by setting the value of the gtid_next system variable to AUTOMATIC:TAG, added in this release (see the description of the variable for tag format and other information). This tag persists for all transactions originating in the current session (unless changed using SET gtid_next), and is applied at commit time for such transactions, or, when using Group Replication, at certification time. It is also possible to set gtid_next to UUID:TAG:NUMBER to set the UUID of a single transaction to an arbitrary value, along with assigning it a custom tag. The assignments of UUID and NUMBER are otherwise unchanged from previous MySQL releases. In either case, the user is responsible for making sure that the tag is unique to a given replication topology.

  The original UUID:NUMBER format for GTIDs continues to be supported unchanged, as implemented in previous versions of MySQL; changes to existing replication setups using GTIDs are not required.

  Setting gtid_next to AUTOMATIC:TAG or UUID:TAG:NUMBER requires a new TRANSACTION_GTID_TAG privilege which is added in this release; this is true both on the originating server as well as for the PRIVILEGE_CHECKS_APPLIER for the replica applier thread. This also means that an administrator can now restrict the use of SET @gtid_next=AUTOMATIC:TAG or UUID:TAG:NUMBER to a desired set of MySQL users or roles so that that only those users related to a given data or operational domain can commit new transactions with assigned tags.

  Note

  When upgrading from a previous version of MySQL to MySQL 8.3, any user accounts or roles which already have the BINLOG_ADMIN privilege are automatically granted the TRANSACTION_GTID_TAG privilege.

  The built-in functions GTID_SUBSET(), GTID_SUBTRACT(), and WAIT_FOR_EXECUTED_GTID_SET() are compatible with tagged GTIDs.

  For more information, see the descriptions of the gtid_next system variable and the TRANSACTION_GTID_TAG privilege, as well as Section 19.1.4, “Changing GTID Mode on Online Servers”.

• EXPLAIN FORMAT=JSON format versioning.  It is now possible to choose between 2 versions of the JSON output format used by EXPLAIN FORMAT=JSON statements using the explain_json_format_version server system variable introduced in this release. Setting this variable to 1 causes the server to use Version 1, which is the linear format which was always used for output from such statements in MySQL 8.2 and earlier. This is the default value and format in MySQL 8.3. Setting explain_json_format_version to 2 causes the Version 2 format to be used; this JSON output format is based on access paths, and is intended to provide better compatibility with future versions of the MySQL Optimizer.

  See Obtaining Execution Plan Information, for more information and examples.

• DDL and DCL statement tracking for group_replication_set_as_primary().  group_replication_set_as_primary() now waits for the following statements to complete before a new primary is elected:

  • ALTER DATABASE

  • ALTER FUNCTION

  • ALTER INSTANCE

  • ALTER PROCEDURE

  • ALTER SERVER

  • ALTER TABLESPACE

  • ALTER USER

  • ALTER VIEW

  • CREATE DATABASE

  • CREATE FUNCTION

  • CREATE PROCEDURE

  • CREATE ROLE

  • CREATE SERVER

  • CREATE SPATIAL REFERENCE SYSTEM

  • CREATE TABLESPACE

  • CREATE TRIGGER

  • CREATE USER

  • CREATE VIEW

  • DROP DATABASE

  • DROP FUNCTION

  • DROP PROCEDURE

  • DROP ROLE

  • DROP SERVER

  • DROP SPATIAL REFERENCE SYSTEM

  • DROP TABLESPACE

  • DROP TRIGGER

  • DROP USER

  • DROP VIEW

  • GRANT

  • RENAME TABLE

  • REVOKE

  These are in addition to those statements added in MySQL 8.1 or otherwise already supported in this regard. For more information, including a listing of all such statements supported in MySQL 8.3, see the description of the group_replication_set_as_primary() function.

• SASL-based LDAP authentication on Windows.  On Microsoft Windows, the server plugin for SASL-based LDAP authentication is now supported. This means that Windows clients can now use GSSAPI/Kerberos for authenticating with the authentication_ldap_sasl_client plugin.

  For more information, see SASL-Based LDAP Authentication.

• Change in binlog_transaction_dependency_tracking default value.  The binlog_transaction_dependency_tracking server system variable was deprecated in MySQL 8.2.0. In preparation for the eventual removal of this variable, its default value is now WRITESET. There are no plans to replace this variable or its functionality, which is expected later to be made internal to the server.

• WITH_LD CMake option.  Define whether to use the llvm lld or mold linker, otherwise use the standard linker. WITH_LD also replaces the USE_LD_LLD CMake option that was removed in MySQL 8.3.0.

• MySQL Enterprise Data Masking and De-Identification.  Data-masking components added support for specifying a dedicated schema to store the related internal table and masking functions. Previously, the mysql system schema provided the only storage option. The new component_masking.masking_database read-only variable enables setting and persisting an alternative schema name at server startup.

• Thread pool plugin connection information.  Added thread pool connection information to the MySQL Performance Schema, as follows:

  • Added a tp_connections table, with information about each thread pool connection.

  • Added the following columns to the tp_thread_state table: TIME_OF_ATTACH, MARKED_STALLED, STATE, EVENT_COUNT, ACCUMULATED_EVENT_TIME, EXEC_COUNT, and ACCUMULATED_EXEC_TIME

  • Added the following columns to the tp_thread_group_state table: EFFECTIVE_MAX_TRANSACTIONS_LIMIT, NUM_QUERY_THREADS, TIME_OF_LAST_THREAD_CREATION, NUM_CONNECT_HANDLER_THREAD_IN_SLEEP, THREADS_BOUND_TO_TRANSACTION, QUERY_THREADS_COUNT, and TIME_OF_EARLIEST_CON_EXPIRE.

  For more information, see Section 7.6.3, “MySQL Enterprise Thread Pool”, and Section 29.12.16, “Performance Schema Thread Pool Tables”.

• Information Schema PROCESSLIST table usage.  Although the INFORMATION_SCHEMA.PROCESSLIST table was deprecated in MySQL 8.0.35 and 8.2.0, interest remains in tracking its usage. This release adds two system status variables providing information about accesses to the PROCESSLIST table, listed here:

  • Deprecated_use_i_s_processlist_count provides a count of the number of references to the PROCESSLIST table in queries since the server was last started.

  • Deprecated_use_i_s_processlist_last_timestamp stores the time the PROCESSLIST table was last accessed. This is a timestamp value (number of microseconds since the Unix Epoch).

• Flushing of data masking dictionaries.  The MySQL Enterprise Data Masking and De-Identification component now includes the ability to flush the data on the secondary or replica into memory. This can be done in either of the ways described here:

  • A flush can be performed by the user at any time using the masking_dictionaries_flush() function added in this release.

  • The component can be configured to flush the memory periodically, leveraging the Scheduler component, by setting the new component_masking.dictionaries_flush_interval_seconds system variable to an appropriate value.

  For more information, see Section 8.5, “MySQL Enterprise Data Masking and De-Identification”, and the descriptions of these items.

Features Deprecated in MySQL 8.3

The following features are deprecated in MySQL 8.3 and may be removed in a future series. Where alternatives are shown, applications should be updated to use them.

For applications that use features deprecated in MySQL 8.3 that have been removed in a later MySQL version, statements may fail when replicated from a MySQL 8.3 source to a replica running a later version, or may have different effects on source and replica. To avoid such problems, applications that use features deprecated in 8.3 should be revised to avoid them and use alternatives when possible.

• Group Replication recovery metadata.  Group Replication recovery no longer depends on writing of view change events to the binary log to mark changes in group membership; instead, when all members of a group are MySQL version 8.3.0 or later, members share compressed recovery metadata, and no such event is logged (or assigned a GTID) when a new member joins the group.

  Recovery metadata includes the GCS view ID, GTID_SET of certified transactions, and certification information, as well as a list of online members.

  Since View_change_log_event no longer plays a role in recovery, the group_replication_view_change_uuid system variable is no longer needed, and so is now deprecated; expect its removal in a future MySQL release. You should be aware that no replacement or alternative for this variable or its functionality is planned, and develop your applications accordingly.

Features Removed in MySQL 8.3

The following items are obsolete and have been removed in MySQL 8.3. Where alternatives are shown, applications should be updated to use them.

For MySQL 8.2 applications that use features removed in MySQL 8.3, statements may fail when replicated from a MySQL 8.2 source to a MySQL 8.3 replica, or may have different effects on source and replica. To avoid such problems, applications that use features removed in MySQL 8.3 should be revised to avoid them and use alternatives when possible.

• C API functions removed.  The following MySQL C API functions were deprecated in previous versions of MySQL, and have now been removed:

  • mysql_kill(): Use mysql_real_query() or mysql_query() to execute a KILL statement instead.

  • mysql_list_fields(): Use mysql_real_query() or mysql_query() to execute SELECT * FROM table LIMIT 0 instead. (This is roughly equivalent to executing the statement in the mysql client after starting it with the --column-type-info option.)

    The char *def member of the MYSQL_FIELD structure was used by this function only, and has also been removed.

  • mysql_list_processes(): Use mysql_real_query() or mysql_query() to execute a SHOW PROCESSLIST statement instead.

  • mysql_refresh(): Use mysql_real_query() or mysql_query() to execute a FLUSH statement instead.

    Due to the removal of this function, the mysqladmin flush-threads command has also been removed.

  • mysql_reload(): Use mysql_real_query() or mysql_query() to execute a FLUSH PRIVILEGES statement instead.

  • mysql_shutdown(): Use mysql_real_query() or mysql_query() to execute a SHUTDOWN statement instead.

  mysql_shutdown() was deprecated in MySQL 8.0; the remainder of the functions listed were deprecated in MySQL 5.7.11.

  Due to these changes, the MySQL C API library version is raised from 22.1 to 23.0.

• FLUSH HOSTS statement.  The FLUSH HOSTS statement, deprecated in MySQL 8.0.23, has been removed. To clear the host cache, issue TRUNCATE TABLE performance_schema.host_cache or mysqladmin flush-hosts.

• Obsolete replication options and variables.  A number of options and variables relating to MySQL Replication were deprecated in previous versions of MySQL, and have been removed from MySQL 8.3. Attempting to use any of these now causes the server to raise a syntax error. These options and variables are listed here:

  • --slave-rows-search-algorithms: The algorithm used by the replication applier to look up table rows when applying updates or deletes is now always HASH_SCAN,INDEX_SCAN, and is no longer configurable by the user.

  • log_bin_use_v1_events: This allowed source servers running MySQL 5.7 and newer to replicate to earlier versions of MySQL which are no longer supported or maintained.

  • --relay-log-info-file, --relay-log-info-repository, --master-info-file, --master-info-repository: The use of files for the applier metadata repository and the connection metadata repository has been superseded by crash-safe tables, and is no longer supported. See Section 19.2.4.2, “Replication Metadata Repositories”.

  • transaction_write_set_extraction

  • group_replication_ip_whitelist: Use group_replication_ip_allowlist instead.

  • group_replication_primary_member: No longer needed; check the MEMBER_ROLE column of the Performance Schema replication_group_members table instead.

• --skip-host-cache server option.  This option has been removed; start the server with --host-cache-size=0 instead. See Section 7.1.12.3, “DNS Lookups and the Host Cache”.

• --innodb and --skip-innodb server options.  These options have been removed. The InnoDB storage engine is always enabled, and it is not possible to disable it.

• --character-set-client-handshake and --old-style-user-limits server options.  These options were formerly used for compatibility with very old versions of MySQL which are no longer supported or maintained, and thus no longer serve any useful purpose.

• Obsolete CMake options.  The following options for compiling the server with CMake were obsolete and have been removed:

  • USE_LD_LLD: Use WITH_LD=lld instead.

  • WITH_BOOST, DOWNLOAD_BOOST, DOWNLOAD_BOOST_TIMEOUT: These options are no longer necessary; MySQL now includes and uses a bundled version of Boost when compiling from source.

• GTID-based replication and IGNORE_SERVER_IDS.  When global transaction identifiers (GTIDs) are used for replication, transactions that have already been applied are automatically ignored. This means that IGNORE_SERVER_IDS is not compatible with GTID mode. If gtid_mode is ON, CHANGE REPLICATION SOURCE TO with a non-empty IGNORE_SERVER_IDS list is rejected with an error. Likewise, if any existing replication channel was created with a list of server IDs to be ignored, SET gtid_mode=ON is also rejected. Before starting GTID-based replication, check for and clear any ignored server ID lists on the servers involved; you can do this by checking the output from SHOW REPLICA STATUS. In such cases, you can clear the list by issuing CHANGE REPLICATION SOURCE TO with an empty list of server IDs, as shown here:

  CHANGE REPLICATION SOURCE TO IGNORE_SERVER_IDS = ();

  See Section 19.1.3.7, “Restrictions on Replication with GTIDs”, for more information.

• Binary log transaction dependency tracking and logging format.  Using writeset information for conflict detection has been found to cause issues with dependency tracking; for this reason, we now limit the usage of writesets for conflict checks to when row-based logging is in effect.

  This means that, beginning with this release, if binlog_transaction_dependency_tracking is set to WRITESET or WRITESET_SESSION, binlog_format must be ROW; MIXED is no longer supported in such cases.