Replication - High Performance MySQL - page 481

Figure 10-14. Another way to emulate multisource replication
Either of these configurations can suffer from the usual problems, such as conflicting
updates and CREATE TABLE statements that explicitly specify a storage engine.
Another option is to use Continuent's Tungsten Replicator, which we'll discuss later
in this chapter.
Creating a log server
One of the things you can do with MySQL replication is create a “log server” with no
data, whose only purpose is to make it easy to replay and/or filter binary log events. As
you'll see later in this chapter, this is very useful for restarting replication after crashes.
It's also useful for point-in-time recovery, which we discuss in Chapter 15 .
Imagine you have a set of binary logs or relay logs—perhaps from a backup, perhaps
from a server that crashed—and you want to replay the events in them. You could use
mysqlbinlog to extract the events, but it's more convenient and efficient to just set up
a MySQL instance without any data and let it think the binary logs are its own. You
can use the MySQL Sandbox script available at http://mysqlsandbox.net to create the
log server if you'll need it only temporarily. The log server does not need any data because
it won't be executing the logs—it will only be serving the logs to other servers. (It does
need to have a replication user, however.)
Let's take a look at how this technique works (we show some applications for it later).
Suppose the logs are called somelog-bin.000001 , somelog-bin.000002 , and so on. Place
these files into your log server's binary log directory. We'll assume it's /var/log/mysql .
Then, before you start the log server, edit its my.cnf file as follows:
log_bin = /var/log/mysql/somelog-bin
log_bin_index = /var/log/mysql/somelog-bin.index