MySQL Blog Archive
For the latest blogs go to blogs.oracle.com/mysql
Replication Features in MySQL 8.0.3
Posted on Sep 22, 2017 by Luis Soares
Category: High Availability / Replication
Tags: group-replication, mysql-replication, replication

Great news! MySQL 8.0.3 is out and it is a release candidate. In the replication team we have been busy working on interesting new enhancements and also doing some clean up. Some of these new features are out in this release. Let me summarize the new replication bits and pieces in MySQL 8.0.3.

Group Replication has been extended with the following features:

  • Dynamic tracing and debugging log for Group Replication. Allows tracing and debugging information that can be activated dynamically, without serious impact on performance. This will help troubleshoot issues, especially those that are rooted in the group communication modules, such as XCom. Tracing and debug information is written out to a special trace file;
  • More performance schema instrumentation. Threads associated with the group communication modules are now also visible in performance schema.

The core framework of MySQL Replication was also extended with the following functionality:

  • Replication of partial JSON documents. User is able to instruct the server to only replicate the partial changes done to large JSON documents, when replicating in ROW mode. This will reduce the amount of storage space needed when writing these changes the binary log as well as the amount of data transferred between different servers in a replication setup.

Also interesting in MySQL 8.0.3, is the fact that some replication related defaults have been changed:

  • The binary log is enabled by default. Starting a MySQL 8 server will mean that you are setup for replication from the get go;
  • The default server-id is 1. Previously, the default server-id was 0;
  • Replication changes are written to the replica’s binary log by default. The slave applier will log its own updates to the slave’s binary log. In other words, log-slave-updates is turned on by default.

Apart from this there was some clean up done, which includes declaring a few features as deprecated and removing obsolete ones:

  • Removed GLOBAL scope of sql_log_bin. The global scope of sql_log_bin was already read-only in MySQL 5.5+. In MySQL 5.7 it was deprecated. It has now been removed from MySQL 8.0.3;
  • Deprecated FILE repositories for replication metadata. FILE option has been deprecated for master.info, relay-log.info and friends. Instead users should use TABLE;
  • Deprecated mysqlbinlog’s stop-never-slave-server-id option. Users should use connection-server-id instead;
  • Deprecated mysqlbinlog’s short-form option. This option is now deprecated without any alternative;
  • Deprecated IGNORE_SERVER_IDS when GTID_MODE=ON. IGNORE_SERVER_IDS is a configuration option for the CHANGE MASTER command. It allows the user to specify that transactions coming in through replication, from a specific set of server ids, are to be ignored. This is to prevent unwanted re-executions of the same transactions (which could happen if a circle in a replication topology had been formed). However, when deploying replication using GTIDs, transactions that have already been handled will be automatically skipped due to the auto-skip property of GTIDs. Therefore IGNORE_SERVER_IDS is obsolete in such a setup;
  • Deprecated expire_logs_days server option. This option has been deprecated in favour of binlog_expire_logs_seconds.

As usual, stay tuned. We expect to be posting follow-up blogs detailing the replication work done in 8.0.3. As for the time being, go and give MySQL 8.0.3 a spin. Oh, and did I mention that this release is in fact a release candidate? Not generally available, thus not production ready, so use it at your own risk. And, as you already know by now, feedback highly appreciated. There are several ways to get to us: bug reports, feature requests, the replication mailing list or by just leaving a comment on this (or subsequent) blog posts.

 Search
Categories