mysql主从异常及恢复

一、（单主从模式）近期发现从库的主从断开了，尴尬的是断开节点的主库binlog文件是几个月之前的，之前一直没发现，现在已经被自动删除了

  时间间隔太久了，只能通过全备来恢复从库了，我用的是innobackupex来进行全备恢复的

主库进行全备：   innobackupex    --user=root     --password=root      --host=172.17.210.112     备份存放目录

                                可加参数：

                                 --parallel=4 --throttle=400                      并行个数，根据主机配置选择合适的，默认是1个，多个可以加快备份速度。
                                 --stream=tar                                        压缩类型，这里选择tar格式，可以加，可不加。加上文件就小一点，在备份的时候就已经打包好了
                                 --defaults-file=[MY.CNF] 

从库进行备份恢复：1、通过scp -r   将主库备份的目录复制到从库服务器上，关闭从库数据库服务

                                     2、备份datadir目录下的所有数据库文件，可以直接mv到其他目录，最好等恢复好后再删掉

                                     3、innobackupex       --apply-log        /opt/xtrabackup_data       （一开始我没执行后重连主从一直也是异常的，处理了几次还是一直这种提示，只能重新删除datadir的数据重新来，如下图）

                                             （--apply-log    应用 BACKUP-DIR 中的 xtrabackup_logfile 事务日志文件。一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件仍处于不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件使得数据文件处于一致性状态）

                                             

                                    4、innobackupex --defaults-file=/opt/my.cnf --copy-back /opt/xtrabackup_data

                                           (ps:执行的时候提示要删除log目录下iblog目录下的ibdata1，删了之后才能正常执行)

                                            

                                      5、等数据恢复完成重新启动数据库，再重连主从就行了

                                            主从的master_log_file和master_log_pos的值用备份目录中的         xtrabackup_binlog_info        

 

 

 

二、（双主模式）Last_SQL_Error:1594

Relay_Master_Log_File：
当前slave SQL线程读取并执行的relay log的文件中多数近期事件，对应的主服务器二进制日志文件的名称。（说白点就是我SQL线程从relay日志中读取的正在执行的sql语句，对应主库的sql语句记录在主库的哪个binlog日志中）
Exec_Master_Log_Pos：
slave SQL线程当前执行的事件，对应在master相应的二进制日志中的position。（结合Relay_Master_Log_File理解，而且在Relay_Master_Log_File这个值等于Master_Log_File值的时候，Exec_Master_Log_Pos是不可能超过Read_Master_Log_Pos的

处理方案，重建主从连接：
mysql> stop slave;
Query OK, 0 rows affected (0.00 sec)
mysql> reset slave;
Query OK, 0 rows affected (0.13 sec)
mysql> CHANGE MASTER TO MASTER_HOST='主库IP',MASTER_USER='replusr',MASTER_PASSWORD='password' ,MASTER_LOG_FILE='master-bin.003339',MASTER_LOG_POS=494675706;
Query OK, 0 rows affected, 2 warnings (0.01 sec)
mysql> start slave;
 

三、（双主模式）Last_IO_Error:1236

处理步骤
1、检查从库二进制日志
]# mysqlbinlog slave-bin.003304 > 003304.txt

]# tail -50f 003304.txt

通过查看从库二进制日志发现Exec_Master_Log_Pos只到276520850，但是主库上查看主从状态Exec_Master_Log_Pos的值却是276527132，超过了003304这个二进制文件的里面的值

相同方法查看下一个二进制日志文件slave-bin.003305

重新连接下主从，后查看数据库是已经主从恢复正常

 

 

四、（双主模式）Last_SQL_Error:1032      （1062，could not write_rows event）

在master上删除一条记录，而slave上找不到
解决方法：
    由于master要删除一条记录，而slave上找不到故报错，这种情况master都将其删除了，那么从机可以直接跳过。数据重复（1062）也是类似的处理方法
mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
Query OK, 0 rows affected (0.00 sec)

（1062的话，我当时看binlog文件是个insert语句的，如果是单主从，可以直接delete从库上的重复数据，但如果是双主模式的建议还是跳过就行，不要删除）

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)