有许多参数来控制复制，其中一些会对数据安全和性能产生影响。稍后我们会解释何种规则在何时会失效。本小节推荐的一种“安全”的配置，可以最小化问题发 生的概率。
在主库上二进制日志最重要的选项是sync binlog:
sync_ binlog=1
如果开启该选项，MySQL每次在提交事务前会将二进制 日志同步到磁盘 上，保证在服务器崩溃时不会丢失事件。如果禁止该选项，服务器会少做一些工作，但二进制日志文件可能在服务器崩溃时损坏或丢失信息。在个不需要作为 主库的备库 上，该选项带来了不必要的开销。它只适用于二进制日志，而非中继日志。
如果无法容忍服务器崩溃导致表损坏，推荐使用InnoDB。在表损坏无关紧要时，MyISAM是可以接受的，但在一次备 库服务器崩溃重启后，MyISAM表可能已经处于不一致状态。一种可能是语句没有完全应用到一个或多个表上，那么即使修复了表，数据也可能是不一致的。
如果使用InnoDB,，我们强烈推荐设置如下选项:
innodb flush logs. at_ trx commit # Flush every log write
innodb support xa=1 # MySQL 5.0 and newer only
innodb safe. binlog # MySQL 4.1 only, roughly equivalent to
# innodb_ support xa
这些是MysSQL 5.0及最新版本中的默认配置，我们推荐明确指定二进制日志的名字，以保证二进制日志名在所有服务器上是致的， 避免因为服务器名的变化导致的日志文件名变化。你可能认为以服务器名来命名二进制日志无关紧要，但经验表明，当在服务器间转移文件。克隆新的备库、转储备份或者其他些你想象 不到的场景下，可能会导致很多问题。为了避免这些问题，需要给log bin选项指定一个參数。 可以随意地给一个绝对路径，但必须明确地指定基本的命名(正如本章之前讨论的)。
log. bin=/var/lib/mysq1/mysql-bin # Good; specfies a path and base name
#log_bin # Bad; base name will be server's hostname
在备库上， 我们同样推荐开启如下配置选项，为中继日志指定绝对路径:
relay_ 1og=/path/to/1ogs/relay-bin
skip_ slave start
read_only
通过设置relay_ log可以避免中继日志文件基于机器名来命名，防止之前提到的可能在主库发生的问题。指定绝对路径可以避免多个MySQL版本中存在的Bug,这些Bug可能会导致中继日志在一个 意料外的位置创建。skip_ slave_ start 选项能够阻止备库在崩溃后自动启动复制。这可以给你些机会来修复 可能发生的问题。如果备库在崩溃后自动启动并且处于不一致的状态，就可能会导致更多的损坏，最后将不得不把所有数据丢弃，并重新开始配置备库。
read only 选项可以阻止大部分用户更改非临时表，除了复制SQL线程和其他拥有超级权限的用户之外，这也是要尽量避免给正常账号授子超级权限的原因之一。
即使开启了所有我们建议的选项，备库仍然可能在崩溃后被中断，因为mastrinfo和中继日志老文件都不是崩溃安全的。默认情况下甚至不会刷新到磁盘，直到MySQL 5.5版本才有选项来控制这种行为。如果正在使用MySQL 5.5并且不介意额外的fsync()导致的性能开销，最好设置以下选项:
sync_ master info = 1
sync relay_ 1og = 1
sync. relay 1og. info = 1
如果备库与主库的延迟很大，备库的1/0线程可能会写很多中继日志文件，SQL线程在重放完一个中继日志中的事件后会尽快将其删除(通过relay _log purge 选项来控制)。
但如果延迟非常严重，I/0线程可能会把整个磁盘撑满。解决办法是配置relay_ log_space_ limit变量。如果所有中继日志的大小之和超过这个值，I/O线程会停止，等待SQL线程释放磁盘空间。
尽管听起来很美好，但有一个隐藏的问题。如果备库没有从主库上获取所有的中继日志，这些日志可能在主库崩请时丢失。早先这个选项存在一些Bug.使用率也不高，所以用到这个选项遇到Bug的风险会更高。除非磁盘空间真的非常紧张，否则最好让中维日志使用其需要的感盘空间，这也是为什么我们没有将relay_log_space_Limit列人推荐的配置选项的原因。
