我们都知道binlog_format有三种可选配置：STATEMENT、ROW、MIXED，相应地，基于这三种模式的Replication分别称为SBR(STATEMENT BASED Replication)、RBR、MBR。 同时，我们也知道，MySQL Replication可以支持比较灵活的binlog规则，可以设置某些库、某些表记录或者忽略不记录。
通常地，我们强烈建议不要设置这些规则，默认都记录就好，在Slave上也是如此，默认所有库都进行Replicate，不要设置DO、IGNORE、REWRITE规则。 如果非要设置这些规则的话，可能会导致某些场景下或者某些特定的SQL无法被记录，就需要特别注意了。
我经过比较简单的测试，不同的binlog_format可能会导致某些SQL不被记录的情况总结如下：
[获取更多]在MySQL复制环境中，我们通常只根据 Seconds_Behind_Master 的值来判断SLAVE的延迟。这么做大部分情况下尚可接受，但并不够准确，而应该考虑更多因素。
首先，我们先看下SLAVE的状态：
yejr@imysql.com [(none)]> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event *** Master_Log_File: mysql-bin.000327 Read_Master_Log_Pos: 668711237 Relay_Log_File: mysql-relay-bin.002999 Relay_Log_Pos: 214736858 Relay_Master_Log_File: mysql-bin.000327 Slave_IO_Running: Yes Slave_SQL_Running: Yes *** Skip_Counter: 0 Exec_Master_Log_Pos: 654409041 Relay_Log_Space: 229039311 *** Seconds_Behind_Master: 3296 ***
可以看到 Seconds_Behind_Master 的值是 3296，也就是SLAVE至少延迟了 3296 秒。
…
[获取更多]
当我们要写入新数据而发生“The table is full”告警错误时，先不要着急，按照下面的思路来逐步分析即可：
1、查看操作系统以及MySQL的错误日志文件
确认操作系统的文件系统没有报错，并且MySQL的错误日志文件中是否有一些最直观的可见的错误提示。
有可能是数据库文件超过操作系统层的文件大小限制，比如fat/fat32以及低版本的Linux，文件最大不可以大于2G（最大扩展到4G），这就需要转换fat32为NTFS，或升级Linux版本。
2、确认磁盘空间没有满
执行 df -h 查看剩余磁盘空间，如果发现磁盘空间确实已经用完，则尽快删除不需要的文件。
如果通过 du 计算各个目录的总和却发现根本不会用完磁盘空间时，就需要注意了，可能是某个被删除的文件还没完全释放，导致 df …
[获取更多]