MySQL 8.0.3: Binary logging and Replication chains are now enabled by default

MySQL 8.0.3 release candidate is out with amazing new replication features, along with changes in couple of replication default options. Thanks to our users for their constant feedback and valuable inputs, MySQL is changing defaults whenever possible to remove configuration overhead for practical deployment of MySQL server. One such long-awaited requirement from the users was to have server in get-go state for replication. So, finally here it is in MySQL 8.0.3.


We can broadly categorize use-cases of MySQL server in following three categories as per usage of binary logs:

  1. UseCase#1: Replicate (Use binary log, and do replicate).
    It is useful for most of the production installations, since it is the base for implementing HA and Scalability.
  2. UseCase#2: Use binary log, but do not replicate.
    It is useful on smaller deployments where the binary log can be used for debugging or point-in-time recovery.
  3. UseCase#3: Do not use binary log, and do not replicate.
    It is useful for smaller deployments that need to save space.

Traditionally, MySQL provided UseCase#3 by default. Our long-term goal is to tweak the defaults so that UseCase#1 becomes the no-config mode, because the demand for HA and scalability are high nowadays. In 8.0.3, for the first time, the defaults are set for use case UseCase#2: the binary logging is now enabled! This also removes configuration steps for UseCase#1, and we further removed configuration steps for chained replicationSo we made a big step forward towards the goal of enabling scalability and HA by default!

About enabling Replication Chains:
Enabling log-slave-updates on a replica means, the replica writes updates that are received from a master to its own binary logs. So a replica can become a intermediate master of another replica. This option is a stepping stone for various simple to complex level replication setups and new technologies like Group Replication.

Example setups:

Worklogs implemented:

WL#10470 – Defaults: Enable Binary Log (log_bin: ON)
WL#10479 – Defaults: Enable Replication Chains (log_slave_updates: ON)


Here is how you can configure the above mentioned three use-cases (UseCase#):
1.  To replicate, the only command-line option you need now is server-id. The binary logging is enabled by default. We still recommend that you set –log-bin=<BASENAME>, otherwise it uses the hostname, which a system administrator could potentially change. But, it is no longer strictly required to set any option.

For examples:

– It is a good practice to set –log-bin to specific values on servers. Similarly, –relay-log can be specified too, to some specific values.

2. To have binary log enabled without replication, you don’t need to set anything. We still recommend users to set server-id=1 for such cases, in order to silence a warning that is otherwise printed at startup.

For examples:

– Warning about providing server-id (if not set) appears regardless of whether it is log-bin or skip-log-bin. This is to ensure that user sets unique server-id even for replicas without a binary log. server-id can be set in the configuration file or even changed dynamically. The recommended way is to set it in the configuration file.

3. To disable binary logs and replication (to save space), set –skip-log-bin or –disable-log-bin,  and –server-id=1 (to avoid warning).


Upgrade consideration:

There is a minor upgrade impact to the users who don’t want binary logging. They need to start server with –skip-log-bin or –disable-log-bin,  and –server-id=1 (to avoid warning). We are keeping binary logging as an opt-out rather than an opt-in thing from MySQL 8.0.3 onwards.


Most production installations have the binary log enabled as it’s used for replication and point-in-time recovery. Enabling binary logging and replication chains by default means users can start prototyping quickly, and can move from prototype of realistic deployment with minimum hassle. It also means, less configurations for replication (async, semi-sync), group replication, and InnoDB Cluster! 🙂

Stay tuned for more blog posts. Note that MySQL 8.0.3 is a release candidate, thus it is not production ready yet. But, please don’t restrict yourselves from providing us with your valuable feedback. You can get to us through: bug reports, feature requests, the replication mailing list or by leaving a comment on this blog post.

Thanks for using MySQL Replication!

 19,956 total views,  12 views today

About Narendra Chauhan

Narendra Singh Chauhan is a Principal Member Technical Staff at MySQL(Oracle). He has been working with MySQL Replication QA team since late 2013. His areas of interest include Replication, Upgrade, Migration, Backup & Restore, HA, Distributed systems and DBMS.

4 thoughts on “MySQL 8.0.3: Binary logging and Replication chains are now enabled by default

  1. You miss:

    UseCase#4: Do not use binary log, and *do* replicate.
    Useful in many deployments where you don’t have to worry about the binlog storage and you want to reduce i/o. These servers can not be used as alternative masters if there’s a failure but for read scale out are convenient.

    It may be convenient to have all boxes run with binlogs but there is an overhead which has to be paid for that and that should not be forgotten.

    1. Hi Simon,

      Thanks for the inputs!

      I thought about it before writing the blog. Skipping UseCase#4 (Do not use binary log, and *do* replicate) was intentional, because, it doesn’t hold true in this blog’s context.

      Let me take a simple replication topology example (M1 -> S1):
      Here, Master(M1) server must need binary logging enabled to replicate further. Thus, it is Replica(S1) which can be with and without having binary logging enabled.
      If binary logging is enabled on Replica it can serve UseCase#1 or UseCase#2, whereas, if binary logging is disabled on Replica it can serve UseCase#3. IIUC, one such aspect of UseCase#3 is what you are suggesting here, where Replica (S1) is binlog-less and it is part of replication topology, but, it will not replicate further.

      UseCase#3 can be seen as:
      1. A standalone server which doesn’t need binary logging enabled and will not participate in replication further.
      2. A last Replica of the chain replication topology where binary logging is disabled, as we will be using it for read-only or analytics or backup. This server will not replicate further.

      Please feel free to revert back to me in case I’m not clear here.

      Best Regards,

  2. The company I work for switch from Mysql 5.6 to Aurora because our slaves were not able to keep up with the amount of writes. I did some benchmarks with Mysql 5.7 and multi-threaded replication workers and was not able to come close to Aurora low latency between the writer and its replicas. I understand Aurora uses a totally different approach (using redo logs) but the solution to scale reads on Mysql (using replication) is limited when the writes are high and heavy. (Sysbench uses small tables (very few columns, int, small varchar) which rarely represent companies’ DB). I’ve also experimented with Galera Cluster which lock when writing to multiple writes.
    Is there any low latency (in ms, not sec) improvement in the near future for Mysql replication?

Leave a Reply