[Due to size limitation, this announcement is split in two. This is part 1]
Dear MySQL users, MySQL Server 8.0.14, a new version of the popular Open Source Database Management System, has been released. MySQL 8.0.14 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.14 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.14 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.14 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.14 also comes with a web installer as an alternative to the full installer. The web installer doesn't come bundled with any actual products and instead relies on download-on-demand to fetch only the products you choose to install. This makes the initial download much smaller but increases install time as the individual products will need to be downloaded. We welcome and appreciate your feedback, bug reports, bug fixes, patches, etc.: http://bugs.mysql.com/report.php The following link lists the changes in the MySQL 8.0 since the release of MySQL 8.0.13. It may also be viewed online at http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-14.html Enjoy! ============================================================================== Changes in MySQL 8.0.14 (2019-01-21, General Availability) * Account Management Notes * Audit Log Notes * Compilation Notes * Component Notes * Configuration Notes * Deprecation and Removal Notes * Function Notes * Logging Notes * Optimizer Notes * Packaging Notes * Performance Schema Notes * Pluggable Authentication * Security Notes * Spatial Data Support * SQL Syntax Notes * Thread Pool Notes * X Plugin Notes * Functionality Added or Changed * Bugs Fixed Account Management Notes * Previously, each MySQL user account was permitted to have a single password. MySQL now permits an account to have dual passwords, designated as primary and secondary passwords. This capability enables phased password changes to be performed seamlessly in complex multiple-server systems, without downtime. To support dual-password capability, the ALTER USER and SET PASSWORD statements now have a RETAIN CURRENT PASSWORD clause that saves the current password as the secondary password when you assign an account a new primary password. ALTER USER also has a DISCARD OLD PASSWORD clause to discard a secondary password that is no longer needed. See Password Management (http://dev.mysql.com/doc/refman/8.0/en/password-management.html). Important The implementation of dual-password capability involves a change to the structure of the mysql.user system table. If you upgrade to this MySQL release from an earlier version, you must run mysql_upgrade (and restart the server) to incorporate this system database change. Until this is done, password changes are not possible. Audit Log Notes * The audit API now enables applications to add their own message events to the audit log using the new audit_api_message_emit component, which includes an audit_api_message_emit_udf() user-defined function. See The Audit Message Component (http://dev.mysql.com/doc/refman/8.0/en/audit-api-message-emit.html). Compilation Notes * The minimum version of the Boost library for server builds is now 1.68.0. (Bug #28478497) Component Notes * A new host_application_signal component service is available to enable server components to deliver signals to the host application. For example, the service enables replication components to send a shutdown signal to the server. Configuration Notes * The content of the .gitignore file has been cleaned up. Much of this file was inherited from its .bzrignore predecessor and was not relevant. One implication of this cleanup is that in-source builds are disallowed. (Bug #28341794, Bug #91626) * MySQL Server now permits a TCP/IP port to be configured specifically for administrative connections. This provides an alternative to the single administrative connection that is permitted on the network interfaces used for ordinary connections even when max_connections connections are already established. The administrative network interface has these characteristics: + The interface is available only if the admin_address system variable is set at startup to indicate the IP address for the administrative interface. + The admin_port system variable specifies the interface TCP/IP port number (default 33062). + There is no limit on the number of administrative connections. + Connections are permitted only by users who have the SERVICE_CONNECTION_ADMIN privilege. The create_admin_listener_thread enables DBAs to choose whether the administrative interface is implemented using the listener thread used for ordinary connections (this is the default), or has its own separate thread. Thanks to Facebook for suggesting the idea (and for contributing code, although it was not used). (Bug #27847672, Bug #90395) Deprecation and Removal Notes * The deprecated resolveip and resolve_stack_dump utilities have been removed and are no longer included in MySQL distributions. nslookup, host, or dig can be used instead of resolveip. Stack traces from official MySQL builds are always symbolized, so there is no need to use resolve_stack_dump. Function Notes * The JSON_ARRAYAGG() and JSON_OBJECTAGG() aggregate functions now can be used as window functions, if an OVER clause is present. See Aggregate (GROUP BY) Function Descriptions (http://dev.mysql.com/doc/refman/8.0/en/group-by-functions.html). Logging Notes * A new system variable, log_slow_extra, if enabled, causes the server to write additional fields to slow query log lines that provide information about slow statements. In addition, SET lines written to the log to indicate statement timestamps now use the time from the beginning of statement execution, rather than the time at the end of execution. See The Slow Query Log (http://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html). Thanks to Facebook for the contribution on which this feature is based. (Bug #27535580, Bug #89637) * Server logging behavior has changed with respect to error log messages generated prior to processing startup options that specify logging configuration. Previously, the server generated messages with the default timestamp, format, and verbosity level; buffered them; and then flushed them after the error log configuration became known. Because these early messages used the default logging configuration, they could differ from what is specified by the startup options. Now, the server buffers log events rather than formatted log messages. This enables it to retroactively apply configuration settings to those events after the settings are known, with the result that flushed messages use the configured settings, not the defaults. For more information, see Error Log Message Format (http://dev.mysql.com/doc/refman/8.0/en/error-log-format.html). Optimizer Notes * Previously, derived tables and common table expressions could not contain outer references. Outer references are now permitted. Packaging Notes * Ubuntu 18.10 and Fedora 29 install OpenSSL 1.1.1 by default, but OpenSSL 1.1.1 is not fully supported by MySQL. To install MySQL, the OpenSSL 1.0.2 compatibility package must be installed. (Bug #28981868) Performance Schema Notes * The Performance Schema statement event tables (events_statements_current, events_statements_history, and events_statements_history_long) now have a STATEMENT_ID column that indicates the query ID maintained by the server at the SQL level. Column values are unique for the server instance because they are generated using a global counter that is incremented atomically. Pluggable Authentication * If the LDAP port number is configured as 636 or 3269, the plugin now uses LDAPS (LDAP over SSL) instead of LDAP. The port number is settable using the authentication_ldap_sasl_server_port or authentication_ldap_simple_server_port system variable. (LDAPS differs from startTLS.) (Bug #28743563) * Previously, for LDAP authentication with proxying, LDAP authentication plugins used the first group name returned by the LDAP server as the MySQL proxy user account name. The authentication string for a MySQL account now can specify a list of groups to match, in preference order, and can optionally map the matching group name to a specified MySQL proxy user name. See LDAP Pluggable Authentication (http://dev.mysql.com/doc/refman/8.0/en/ldap-pluggable-authentication.html). Security Notes * The OpenSSL libraries bundled with MySQL on some platforms (Windows, macOS, and Generic Linux) have been upgraded to version 1.0.2q. On all other platforms, MySQL uses the system installed OpenSSL. Issues fixed in the new OpenSSL version are described at http://www.openssl.org/news/vulnerabilities.html. (Bug #28988091) * To affect subsequent server restarts, the SET PERSIST and SET PERSIST_ONLY statements enable system variables to be persisted to the mysqld-auto.cnf option file in the data directory. However, some system variables cannot be persisted (for example, because they involve sensitive data). Consequently, they cannot be set at runtime from within a session conducted by a remote administrator, and thus require the administrator to log into the server host and directly modify a my.cnf option file. MySQL now permits users to perform runtime administration of many previously nonpersistible system variables, so that they can be persisted under certain restrictive conditions. To enable this capability, designate an SSL certificate X.509 Subject value that signifies the ability to persist these restricted system variables, and set the new persist_only_admin_x509_subject system variable to that Subject value. Users who connect to the server using an encrypted connection and supply an SSL certificate with the designated Subject value then can use SET PERSIST_ONLY to persist persist-restricted system variables. For more information, see Nonpersistible and Persist-Restricted System Variables (http://dev.mysql.com/doc/refman/8.0/en/nonpersistible-system-variables.html). * For most system variables, setting the session value requires no special privileges and can be done by any user to affect the current session. For some system variables, setting the session value can have effects outside the current session and thus is a restricted operation that can be done only by users who have a special privilege. Previously, either SYSTEM_VARIABLES_ADMIN or SUPER qualified as such a privilege, but both privileges also permit operations other than setting session variables. The new SESSION_VARIABLES_ADMIN privilege makes it possible to grant users only the ability to set restricted session variables without also enabling other operations. Any operation permitted by SESSION_VARIABLES_ADMIN is also permitted by SYSTEM_VARIABLES_ADMIN or SUPER, so any user who already has one of the latter privileges effectively has SESSION_VARIABLES_ADMIN by implication and need not be granted SESSION_VARIABLES_ADMIN explicitly. However, if a user has been granted SYSTEM_VARIABLES_ADMIN or SUPER only for the purpose of enabling that user to modify restricted session system variables, an administrator can reduce the user's privilege footprint by revoking SYSTEM_VARIABLES_ADMIN and SUPER, and granting SESSION_VARIABLES_ADMIN instead. For instructions, see System Variable Privileges (http://dev.mysql.com/doc/refman/8.0/en/system-variable-privileges.html). These previously restricted session variables required SYSTEM_VARIABLES_ADMIN or SUPER but now can also be set with SESSION_VARIABLES_ADMIN: binlog_format binlog_row_image binlog_row_value_options binlog_rows_query_log_events debug debug_sync default_collation_for_utf8mb4 explicit_defaults_for_timestamp gtid_next histogram_generation_max_mem_size original_commit_timestamp sql_log_bin sql_log_off sql_require_primary_key These previously unrestricted session variables now are restricted and setting them requires at least SESSION_VARIABLES_ADMIN (they can also be set by users who have SYSTEM_VARIABLES_ADMIN or SUPER): auto_increment_increment auto_increment_offset binlog_direct_non_transactional_updates bulk_insert_buffer_size character_set_filesystem character_set_database collation_database pseudo_slave_mode pseudo_thread_id rbr_exec_mode transaction_write_set_extraction Spatial Data Support * The ST_Distance() function now takes an optional third argument enabling the unit for the return value to be specified. Permitted units are those listed in the new INFORMATION_SCHEMA ST_UNITS_OF_MEASURE table. See Spatial Relation Functions That Use Object Shapes (http://dev.mysql.com/doc/refman/8.0/en/spatial-relation-functions-object-shapes.html), and The INFORMATION_SCHEMA ST_UNITS_OF_MEASURE Table (http://dev.mysql.com/doc/refman/8.0/en/st-units-of-measure-table.html). SQL Syntax Notes * A derived table now may be preceded by the LATERAL keyword to specify that it is permitted to refer to (depend on) columns of preceding tables in the same FROM clause. A derived table specified with LATERAL can occur only in a FROM clause, either in a list of tables separated with commas or in a join specification (JOIN, INNER JOIN, CROSS JOIN, LEFT [OUTER] JOIN, or RIGHT [OUTER] JOIN). Lateral derived tables make possible certain SQL operations that cannot be done with nonlateral derived tables or that require less-efficient workarounds. See Lateral Derived Tables (http://dev.mysql.com/doc/refman/8.0/en/lateral-derived-tables.html). Note LATERAL now is a reserved word and cannot be used as an identifier without identifier quoting. Thread Pool Notes * The INFORMATION_SCHEMA tables that accompany the thread pool plugin have been migrated to be available as Performance Schema tables. The INFORMATION_SCHEMA tables now are deprecated and will be removed in a future MySQL version. Applications should transition away from the old tables to the new tables. For example, if an application uses this query: SELECT * FROM INFORMATION_SCHEMA.TP_THREAD_STATE; The application should use this query instead: SELECT * FROM performance_schema.tp_thread_state; For more information, see Performance Schema Thread Pool Tables (http://dev.mysql.com/doc/refman/8.0/en/performance-schema-thread-pool-tables.html). X Plugin Notes * X Plugin now includes the 5-digit SQLSTATE error code in its error handling class. Previously, the SQLSTATE error code was returned to clients for SQL errors, but only the MySQL-specific error number was exposed. (Bug #28735058) * When querying collections of documents, if boolean values were used as arguments for a placeholder in an SQL query, unexpected results were returned. A new translation specialization has now been added for boolean values so that they are handled correctly in this situation. (Bug #28227037) * X Protocol now always converts retrieved data to the utf8mb4 character set (using the utf8mb4_general_ci collation) before returning it. (Bug #28180155) * X Protocol now supports SQL prepare functionality. Functionality Added or Changed * InnoDB: To reduce the size of core files, the innodb_buffer_pool_in_core_file variable can be disabled to prevent InnoDB buffer pool pages from being written to core files. Thanks to Facebook for the contribution. (Bug #27724476, Bug #90144) * InnoDB: By default, undo logs reside in two undo tablespaces that are created when the MySQL instance is initialized. Additional undo tablespaces can be created in a chosen location at runtime using CREATE UNDO TABLESPACE syntax. CREATE UNDO TABLESPACE tablespace_name ADD DATAFILE 'file_name.ibu'; Undo tablespaces created using CREATE UNDO TABLESPACE syntax can be dropped at runtime using DROP UNDO TABLESPACE syntax. DROP UNDO TABLESPACE tablespace_name; ALTER UNDO TABLESPACE syntax can be used to mark an undo tablespace as active or inactive. ALTER UNDO TABLESPACE tablespace_name SET {ACTIVE|INACTIVE}; A STATE column that shows the state of a tablespace was added to the INFORMATION_SCHEMA.INNODB_TABLESPACES table. An undo tablespace must be in an empty state before it can be dropped. The previously deprecated innodb_undo_tablespaces variable is no longer configurable and will be removed in a future release. For more information, see Undo Tablespaces (http://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html). * InnoDB: InnoDB now supports parallel clustered index reads, which can improve CHECK TABLE performance. This feature does not apply to secondary index scans. The innodb_parallel_read_threads session variable must be set to a value greater than 1 for parallel clustered index reads to occur. The default value is 4. The actual number of threads used to perform a parallel clustered index read is determined by the innodb_parallel_read_threads setting or the number of index subtrees to scan, whichever is smaller. * InnoDB: The ADD DATAFILE clause of the CREATE TABLESPACE statement is now optional, which permits users without the FILE privilege to create tablespaces. A CREATE TABLESPACE statement executed without an ADD DATAFILE clause implicitly creates a tablespace data file with a unique file name. * InnoDB: When the innodb_dedicated_server variable is enabled, the size and number of log files are now configured according to the automatically configured buffer pool size. Previously, log file size was configured according to the amount of memory detected on the server, and the number of log files was not configured automatically. * Replication: When running a group in single-primary mode, in the event of a new primary being elected while there were transactions held in the backlog to be applied, there was a chance that a read operation against the new primary could return a stale value. Now, you can use the group_replication_consistency variable to control how a group behaves in this situation. When group_replication_consistency is set to EVENTUAL, a new primary responds to read requests even when there is a backlog which has not yet been applied, which matches the previous behavior and comes with the risk that a client could read old values while any backlog is being applied. Writes to the new primary fail during this period because it is has super_read_only mode enabled. When group_replication_consistency is set to BEFORE_ON_PRIMARY_FAILOVER, any new read or write queries against a newly elected primary that is applying backlog from the old primary are held until the backlog is applied. This ensures that clients always read the newest value which they have written, but also means that clients might have to wait until the backlog has been applied before they can read from the new primary. References: See also: Bug #26004894. * Microsoft Windows: The access control granted to clients on the named pipe created by the MySQL server now is set to the minimum necessary for successful communication on Windows. Newer MySQL client software can open named pipe connections without any additional configuration. If older client software cannot be upgraded immediately, the new named_pipe_full_access_group server system variable can be used to give a Windows group the necessary permissions to open a named pipe connection. Membership in the full-access group should be restricted and temporary. * The minimal server RPM is mostly used for Docker images. For better Docker compatibility, the log-error line has been removed from the rpm-docker configuration file. This way, logging goes to stdout/stderr, enabling use of Docker's own interface. (Bug #28692675) * Error messages relating to creating and dropping foreign keys were improved to be more specific and informative. (Bug #28526309, Bug #92087) * The error message for ALTER TABLE statements that attempted character set conversion but failed was improved to indicate which column produced the error. (Bug #27546306, Bug #88738) * Previously, for command options that take a numeric value, the value could be given with a suffix of K, M, or G to indicate a multiplier of 1024, 1024^2 or 1024^3. Now a suffix can also be T, P, and E to indicate a multiplier of 1024^4, 1024^5 or 1024^6. Thanks to Daniel Black for the patch. (Bug #27306931, Bug #89017) * Resource group locking was revised to improve scalability and performance. (Bug #27148580) * The Group Communication System (GCS) and group communication engine (XCom, a Paxos variant) for Group Replication now provide full support for IPv6, so replication group members can use IPv6 addresses as an alternative to IPv4 addresses for internal group communications. The localhost address for IPv6, and the private subnetwork addresses for IPv6 (unique-local addresses and link-local unicast addresses), are added to the automatic whitelist for Group Replication for use if no manual whitelist is specified. If all members of a replication group are at a MySQL server version that supports the use of IPv6 addresses for Group Replication, the group can contain a mix of members using IPv6 addresses and members using IPv4 addresses. Joining members must provide whitelisted IP addresses or host names that match the protocols offered by the seed members for connection, but the joining member's main identifying address or host name (group_replication_local_address) can use either protocol. If a member uses a host name that resolves to both an IPv4 and an IPv6 address, the IPv4 address is always used for Group Replication connections. If any or all existing members of a replication group are using an older MySQL Server version without support for the use of IPv6 addresses for Group Replication, joining members must present an IPv4 address for group communications in the group_replication_local_address option. When every group member has been upgraded, the group can be migrated to IPv6 addresses. (Bug #26088469, Bug #27757729, Bug #90217) * MySQL Group Replication can now communicate using a dedicated input channel as an alternative to using a TCP socket. The new input channel uses shared memory for communication between the Group Replication logic and the local instance of the underlying group communication engine (XCom, a Paxos variant). Previously, communication with the local XCom instance always took place using a TCP socket, namely the network address that is specified by the group_replication_local_address system variable for each group member. This incurred overheads that were unnecessary for local communication, such as memory copying through the network protocol stack and data serialization. A TCP socket (group_replication_local_address) is still required for each group member to communicate with remote XCom instances. The Group Communication System (GCS) component of Group Replication now selects the most appropriate communication method for each Group Replication task, either the input channel or TCP. For example, the process of joining a group requires communication with a remote XCom instance, so TCP must be used. However, the process of removing a member from a group only requires communication with the local XCom instance, so the input channel is used. The input channel is selected wherever possible to minimize the overheads associated with communication using networking mechanisms. * Two new session system variables have been added for internal use by replication. original_server_version and immediate_server_version support cross-version replication by transmitting the MySQL server release numbers associated with a transaction through the replication topology. original_server_version holds the MySQL Server release number of the server where a transaction was originally committed (for example, 80014 for a MySQL 8.0.14 server instance). immediate_server_version holds the MySQL Server release number of the server that is the immediate master in a replication topology. If either of those servers, or another intervening server in the replication topology, is at an older release that does not support these session system variables, their values are set to 0. With this information the slave can correctly process data originating from a master at an older release, by recognizing where syntax changes or semantic changes have occurred between the releases involved and handling these appropriately. The information can also be used in a Group Replication environment where one or more members of the replication group is at a newer release than the others. The value of the variable can be viewed in the binary log for each transaction (as part of the Gtid_log_event, or Anonymous_gtid_log_event if GTIDs are not in use on the server), and could be helpful in debugging cross-version replication issues. * The startup option --binlog-row-event-max-size now has a corresponding system variable binlog_row_event_max_size. The startup option and system variable set a soft limit on the maximum size of a row-based binary log event, with a default setting of 8192 bytes. Where possible, rows stored in the binary log are grouped into events with a size not exceeding the value of this setting. If an event cannot be split, the maximum size can be exceeded. The binlog_row_event_max_size global system variable is read-only and can be set only at server startup. Its value can therefore only be modified by using the PERSIST_ONLY keyword or the @@persist_only qualifier with the SET statement. The addition of a system variable means that this setting can be viewed using the Performance Schema tables or a SHOW VARIABLES or SELECT statement. * Binary log files and relay log files can now be encrypted, helping to protect these files and the potentially sensitive data contained in them from being misused by outside attackers, and also from unauthorized viewing by users of the operating system where they are stored. You enable encryption on a MySQL server by setting the new binlog_encryption system variable to ON. OFF is the default. The system variable sets encryption on for binary log files and relay log files. When you first start the server with encryption enabled, a new binary log encryption key is generated before the binary log and relay logs are initialized. This key is used to encrypt a file password for each binary log file (if the server has binary logging enabled) and relay log file (if the server has replication channels), and further keys generated from the file passwords are used to encrypt the data in the files. If you activate encryption while the server is running, a new binary log encryption key is generated at that time, and the binary log files and relay log files are rotated so that the new and subsequent files are encrypted. If you deactivate encryption by changing the binlog_encryption system variable to OFF, the binary log file and relay log files are rotated immediately and all subsequent logging is unencrypted. Previously encrypted files are not automatically decrypted, but the server is still able to read them. (The SHOW BINARY LOGS statement now shows whether each binary log file is encrypted or unencrypted.) SUPER privileges or the new BINLOG_ENCRYPTION_ADMIN privilege are required to activate or deactivate encryption while the server is running. The encryption algorithm used for the files, the AES (Advanced Encryption Standard) cipher algorithm, is built in to MySQL Server and cannot be configured. The binary log encryption keys used to encrypt the file passwords for the log files are 256-bit keys that are generated specifically for each MySQL server instance using MySQL Server's built-in keyring service. The binary log encryption key that is currently in use on the server is called the binary log master key. The new binlog_rotate_encryption_master_key_at_startup system variable controls whether the binary log master key is automatically rotated when the server is restarted. If this system variable is set to ON, a new binary log encryption key is generated and used as the new binary log master key whenever the server is restarted. If it is set to OFF, which is the default, the existing binary log master key is used again after the restart. Note that when encryption is active for a MySQL server instance, only the data at rest that is written to the binary log files and relay log files is encrypted. The data in motion in the replication event stream, which is sent to MySQL clients including mysqlbinlog, is always in unencrypted format, so it must be protected in transit by the use of connection encryption. The data in use that is held in the binary log transaction and statement caches during a transaction, and any data that exceeds the space available in those caches and is therefore stored in a temporary file on disk, is also in unencrypted format. The temporary files and caches are deleted when the thread that handles the transaction ends. * ALTER TABLE now can be used to change a column character set in place (without a table rebuild), when these conditions apply: + The column data type is CHAR, VARCHAR, a TEXT type, or ENUM. + The character set change is from utf8mb3 to utf8mb4, or any character set to binary. + There is no index on the column. * The new -DFORCE_INSOURCE_BUILD CMake option defines whether to force an in-source build. Out-of-source builds are recommended, as they permit multiple builds from the same source, and cleanup can be performed quickly by removing the build directory. To force an in-source build, invoke CMake with -DFORCE_INSOURCE_BUILD=ON. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
