In development milestone release (DMR) version 8.0.2 we are changing several replication options. The motivation behind this is simply that we want our users to enjoy default installations with the best efficient setup, configuration and performance. We also don’t want users to struggle getting them to work optimally. So we promise the best possible defaults – tested and proven.

WL#10474 Store Replication Metadata in InnoDB

We are making replication slaves crash safe by default. This makes replication more robust and efficient offering ACID guarantees by making it possible to store metadata information about replication slaves in the system tables (InnoDB). For more information about this feature, please see Replication-implementation-crash-safe-slave.

The following describes the changes in 8.0.2,

master-info-repository = TABLE : causes mysql.slave_master_info used for storing replication channel metadata.
relay-log-info-repository = TABLE :  causes mysql.slave_relay_log_info used for storing relay log metadata.

There are several advantages of this feature including the following:
1. Storing the master/relay-log information in InnoDB tables is a requirement for Group Replication, that will make migration from Replication to Group Replication easier.
2. Storing replication metadata and configuration in InnoDB system tables by default, also means that the user can take advantage of the TDE to secure this data, which in some cases may be deemed too sensitive.

We also have test files for testing the feature. If you want to see how it works, you can find some examples of these in MTR tests:

For information on how to run the MTR tests, see MYSQL_TEST_RUN.

WL#10477 Enable Transaction Write Sets

The write-set of a transaction is a set of hashes that identify each row in the database that has changed. The write-sets are used by Group Replication to detect which transactions can run in parallel between member servers – using the certification mechanism.

With transaction write sets in Replication, the master has to do slightly more work to generate the write sets, i.e. creating a hash of the writes extracted during a transaction, which is helpful in conflict detection. This allows users to easily move into Group Replication, since these writesets from a transaction is required for conflict detection in group members. The same idea is also used in each member to detect which transactions can be applied in parallel on the slaves. Note: Transaction Write Sets works only with row based replication.

MySQL 8.0.1 introduces a new mechanism to track the dependencies between transactions. This feature is used to optimize the binary log applier on asynchronous replication slaves, improving the throughput significantly on workloads where there is low-concurrency on the master and/or on systems with very fast storage. For more information about this features, please see Improving-the-parallel-applier-with-writeset-based-dependency-tracking.

The following describes the changes in 8.0.2,
transaction_write_set_extraction = OFF
is being changed to:
transaction-write-set-extraction = XXHASH64

For more information about this change, please see Sysvar_transaction_write_set_extraction
Note: There is no change to the option binlog_transaction_dependency_tracking.

We also have test files for testing the feature. If you want to see how it works, you can find some examples of these in MTR tests:

For information on how to run the MTR tests, see MYSQL_TEST_RUN.

WL#10476 Defaults: Enable Hash Scans in RBR

HASH_SCAN is an optional algorithm, which offers the best possible performance when applying transactions on tables that have no index to uniquely identifying rows (when applying ROW based events on the slave). With the HASH_SCAN algorithm, we can still try and avoid doing a full-table scan. That is, we can avoid a table scan and instead search for the applicable row(s) using generated hashes. Since full-table scans are very expensive, the  hash scan we produce better plans yielding in better performance. For more information about this feature, please see Batch-operations-in-RBR

The following describes the changes in 8.0.2,

slave-rows-search-algorithms = ‘TABLE_SCAN,INDEX_SCAN’.
Is being changed to:
slave-rows-search-algorithms = ‘INDEX_SCAN,HASH_SCAN’
This option enables the use of a hash table to avoid repeated table scans when no Primary Key or Unique Key exists.

For a good reference on different scan algorithms, please see: Option_mysqld_slave-rows-search-algorithms

We also have test files for testing the feature. If you want to see how it works, you can find some examples of these in MTR tests:

For information on how to run the MTR tests, see MYSQL_TEST_RUN.

WL#10478 Defaults: Enable Binary Log Expiration

We all know how important it is to keep disk space free. In fact, most DBA’s work hard to make sure that disk space is cleaned up when surplus files are not required. For replication binary logging, having ample disk space is a must because we store binlogs on disk which is useful in recovery and in addition binlogs are used by the slaves to catch up with the master. So, ideally, we cannot remove the binlog files too early because we may need them but not removing them over time would mean that we risk the increase in disk space.

It should be noted that binary logs do not have a default expiration in MySQL (until MySQL 8.0.1). Binary logs are append only and their growth rate is highly influenced by your workload. In some cases they can grow very large, in some cases they can remain small (typically on loads where read operations prevail). One solution to the problem where there are large set of binary logs is to purge old and unneeded binary logs using the PURGE LOGS command. But if replication is enabled, you need to ensure that all replication slaves have finished reading the logs before purging them.

For more information about purging binary logs, please see Purge-binary-logs.

To prevent this, we have MySQL global variable expire_logs_days, this variable determines how many days the binary logs are kept before being automatically purged, but its current value is set to 0.

The following describes the changes in 8.0.2,

expire_logs_days=30, i.e. now the default will be 30 days.

We feel the replication slaves typically don’t lag behind too many days and this new default value will help out of the box installations which will ensure that less work for an end/user to monitor and worry about disk resources in use.

We also have test files for testing the feature. If you want to see how it works, you can find some examples of these in MTR tests:

For information on how to run the MTR tests, see MYSQL_TEST_RUN.

We hope the changes to options listed above will help users in configuring and using MySQL and Replication. Please feel free to provide us your suggestions. We are looking forward for your valuable feedback.