Mirrored Binlogs


This feature makes the slave IO thread maintain a copy of the master’s binlog as it writes the relay log. By copy, we mean that the file has the same name and same contents (and offsets). When this is done, slave can transparently failover between replication proxy slaves as long as the proxies all mirror the binlog.

Note: When this is first enabled, the slave must download all of the current binlog. This can take some time. New events are not appended to the relay log until this has finished.

This patch was introduced in patchset d7.

Patch Origin

Google (Mark Callaghan), updates and fixes by Percona and Open Query.


  • rpl_mirror_binlog_enabled – Enable binlog mirroring (default: disabled).
  • sync_mirror_binlog – Equivalent to sync_binlog option but for the mirror binlog, sync the mirrored binlog to disk after every #th event (#=0 (default) does no sync. Syncing slows things down).


        MASTER_LOG_FILE=<log_file>, MASTER_SERVER_ID=<id>
        [, INDEX=<log_file.index>] [WITH BINLOG]
    – This command enables the use of a specific server-id and binlog on a slave without restarting mysqld: make the current database a primary and starts binlog logging for all updates. When the WITH BINLOG option is used, old binlogs will be kept after MAKE MASTER command.


MySQL replication is great. It is efficient, stable and easy to use. Unfortunately, it is not easy to use for hierarchical replication. The most important replication state on a slave is the name and offset for the file on the server from which it copies replication events.

When hierarchical replication is used, that state cannot be transferred without translation. For example, suppose there is one master, two slaves that replicate from the master and generate a binlog, these two are the replication proxy slaves. There are also many slaves that replicate from the two replication proxy slaves. If one of the replication proxy slaves fails, the slaves that replicated from the proxy cannot transparently failover to the other replication proxy. The binlogs written by the proxies might not have the same names, and replication events stored at the same offsets are not the same.

4 Responses to “Mirrored Binlogs”

  1. Michael Renner Says:

    “MySQL replication is great. It is efficient, stable and easy to use.”

    I am at loss of words.

    Heading for the tip:


    http://dev.mysql.com/doc/refman/5.1/en/replication-features.html (the “Features & Issues” is a rather kinky way to put it)

    And there is probably much much more below the surface. But I guess if the Stockholm’s is advanced enough, you can’t tell the difference anymore.

  2. arjen Says:

    @Michael: yep those are Mark Callaghan’s words. Of course replication also has its issues but it works really well in a huge number of places. Obviously skill and monitoring come into it, too.

    MySQL is the most widely used and publicly documented database product, at least in the OSS and mainstream deployment space; so obviously there’s more info out there about things that can cause hassles, and also there’ll be more people experiencing those hassles.
    Doesn’t mean it’s like that for everybody. But it’s good to hear the good as well as the bad, then people can make more educated decisions.

    What I’ve found doing Open Query training and support is that many replication issues simply arise from misconceptions about how it works, being unfamiliar with particular aspects and features and trying to abuse other features to do something inappropriate, and so on. Like any tool, knowing how to handle it helps a great deal and often prevents trouble.

  3. Michael Renner Says:


    thanks for your reply. By no means I want to criticize the work you are doing here, it was long overdue and I see it as a chance for the project to regain credibility. It is a major shame though, that this work wasn’t started by MySQL Management either in the AB or now at Sun.

    What I’m missing is a somewhat critical and/or challenging stance to the product you use daily.

    I’m a heavy Linux, Debian and PostgreSQL user (and contributor) and have used a fair share of different Open Source Software in the infrastructure I managed. I am never short of criticism for any of the tools I use and even contributed to, because I know that as great as they might be in a specific area, there are enough use cases where they are suboptimal or plain and outright fail.

    And this is one of the things I miss from the MySQL Community at large (generalizing here); the only critical voice I heard so far was the one from Monty Widenius, who held nice presentations about the status quo a year or two ago, and now started to be more public about his insights.

    To summarize:

    When the fish stinks, it usually means it’s (grown) bad. And if a whole lot of fish in a given area stink, it usually hints on systemic/architectural problems and not isolated bugs or user problems.

    best regards,

  4. arjen Says:

    @Michael: The MySQL community has not been exactly quiet. Heck, I was even vocal when I was at MySQL AB. Anyway, to get a good insight in the regular goings’ on you could follow planetmysql.org and you will quickly notice that the community is anything but silent on saying what they think, and acting on it.