应 该保证从服务器上任何数据的修改都是通过从主服务器上复制操作获取的，换句话说，从服务器应该是只读的，如果不能保证这一点，则可能造成主从数据不一致。 可以在从服务器的my.cnf里加入read-only参数来实现这一点，唯一需要注意的一点事read-only仅对没有super权限的用户有效。所 以最好核对一下连接从服务器的用户，确保其没有super权限。
从 理想角度看，主从数据库应该无故障的运转下去，可以有时候还是会出现一些莫名其妙的问题，比如说即便从未在从服务器上手动更新过数据，但还是可能遇到 “Error: 1062 Duplicate entry”错误，具体原因不详，可能是MySQL本身的问题。遇到这类问题的时候，从服务器会停止复制操作，我们只能手动解决问题，具体的操作步骤如 下：
mysql> set global sql_slave_skip_counter = 1;
mysql> start slave;
同样的操作可能需要进行多次，也可以设置自动处理此类操作，在从服务器的my.cnf里设置：
slave-skip-errors=1062
最后再唠叨一下日志的问题：时间长了，数据库服务器上的二进制文件会越来越多，清理是必要的，你可以设置自动清理，相关参数是expire_logs_days，也可以使用手动删除的方式，但这里说的手动不是指rm，而是指PURGE BINARY LOGS，删除任何日志前，最好在所有的从服务器上通过show slave status命令确认一下相关日志是否已经无用。
更详细的介绍参考官方文档：How to Set Up Replication，不喜欢英文的话可以看老叶同志的中文翻译。
补充：[ERROR] Error in Log_event::read_log_event(): 'Event too big'
在使用主从复制的时候，出现的问题多半是和日志（主服务器的二进制日志，从服务器的延迟日志）相关的。比如说加入你遇到了上面的错误，你可以根据错误日志的信息在主从数据库服务器上分别执行：
mysqlbinlog 日志文件 > /dev/null
查 看错误，如果没有错误，则不会有任何输出，反之会输出错误信息，如果确定了错误是出现在主服务器二进制日志上，可以跳过适当的位置，再在从服务器上重新设 定LOG_POS，如果确定了错误是出现在从服务器延迟日志上，则可以删除从服务器的延迟日志（使用CHANGE TO MASTER的时候，除非设定了延迟日志信息，否则会自动删除延迟日志），并在从服务器上重新设定LOG_POS。期间也可以考虑手动执行不能自动执行的 SQL日志。
补充：配置的时候如果版本允许最好打开sync_binlog选项。
补充：有时候，从服务器延迟日志可能已经损坏，这时需要执行CHANGE MASTER TO设置新的日志文件信息，但是在从服务器上SHOW SLAVE STATUS会显示很多日志信息，他们的含义有所不同：
Master_Log_File:Read_Master_Log_Pos 是IO相关的日志信息
Relay_Master_Log_File:Exec_Master_Log_Pos 是SQL相关的日志信息
从服务器需要设置的是SQL相关的日志信息：
slave stop;
change master to master_log_file=’(binlog name in relay_master_log_file)’, master_log_pos=(exec_master_log_pos number);
slave start;
1) When you are using the master as a consistent snapshot, use SHOW MASTER STATUS to determine the position.
2) When you are using a slave as a consistent snapshot, use SHOW SLAVE STATUS and Exec_Master_Log_Pos.
参考链接
补充：缺省情况下，从服务器会以主机名命名延迟日志，所以一旦你修改了从服务器的主机名就会造成问题，新版MySQL会提示你这个情况：
[Warning] Neither --relay-log nor --relay-log-index were used;
so replication may break when this MySQL server acts as a slave and has his hostname changed!!
Please use '--relay-log=name-relay-bin' to avoid this problem.
设定relay-log可以避免此类问题。
从 理想角度看，主从数据库应该无故障的运转下去，可以有时候还是会出现一些莫名其妙的问题，比如说即便从未在从服务器上手动更新过数据，但还是可能遇到 “Error: 1062 Duplicate entry”错误，具体原因不详，可能是MySQL本身的问题。遇到这类问题的时候，从服务器会停止复制操作，我们只能手动解决问题，具体的操作步骤如 下：
mysql> set global sql_slave_skip_counter = 1;
mysql> start slave;
同样的操作可能需要进行多次，也可以设置自动处理此类操作，在从服务器的my.cnf里设置：
slave-skip-errors=1062
最后再唠叨一下日志的问题：时间长了，数据库服务器上的二进制文件会越来越多，清理是必要的，你可以设置自动清理，相关参数是expire_logs_days，也可以使用手动删除的方式，但这里说的手动不是指rm，而是指PURGE BINARY LOGS，删除任何日志前，最好在所有的从服务器上通过show slave status命令确认一下相关日志是否已经无用。
更详细的介绍参考官方文档：How to Set Up Replication，不喜欢英文的话可以看老叶同志的中文翻译。
补充：[ERROR] Error in Log_event::read_log_event(): 'Event too big'
在使用主从复制的时候，出现的问题多半是和日志（主服务器的二进制日志，从服务器的延迟日志）相关的。比如说加入你遇到了上面的错误，你可以根据错误日志的信息在主从数据库服务器上分别执行：
mysqlbinlog 日志文件 > /dev/null
查 看错误，如果没有错误，则不会有任何输出，反之会输出错误信息，如果确定了错误是出现在主服务器二进制日志上，可以跳过适当的位置，再在从服务器上重新设 定LOG_POS，如果确定了错误是出现在从服务器延迟日志上，则可以删除从服务器的延迟日志（使用CHANGE TO MASTER的时候，除非设定了延迟日志信息，否则会自动删除延迟日志），并在从服务器上重新设定LOG_POS。期间也可以考虑手动执行不能自动执行的 SQL日志。
补充：配置的时候如果版本允许最好打开sync_binlog选项。
补充：有时候，从服务器延迟日志可能已经损坏，这时需要执行CHANGE MASTER TO设置新的日志文件信息，但是在从服务器上SHOW SLAVE STATUS会显示很多日志信息，他们的含义有所不同：
Master_Log_File:Read_Master_Log_Pos 是IO相关的日志信息
Relay_Master_Log_File:Exec_Master_Log_Pos 是SQL相关的日志信息
从服务器需要设置的是SQL相关的日志信息：
slave stop;
change master to master_log_file=’(binlog name in relay_master_log_file)’, master_log_pos=(exec_master_log_pos number);
slave start;
1) When you are using the master as a consistent snapshot, use SHOW MASTER STATUS to determine the position.
2) When you are using a slave as a consistent snapshot, use SHOW SLAVE STATUS and Exec_Master_Log_Pos.
参考链接
补充：缺省情况下，从服务器会以主机名命名延迟日志，所以一旦你修改了从服务器的主机名就会造成问题，新版MySQL会提示你这个情况：
[Warning] Neither --relay-log nor --relay-log-index were used;
so replication may break when this MySQL server acts as a slave and has his hostname changed!!
Please use '--relay-log=name-relay-bin' to avoid this problem.
设定relay-log可以避免此类问题。
