今天Mysql双机遇到两个问题，从网上整理下解决方案，记录下来：

通过以下命令行可查看异常信息

Sql代码 

 具体细节可查看Mysql日志。

问题一：
 命令行报错如下

从字面理解就是，从服务器请求了主服务器的一个错误的复制位置。比如主服务器上的BLIN_LOG里没有这个POSITION.
解决办法：
首先查看主服务器的日志文件中是否有此行，使用命令

Java代码 

 在log文件里查找662720845对应的行或者和这个数字接近的行（先从小的试试，无法恢复再从大的试）， 
  log文件内容类似：
Java代码 

 然后重新设置复制位置，如下
Java代码 

如果找不到，可用如下命令查看mysql-bin.000073的最大位置
Java代码 

 如果大小远小于662720845，则可以跳过这个日志，从下个日志开始复制。
Java代码 

问题二：
  错误代码如下

  如果日志中出现了这样代码，可能是错误的select，或update操作，master是跳过这些操作，但是被记录到了二进制日志中，slave会依据二进制中的语句做相同的动作，就会报错，知道原理了要做的操作就很简单了。
  解决方法
Java代码 

如果你不想再遇到这种错误，可以写到slave配置文件中格式如下： 

 问题三：
 错误代码如下

以上异常可能由内存溢出或者硬盘空间不足导致。
 解决办法
从最近一次复制结束的位置复制即可
Java代码 

Java代码 

备注：

         mysql replication 中slave机器上有两个关键的进程，死一个都不行，一个是slave_sql_running，一个是Slave_IO_Running，一个负责自己的slave mysql进程，一个负责与主机的io通信。
         如果是slave_io_running no了，可能有三种情况，一个是网络有问题，第二个是有可能my.cnf有问题，最后一个是授权的问题，replication slave和file权限是必须的。
         一旦io为no了先看err日志，看看报什么错，很可能是网络，也有可能是包太大收不了，这个时候主备上改max_allowed_packet这个参数。
        如果是slave_sql_running no了，那么也有两种可能，一种是slave机器上这个表中出现了其他的写操作，就是程序写了，这个是会有问题的，还有一种占绝大多数可能的是slave进程重启，事务回滚造成的，这也是mysql的一种自我保护的措施，像关键时候只读一样。 这个时候想恢复的话，只要停掉slave，set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;(参考问题二解决方法)，再开一下slave就可以了。

--转自