调试MySQL的一个问题，遇到了“13 - Permission denied”问题。这是一个常见的错误提示。遇到这个问题的时候，结合修改的代码看，经分析后认为几乎不可能出现这样的问题。莫非是同期多人提交，多个patch合并后所致？再结合现象看，初始认为这个现象的出现是不可能,除非是OS错误。(注意,如下过程有精简,保留部分是为了着重说明“13 - Permission denied”问题.原始问题是一个综合性问题)
一现象
1 同样一个测试用例，代码修改前，各个OS平台运行正常。
2 同样一个测试用例，代码修改后，在Windows平台报告“13 - Permission
denied”；但Linux平台运行正常，可以得到期望结果。Windows下错误信息为：
query 'ALTER TABLE t1 FORCE' failed: 7:
Error on rename of '.\test\t1.MYI' to
'.\test\#sql2-11f7c-2.MYI'
(Errcode: 13 - Permission …
我们知道，有时候为了debug或跟踪方便，会临时打开MySQL的general log。如果在线业务请求比较频繁的话，会导致瞬间产生大量的日志，一定程度上会影响IOPS性能。
此外，我们还有一种变通的办法，那就是打开slow query log，然后设置 long_query_time = 0，这样也可以记录所有请求log，而且记录的log比general log还要来的小，他产生的IOPS性能影响可能会比直接打开general log的影响来的小，可事实果真如此吗？我们来对比测试下就知道了。
测试试用MySQL版本： …
[获取更多]我们都知道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 秒。
…
[获取更多]