Databases Reference
In-Depth Information
Another technique entirely, which is under development at the time of writing, is in-
ternal to InnoDB. It puts transactions into a special mode that causes InnoDB to “fake”
updates, so a process can execute these fake updates and then the replication thread
can do the real updates quickly. This is something we're developing in Percona Server
specifically for a very popular Internet-scale web application. Check on the status of
this, because it's bound to have changed by the time this topic is published.
If you're considering this technique, we think you would be well advised to get qualified
advice from an expert who's familiar with when it works and what other options are
available. This is best reserved as a last-resort measure for when all else fails.
Oversized Packets from the Master
Another hard-to-trace problem in replication can occur when the master's
max_
allowed_packet
size doesn't match the replica's. In this case, the master can log a packet
the replica considers oversized, and when the replica retrieves that binary log event, it
might suffer from a variety of problems. These include an endless loop of errors and
retries, or corruption in the relay log.
Limited Replication Bandwidth
If you're replicating over limited bandwidth, you can enable the
slave_compressed
_protocol
option on the replica (available in MySQL 4.0 and newer). When the replica
connects to the master, it will request a compressed connection—the same compres-
sion any MySQL client connection can use. The compression engine used is
zlib
, and
our tests show it can compress some textual data to roughly a third of its original size.
The trade-off is that extra CPU time is required to compress the data on the master and
decompress it on the replica.
If you have a slow link with a master on one side and many replicas on the other side,
you might want to colocate a distribution master with the replicas. That way only one
server connects to the master over the slow link, reducing the bandwidth load on the
link and the CPU load on the master.
No Disk Space
Replication can indeed fill up your disks with binary logs, relay logs, or temporary files,
especially if you do a lot of
LOAD DATA INFILE
queries on the master and have
log
_slave_updates
enabled on the replica. The more a replica falls behind, the more disk
space it is likely to use for relay logs that have been retrieved from the master but not
yet executed. You can prevent these errors by monitoring disk usage and setting the
relay_log_space
configuration variable.
