[Due to size limitations, the announcement is split in 2. This is part 1.] Dear MySQL users,
MySQL Server 8.0.3-rc (Release Candidate) is a new version of the world's most popular open source database. This is the first release candidate of MySQL 8.0. http://dev.mysql.com/doc/mysql-development-cycle/en/development-milestone-releases.html As with any other pre-production release, caution should be taken when installing on production level systems or systems with critical data. Note that 8.0.3-rc includes all features in MySQL 5.7. For information on installing MySQL 8.0.3-rc on new servers, please see the MySQL installation documentation at http://dev.mysql.com/doc/refman/8.0/en/installing.html MySQL Server 8.0.3-rc is available in source and binary form for a number of platforms from the "Development Releases" selection of our download pages at http://dev.mysql.com/downloads/mysql/ MySQL Server 8.0.3-rc 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.3-rc 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.2. It may also be viewed online at http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-3.html Enjoy! ============================================================================== Changes in MySQL 8.0.3 (2017-09-21, Release Candidate) Note This is a milestone release, for use at your own risk. Upgrades between milestone releases (or from a milestone release to a GA release) are not supported. Significant development changes take place in milestone releases and you may encounter compatibility issues, such as data format changes that require attention in addition to the usual procedure of running mysql_upgrade. For example, you may find it necessary to dump your data with mysqldump before the upgrade and reload it afterward. * C API Notes * Character Set Support * Compilation Notes * Configuration Notes * Data Dictionary Notes * Deprecation and Removal Notes * InnoDB Notes * Optimizer Notes * Packaging Notes * Performance Schema Notes * Security Notes * Spatial Data Support * SQL Syntax Notes * X Plugin Notes * Functionality Added or Changed * Bugs Fixed C API Notes * The MySQL C API now enables clients to specify that metadata transfer for result sets is optional. Suppression of metadata transfer can improve performance, particularly for sessions that execute many queries that return few rows each. For more information, see C API Optional Result Set Metadata (http://dev.mysql.com/doc/refman/8.0/en/c-api-optional-metadata.html). Character Set Support * MySQL now supports Russian collations for the utf8mb4 Unicode character set: + utf8mb4_ru_0900_ai_ci is accent insensitive and case insensitive. + utf8mb4_ru_0900_as_cs is accent sensitive and case sensitive. Compilation Notes * For debug builds, the SAFE_MUTEX compilation flag was disabled if the memcached plugin was included in the build. This no longer occurs; SAFE_MUTEX is always enabled for debug builds. Some code issues found as a result of this change were corrected. (Bug #26442367, Bug #87068) * Binary packages on EL6 and EL7 now are compiled using Devtoolset 6 rather than Devtoolset3 and GCC 6.2.1 rather than 4.9.2. (Bug #26436968, Bug #87061) * MySQL now compiles for SPARC on Oracle Linux. (Bug #26306331, Bug #86745) * MySQL compilation on macOS using Clang now requires a Clang version different from 8.0, which has problems with certain inline constructs. (Bug #26279510, Bug #86711) * Work was done to clean up the source code base, including: Removing unneeded CMake checks; removing unused macros from source files; reorganizing header files to reduce the number of dependencies and make them more modular, removing function declarations without definitions, replacing locally written functions with equivalent functions from industry-standard libraries. Configuration Notes * The performance_schema_max_mutex_classes system variable default value was increased from 220 to 250. The performance_schema_max_thread_classes system variable default value was increased from 50 to 100. (Bug #26193630) * The new cte_max_recursion_depth system variable implements a common table expression (CTE) maximum recursion depth. The server terminates execution of any CTE that recurses more levels than the value of this variable. For more information, see Limiting Common Table Expression Recursion (http://dev.mysql.com/doc/refman/8.0/en/with.html#common-table-expressions-recursion-limits). (Bug #26136509, Bug #86444) * The back_log system variable default value is now the value of max_connections, which enables the permitted backlog to adjust to the maximum permitted number of connections. * To enable the Event Scheduler by default, the event_scheduler system variable default value was changed from OFF to ON. * The max_allowed_packet system variable default value was increased from 4194304 (4M) to 67108864 (64M). * The max_error_count system variable default variable was increased from 64 to 1024. Data Dictionary Notes * These INFORMATION_SCHEMA tables have been reimplemented as views on data dictionary tables: FILES PARTITIONS REFERENTIAL_CONSTRAINTS Queries on those tables are now more efficient because they obtain information from data dictionary tables rather than by other, slower means. For example, the server no longer must create a temporary table for each query of the INFORMATION_SCHEMA table. Also as a result of this change, foreign key information is retrieved from the data dictionary, not from InnoDB. If you upgrade to this MySQL release from an earlier version, you must run mysql_upgrade (and restart the server) to incorporate these changes. (Bug #25583288) * Crash safety was improved for CREATE and DROP operations, and, if applicable, ALTER operations for stored programs (other than triggers), views, and user-defined functions (UDFs). The exception for triggers is made because trigger operations are already atomic. A behavior change for DROP VIEW occurs if any named views do not exist. Previously, the statement returned an error indicating which views did not exist and it was unable to drop, but also dropped the views that did exist. Now the statement still indicates which views did not exist, but fails with an error and no changes are made. Deprecation and Removal Notes * Replication: The deprecated global scope for the sql_log_bin system variable has been removed. sql_log_bin now has session scope only. Applications that rely on accessing @@global.sql_log_bin should be adjusted. * These encryption-related deprecated items have been removed: + The ENCODE() and DECODE() functions. + The ENCRYPT function. + The DES_ENCRYPT(), and DES_DECRYPT() functions, the --des-key-file option, the have_crypt system variable, the DES_KEY_FILE option for the FLUSH statement, and the HAVE_CRYPT CMake option. In place of the removed encryption functions, consider using AES_ENCRYPT() and AES_DECRYPT() instead. (Bug #26493987) * The deprecated tx_isolation and tx_read_only system variables have been removed. Use transaction_isolation and transaction_read_only instead. * The deprecated query cache has been removed. Removal includes these items: + The FLUSH QUERY CACHE and RESET QUERY CACHE statements. + These system variables: query_cache_limit, query_cache_min_res_unit, query_cache_size, query_cache_type, query_cache_wlock_invalidate. + These status variables: Qcache_free_blocks, Qcache_free_memory, Qcache_hits, Qcache_inserts, Qcache_lowmem_prunes, Qcache_not_cached, Qcache_queries_in_cache, Qcache_total_blocks. + These thread states: checking privileges on cached query, checking query cache for query, invalidating query cache entries, sending cached result to client, storing result in query cache, Waiting for query cache lock. These deprecated query cache items remain deprecated, but have no effect, and will be removed in a future MySQL release: + The SQL_CACHE and SQL_NO_CACHE SELECT modifiers. + The ndb_cache_check_time system variable. The have_query_cache system variable remains deprecated, always has a value of NO, and will be removed in a future MySQL release. * The deprecated EXTENDED and PARTITIONS keywords for the EXPLAIN statement have been removed. These keywords are unnecessary because their effect is always enabled. * The unused date_format, datetime_format, time_format, and max_tmp_tables system variables have been removed. * The deprecated multi_range_count system variable has been removed. * The deprecated log_warnings system variable and --log-warnings server option have been removed. Use the log_error_verbosity system variable instead. * The deprecated secure_auth system variable and --secure-auth client option have been removed. The MYSQL_SECURE_AUTH option for the mysql_options() C API function was removed. * The deprecated --ignore-builtin-innodb server option and ignore_builtin_innodb system variable have been removed. InnoDB Notes * Renaming of columns in a parent foreign key is temporarily disabled due to ongoing work on foreign key locking. This restriction will be lifted in MySQL 8.0.4. (Bug #26334071) References: See also: Bug #26659110. Optimizer Notes * The optimizer now supports a SET_VAR hint that sets the session value of a system variable for the duration of a single statement. Examples: SELECT /*+ SET_VAR(sort_buffer_size = 16M) */ name FROM people ORDER B Y name; INSERT /*+ SET_VAR(foreign_key_checks=OFF) */ INTO t2 VALUES(2); For more information, see Optimizer Hints (http://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). * The optimizer now uses column-value histogram statistics stored in the column_statistics data dictionary table to construct query execution plans. Histogram use applies to predicates involving comparison of a column to a constant. See Optimizer Statistics (http://dev.mysql.com/doc/refman/8.0/en/optimizer-statistics.html). * Previously, there was no way of skipping the use of index dives to estimate index usefulness, except by using the eq_range_index_dive_limit system variable. Now index dive skipping is possible for single-table queries under certain query conditions (see Range Optimization (http://dev.mysql.com/doc/refman/8.0/en/range-optimization.html)). * The optimizer_switch system variable has a new flag named use_invisible_indexes to control whether the optimizer uses invisible indexes for query execution plan construction. If the flag is off (the default), the optimizer ignores invisible indexes (the same behavior as prior to the introduction of this flag). If the flag is on, invisible indexes remain invisible but the optimizer takes them into account for execution plan construction. Packaging Notes * mysqlcheck was missing in the MySQL Server Docker image, which prevented mysql_upgrade from running. (Bug #26400146, Bug #86968) * For Debian, non-debug binaries were moved from the mysql-server package to the mysql-server-core package. (Bug #26382333) * The Debian/Ubuntu mysql-community-source package is no longer produced because the MySQL source tarball it contained is provided by other packages at dev.mysql.com. (Bug #26201482) Performance Schema Notes * As of MySQL 8.0.2, Performance Schema table definitions are maintained internally to the server. In consequence of that change, CREATE TABLE and DROP TABLE are no longer possible for Performance Schema tables. (Bug #26136994) * The events_statements_summary_by_digest table now provides, for each row, a sample statement that produces the digest value in the row. Applications can use this information as a more efficient means of capturing statement samples than alternatives such as probing the xxx_history_long tables. The latter approach requires enabling the corresponding xxx_history_long consumers, which is additional overhead for applications that do not otherwise need those tables. For more information, see Performance Schema Statement Digests and Sampling (http://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-digests.html), and Statement Summary Tables (http://dev.mysql.com/doc/refman/8.0/en/statement-summary-tables.html). Additionally, the FIRST_SEEN and LAST_SEEN timestamp columns of the events_statements_summary_by_digest table now have a fractional seconds part. * The Performance Schema setup_instruments table now has columns for instrument metadata: Instrument properties, instrument volatility, and a documentation string describing the the instrument purpose. Also, the TIMED column now can be NULL, indicating that the instrument does not support timing. See The setup_instruments Table (http://dev.mysql.com/doc/refman/8.0/en/setup-instruments-table.html). The new Performance Schema setup_threads table exposes instrumented thread class names and attributes. See The setup_threads Table (http://dev.mysql.com/doc/refman/8.0/en/setup-threads-table.html). Security Notes * A new caching_sha2_password authentication plugin is available. Like the sha256_password plugin, caching_sha2_password implements SHA-256 password hashing, but uses caching to address latency issues at connect time. It also supports more connection protocols and does not require linking against OpenSSL for RSA password-exchange capabilities. See SHA-2 Pluggable Authentication (http://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authentication.html). * MySQL now maintains information about password history, enabling DBAs to require that new passwords not reuse old ones for some number of password changes or period of time. It is possible to establish password-reuse policy globally using the password_history and password_reuse_interval system variables, as well as on a per-account basis using the CREATE USER and ALTER USER statements. Together with existing password-expiration capabilities to require that passwords be changed periodically, the new password-history capabilities provide DBAs more complete control over password management. For more information, see Password Management (http://dev.mysql.com/doc/refman/8.0/en/password-management.html). Important MySQL implements password-reuse restrictions by means of new columns in the mysql.user system table and a new mysql.password_history system table. If you upgrade to this MySQL release from an earlier version, you must run mysql_upgrade (and restart the server) to incorporate these system database changes. Until this is done, password changes will not be possible. * If the server is started with the --skip-grant-tables option to disable authentication checks, the server now enables --skip-networking to prevent remote connections. Spatial Data Support * Incompatible Change: Previously, these functions that test geometry relationships supported only Cartesian spatial reference systems (SRSs): ST_Contains(), ST_Crosses(), ST_Disjoint(), ST_Equals(), ST_Intersects(), ST_Overlaps(), ST_Touches(), ST_Within(), MBRContains(), MBRCoveredBy(), MBRCovers(), MBRDisjoint(), MBREquals(), MBRIntersects(), MBROverlaps(), MBRTouches(), MBRWithin(). These functions now detect geometry arguments in a geographic (ellipsoidal) SRS and return geographic results. Calculations for projected SRSs and SRID 0 remain the same. For more information, see Spatial Relation Functions That Use Object Shapes (http://dev.mysql.com/doc/refman/8.0/en/spatial-relation-functions-object-shapes.html), and Spatial RelationFunctions That Use Minimum Bounding Rectangles (http://dev.mysql.com/doc/refman/8.0/en/spatial-relation-functions-mbr.html). Note If spatial data contains SRID values that refer to a geographic spatial reference system, existing queries using these functions will return different results, compared to previous MySQL versions. * InnoDB: Spatial reference identifier (SRID) support was added for InnoDB spatial indexes. * Spatial data types now permit an SRID attribute, to explicitly indicate the spatial reference system (SRS) for values stored in the column. See Spatial Data Types (http://dev.mysql.com/doc/refman/8.0/en/spatial-datatypes.html). To indicate each column's SRID attribute value, if there is one, the INFORMATION_SCHEMA.COLUMNS table now has an SRS_ID column. A spatial column with an explicit SRID attribute is SRID-restricted: The column takes only values with that ID, and SPATIAL indexes on the column become subject to use by the optimizer. The optimizer ignores SPATIAL indexes on spatial columns with no SRID attribute. See SPATIAL Index Optimization (http://dev.mysql.com/doc/refman/8.0/en/spatial-index-optimization.html). SQL Syntax Notes * ALTER TABLE now supports easier column renaming using RENAME COLUMN old_name TO new_name syntax. See ALTER TABLE Syntax (http://dev.mysql.com/doc/refman/8.0/en/alter-table.html). For changing a column name but not its definition, RENAME COLUMN is more convenient than CHANGE, which requires respecifying the current column definition. With CHANGE, you must look up the definition if you do not know it, and if you do not respecify it exactly, there is a possibility of data change or loss. (Bug #11746522, Bug #26949, Bug #11747473, Bug #32497, Bug #11765084, Bug #58006, Bug #14031617) X Plugin Notes * The X Plugin could not be installed when the server was started with the --skip-grant-tables option. (Bug #26516678) * X Plugin socket connections were not working correctly. (Bug #26427112, Bug #87019) * When compiling MySQL from source, certain infrequently used CMake arguments caused issues for the X Plugin build. (Bug #26141933) * A Mysqlx.Connection.CapabilitiesGet request using MySQL X Protocol did not return the complete list of available authentication mechanisms. (Bug #26044113) * For mixed case or uppercase schema names, the statement list_objects could incorrectly report a collection as a table. (Bug #25769683) * The X Plugin was omitted from the list of plugins to include for testing data directory permissions. (Bug #24823999) Functionality Added or Changed * InnoDB: InnoDB now supports atomic DDL, which ensures that DDL operations are either committed in their entirety or rolled back in case of an unplanned server stoppage. This feature applies to the following statements: + ALTER TABLE + CREATE INDEX + CREATE TABLE + CREATE TABLESPACE + DROP INDEX + DROP TABLE + DROP TABLESPACE + RENAME TABLE + TRUNCATE TABLE Recovery logs for atomic DDL operations are written to the mysql.innodb_ddl_log data dictionary table. Enabling the innodb_print_ddl_logs configuration option prints DDL recovery logs to the error log. The introduction of atomic DDL prevents orphan temporary or intermediate tables from being left behind by failed ALTER TABLE operations. (Bug #24620918) * InnoDB: A new type of backup lock permits DML on InnoDB tables during an online backup while preventing operations on InnoDB files that could result in an inconsistent snapshot. The new backup lock is supported by LOCK INSTANCE FOR BACKUP and UNLOCK INSTANCE syntax. The BACKUP_ADMIN privilege is required to use these statements. * InnoDB: The new innodb_dedicated_server configuration option, which is disabled by default, causes InnoDB to automatically configure the following options according to the amount of memory detected on the server: + innodb_buffer_pool_size + innodb_log_file_size + innodb_flush_method This option is intended for MySQL server instances that run on a dedicated server. For more information, see Enabling Automatic Configuration for a Dedicated MySQL Server (http://dev.mysql.com/doc/refman/8.0/en/innodb-dedicated-server.html). * InnoDB: Renaming a general tablespace is now supported by ALTER TABLESPACE ... RENAME TO syntax. The ALTER TABLESPACE and DROP TABLESPACE ENGINE clause is deprecated and will be removed in a future release. * InnoDB: Code related to obsoleted InnoDB system tables was removed. INFORMATION_SCHEMA views based on InnoDB system tables were replaced by internal system views on data dictionary tables. Affected InnoDB INFORMATION_SCHEMA views were renamed: Table 1 Renamed InnoDB Information Schema Views Old Name New Name INNODB_SYS_COLUMNS INNODB_COLUMNS INNODB_SYS_DATAFILES INNODB_DATAFILES INNODB_SYS_FIELDS INNODB_FIELDS INNODB_SYS_FOREIGN INNODB_FOREIGN INNODB_SYS_FOREIGN_COLS INNODB_FOREIGN_COLS INNODB_SYS_INDEXES INNODB_INDEXES INNODB_SYS_TABLES INNODB_TABLES INNODB_SYS_TABLESPACES INNODB_TABLESPACES INNODB_SYS_TABLESTATS INNODB_TABLESTATS INNODB_SYS_VIRTUAL INNODB_VIRTUAL After upgrading to MySQL 8.0.3 or later, update any scripts that reference previous InnoDB INFORMATION_SCHEMA view names. INNODB_TABLESPACES_BRIEF, a new INFORMATION_SCHEMA view, provides space, name, path, flag, and space type data for InnoDB tablespaces. * InnoDB: When InnoDB was integrated with the global data dictionary, file-per-table tablespace names in the data dictionary were created in the form of innodb_file_per_table_x, where x is the InnoDB tablespace ID. For ease of use, file-per-table tablespace names in the data dictionary are once again the same as the table name. Upgrade from MySQL 5.7 to MySQL 8.0 appends MySQL 5.7 innodb_table_stats and innodb_index_stats tabelspace names in the data dictionary with "_backup57" to differentiate them from their MySQL 8.0 counterparts. * InnoDB: The default innodb_autoinc_lock_mode setting was changed from 1 (consecutive) to 2 (interleaved). Interleaved lock mode permits the execution of multi-row inserts in parallel, which improves concurrency and scalability. The new innodb_autoinc_lock_mode default setting reflects the change from statement-based replication to row based replication as the default replication type in MySQL 5.7. Statement-based replication requires the consecutive auto-increment lock mode to ensure that auto-increment values are assigned in a predictable and repeatable order for a given sequence of SQL statements, whereas row-based replication is not sensitive to the execution order of SQL statements. For more information, see InnoDB AUTO_INCREMENT Lock Modes (http://dev.mysql.com/doc/refman/8.0/en/innodb-auto-increment-handling.html#innodb-auto-increment-lock-modes). For systems that use statement-based replication, the new innodb_autoinc_lock_mode default setting may break applications that depend on sequential auto-increment values. To restore the previous default, set innodb_autoinc_lock_mode to 1. * InnoDB: Serialized Dictionary Information (SDI) is now present in all InnoDB tablespace files except for temporary tablespace and undo tablespace files. SDI is serialized metadata for schema, table, and tablespace objects. The presence of SDI data provides metadata redundancy. For example, dictionary object metadata may be extracted from tablespace files if the data dictionary becomes unavailable. SDI extraction is performed using the ibd2sdi tool. SDI data is stored in JSON format. The inclusion of SDI data in tablespace files increases tablespace file size. An SDI record requires a single index page, which is 16k in size by default. However, SDI data is compressed when it is stored to reduce the storage footprint. * InnoDB: The innodb_flush_neighbors default value was changed from 1 to 0, which disables flushing of neighboring pages from the buffer pool. A setting of 0 is optimal for non-rotational storage (SSD) devices where seek time is not a significant factor. For systems that use rotational storage (HDD), it is recommended to change the setting back to the previous default value of 1. * InnoDB: Default values for configuration options that affect buffer pool preflushing and flushing behavior were modified: + The innodb_max_dirty_pages_pct_lwm default value was changed to 10. The previous default value of 0 disables buffer pool preflushing. A value of 10 enables preflushing when the percentage of dirty pages in the buffer pool exceeds 10%. Enabling preflushing improves performance consistency. + The innodb_max_dirty_pages_pct default value was changed from 75 to 90. InnoDB attempts to flush data from the buffer pool so that the percentage of dirty pages does not exceed this value. The increased default value permits a greater percentage of dirty pages in the buffer pool. * InnoDB: The minimum innodb_undo_tablespaces value changed from 0 to 2. In previous releases, the system tablespace is used for rollback segments if innodb_undo_tablespaces is set to 0. A minimum value of 2 ensures that rollback segments are created in undo tablespaces instead of the system tablespace. For more information about undo tablespaces, see Configuring Undo Tablespaces (http://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespace.html). * Replication; JSON: Added the binlog_row_value_options system variable. Currently this variable can be unset, or set to the value PARTIAL_JSON. This causes MySQL's row-based replication to use a compact binary log format for each update modifying only a small portion of a JSON document and using any combination of JSON_SET(), JSON_REPLACE(), and JSON_REMOVE(). The compact format includes only the modified parts of the JSON document, not the full document, in the after-image used for the update in the binary log. If the modification requires more space than the full document, or if it is not possible to generate a partial update, the full document is used instead. See the description of the variable as well as Partial Updates of JSON Values (http://dev.mysql.com/doc/refman/8.0/en/json.html#json-partial-updates), for more information. * Replication: The IGNORE_SERVER_IDS option of the CHANGE MASTER TO statement is now deprecated when using GTID-based replication (gtid_mode=ON). With GTIDs, transactions that have already been applied are automatically ignored, so this function is not needed. Before starting GTID-based replication, check for and clear all ignored server ID lists that have previously been set on the servers involved. The SHOW_SLAVE_STATUS statement, which can be issued for individual channels, displays the list of ignored server IDs if there is one. If there is no list, the Replicate_Ignore_Server_Ids field is blank. If gtid_mode=ON is set for the server, a deprecation warning is now issued if you include the IGNORE_SERVER_IDS option in a CHANGE MASTER TO statement. A deprecation warning is also issued if you issue a SET GTID_MODE=ON statement when any channel has existing server IDs set with IGNORE_SERVER_IDS. If you do receive the deprecation warning, you can still clear a list after gtid_mode=ON is set by issuing a CHANGE MASTER TO statement containing the IGNORE_SERVER_IDS option with an empty list. * Replication: The following obsolete mysqlbinlog options are now deprecated and will be removed in a future release: + --short-form, which could be used for testing to limit the output to statements alone. + --stop-never-slave-server-id, which provided a server ID for connections using the --stop-never option. If you require this function, use the --connection-server-id option instead. The deprecation warnings for these options are sent to standard error, rather than to standard output, so that they do not interfere with the operation of tools that use the output of mysqlbinlog. * Replication: The log_slave_updates system variable is now set to ON by default, so you do not need to specify --log-slave-updates explicitly when you start a replication slave. The log_slave_updates system variable is read-only. If you need to prevent a replication slave from logging the updates performed by its SQL thread to its own binary log, specify --skip-log-slave-updates when you start the slave, or specify log_slave_updates=OFF in the configuration file for the slave. * Replication: The Group Replication thread states are now shown in the Performance Schema tables. * Replication: The group_replication_communication_debug_options variable has been added which enables you to dynamically filter out debugging and tracing messages per Group Replication component, such as GCS, XCOM, and so on. (Bug #10200) * JSON: The JSON_MERGE() function is renamed to JSON_MERGE_PRESERVE(). This release also adds the JSON_MERGE_PATCH() function, an RFC 7396 compliant version of JSON_MERGE_PRESERVE(); its behavior is the same as that of JSON_MERGE_PRESERVE(), except that JSON_MERGE_PATCH() removes any member in the first object with a matching key in the second object, provided that the value associated with the key in the second object is not JSON null. This example compares the results of merging the same 3 JSON objects, each having a matching key "a", with each of these functions: mysql> SET @x = '{ "a": 1, "b": 2 }', > @y = '{ "a": 3, "c": 4 }', > @z = '{ "a": 5, "d": 6 }'; mysql> SELECT JSON_MERGE_PRESERVE(@x, @y, @z) AS Preserve, -> JSON_MERGE_PATCH(@x, @y, @z) AS Patch\G *************************** 1. row *************************** Preserve: {"a": [1, 3, 5], "b": 2, "c": 4, "d": 6} Patch: {"a": 5, "b": 2, "c": 4, "d": 6} JSON_MERGE() is still supported as an alias of JSON_MERGE_PRESERVE(), but is now deprecated and subject to removal in a future MySQL release. See Functions That Modify JSON Values (http://dev.mysql.com/doc/refman/8.0/en/json-modification-functions.html), for more information. (Bug #81283, Bug #23255346) * InnoDB now uses Variance-Aware Transaction Scheduling (VATS) for scheduling the release of transaction locks when the system is highly loaded, which helps reduce lock sys wait mutex contention. Lock scheduling uses VATS when >= 32 threads are suspended in the lock wait queue. For more information about Variance-Aware Transaction Scheduling (VATS), see Identifying the Major Sources of Variance in Transaction Latencies: Towards More Predictable Databases (https://arxiv.org/pdf/1602.01871.pdf). Thanks to Jiamin Huang for the contribution. (Bug #25290971, Bug #84266) * The binary log is now enabled by default at server startup. The log_bin system variable is set to ON by default, instead of OFF, even if the --log-bin option has not been specified. Binary logging is standard practice for production installations, so enabling it by default removes configuration and planning steps that were usually required. To enable the server to start with log_bin = ON, the server_id system variable is now set to 1 by default, instead of 0. For servers in a replication topology, you must still change this setting to specify a unique server ID for each replication server. Previously, the server could not start with log_bin = ON if no server ID was specified. Now, the server can start, but a warning message is issued if you did not set an explicit server ID. With binary logging enabled for a server, all statements that change data are logged to the server's binary log, which is a sequence of files with a base name and numeric extension. By default, the server creates binary log files and an index file in the data directory, with base names of host_name-bin.xxxxxx and host_name-bin.index, using the value of the pid-file option, which by default is the name of the host machine. You can choose the names and locations of the files by specifying the --log-bin and --log-bin-index options. You are recommended to specify a base name explicitly, so that if the host name changes, you can easily continue to use the same binary log file names. The log_bin_basename system variable holds the base name and any specified path for the binary log files. The relay log and relay log index on a replication slave, whose names are specified by the --relay-log and --relay-log-index options, cannot be given the same names as the binary log and binary log index. From MySQL 8.0.3, the server issues an error message and does not start if the binary log and relay log file base names would be the same. The server creates a new binary log file in the series each time it starts or flushes the logs. The server also creates a new binary log file automatically after the current file's size reaches max_binlog_size, which defaults to the maximum permitted value of 1GB. In MySQL 8.0.3, binary log files expire by default after 30 days, and can then be automatically removed at startup or when the binary log is flushed. You can purge binary log files manually using the PURGE BINARY LOGS statement, or specify a different binary log expiration period using the binlog_expire_logs_seconds system variable. Many other options are available to modify the behavior of binary logging. For more information, see The Binary Log (http://dev.mysql.com/doc/refman/8.0/en/binary-log.html) and Binary Logging Options and Variables (http://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html). To disable binary logging, you can specify the --skip-log-bin or --disable-log-bin option at startup. If either of these options is specified and --log-bin is also specified, the option specified later takes precedence. If you disable binary logging, you must also specify --skip-log-slave-updates, as the --log-slave-updates option is enabled by default from MySQL 8.0.3 and requires binary logging. If you use mysqld to initialize the data directory manually by invoking it with the --initialize or --initialize-insecure option, binary logging is disabled by default, but can be enabled by specifying the --log-bin option with or without a base name. References: See also: Bug #26730000. * The expire_logs_days system variable, which specifies the binary log expiration period in days, is now deprecated and will be removed in a future release. expire_logs_days does not provide sufficient flexibility for defining the binary log expiration period. binlog_expire_logs_seconds can be used to set the binary log expiration period in seconds. In MySQL 8.0.3, the effects of the two variables are currently cumulative. For example, if expire_logs_days is 1 and binlog_expire_logs_seconds is 43200, then the binary log is purged every 1.5 days. This produces the same result as setting binlog_expire_logs_seconds to 129600 and expire_logs_days to 0. Note that the default expire_logs_days setting of 30 days is currently added to the binary log expiration period if expire_logs_days is not specified. To use binlog_expire_logs_seconds alone, set expire_logs_days=0 explicitly. To disable automatic purging of the binary log, you must set both expire_logs_days and binlog_expire_logs_seconds explicitly to 0. References: See also: Bug #26483363. * The new get_sysvar_source plugin service enables plugins to retrieve the source of system variable settings. * The zlib library version bundled with MySQL was raised from version 1.2.3 to version 1.2.11. MySQL implements compression with the help of the zlib library. The zlib compressBound() function in zlib 1.2.11 returns a slightly higher estimate of the buffer size required to compress a given length of bytes than it did in zlib version 1.2.3. The compressBound() function is called by InnoDB functions that determine the maximum row size permitted when creating compressed InnoDB tables or inserting rows into compressed InnoDB tables. As a result, CREATE TABLE ... ROW_FORMAT=COMPRESSED or INSERT operations with row sizes very close to the maximum row size that were successful in earlier releases could now fail. If you have compressed InnoDB tables with large rows, it is recommended that you test compressed table CREATE TABLE statements on a MySQL 8.0.3 test instance prior to upgrading. * In MySQL 8.0.2, the system variables for the slave status logs, master_info_repository and relay_log_info_repository, were set to TABLE instead of FILE by default. In MySQL 8.0.3, the FILE setting for both these system variables is deprecated, and a warning is issued if it is used. The FILE setting will be removed in a future release. The TABLE setting ensures that replication repository information is stored in InnoDB tables, rather than in files in the data directory. The use of tables makes replication resilient to unexpected halts. The default names for the slave status logs when stored as files were master.info and relay-log.info. The names could be changed using the --master-info-file and --relay-log-info-file options, respectively. As InnoDB tables, the slave status logs are named mysql.slave_master_info and mysql.slave_relay_log_info. To modify an existing replication slave that is using a FILE repository for the slave status logs to use TABLE repositories, convert the existing replication repositories dynamically by running the following commands: STOP SLAVE; SET GLOBAL master_info_repository = 'TABLE'; SET GLOBAL relay_log_info_repository = 'TABLE'; The master info log table mysql.slave_master_info should be protected because it contains the password for connecting to the master. When you back up the replication slave's data, ensure that you back up the mysql.slave_master_info and mysql.slave_relay_log_info tables containing the slave status logs, because they are needed to resume replication after you restore the data from the slave. [ to be continued ] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
