1.1236错误解决办法
由于主服务器异外重启,导致从报错,错误如下:mysql>showslavestatus\G
Master_Log_File:mysql-bin.000288
Read_Master_Log_Pos:627655136
Relay_Log_File:mysql-relay-bin.000990
Relay_Log_Pos:627806457
Relay_Master_Log_File:mysql-bin.000288
Slave_IO_Running:No
Slave_SQL_Running:Yes
Exec_Master_Log_Pos:627655136
Relay_Log_Space:627806663
......
Last_IO_Error:Gotfatalerror1236frommasterwhenreadingdatafrombinarylog:'Clientrequestedmastertostartreplicationfromimpossibleposition',readuptolog'mysql-bin.000288',position627655136.
登陆到主服务器查看binlog日志,先按照错误点的标记去主服务器日志中查找,没有看到这个位置。shell>/usr/local/mysql/bin/mysqlbinlog--start-position=627655136/usr/local/mysql/data/mysql-bin.000288
/*!40019SET@@session.max_insert_delayed_threads=0*/;
/*!50003SET@OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER/*!*/;
#at4
#11101013:31:19serverid4end_log_pos106Start:binlogv4,serverv5.1.45-log
created11101013:31:19
#Warning:thisbinlogiseitherinuseorwasnotclosedproperly.
BINLOG'
F1aTTg8EAAAAZgAAAGoAAAABAAQANS4xLjQ1LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC
'/*!*/;
DELIMITER;
#Endoflogfile
ROLLBACK/*addedbymysqlbinlog*/;
/*!50003SETCOMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
查看这个binlog最后一部分:shell>mysqlbinlog/usr/local/mysql/data/mysql-bin.000288>binlog.txt
shell>tail-fbinlog.txt
#at627625495#11101016:35:46serverid1end_log_pos627625631Querythread_id=45613333exec_time=32758error_code=0SETTIMESTAMP=1318289746/*!*/;deletefromfreeshipping_bef_updatewherepart='AR-4006WLM'andcode=''/*!*/;#at627625631#11101016:35:46serverid1end_log_pos627625751Querythread_id=45613333exec_time=32758error_code=0SETTIMESTAMP=1318289746/*!*/;deletefromshippingFee_specialwherepart='AR-4006WLM'/*!*/;DELIMITER;#EndoflogfileROLLBACK/*addedbymysqlbinlog*/;/*!50003SETCOMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
找到最接近错误标记627655136的一个position是627625631.再回到slave机器上,changemaster,将postion指向这个位置.mysql>stopslave;
mysql>changemastertomaster_log_file='mysql-bin.000288',master_log_pos=627625631;
mysql>startslave;
再次查看,复制已恢复正常。mysql>showslavestatus\G
***************************1.row***************************
Slave_IO_State:Queueingmastereventtotherelaylog
Master_Host:192.168.21.105
Master_User:rep
Master_Port:3306
Connect_Retry:10
Master_Log_File:mysql-bin.000289
Read_Master_Log_Pos:25433767
Relay_Log_File:mysql-relay-bin.000003
Relay_Log_Pos:630
Relay_Master_Log_File:mysql-bin.000289
Slave_IO_Running:Yes
Slave_SQL_Running:Yes
……
2.10621054等错误解决办法
如果日志中出现了Error_code:10621054这样代码,可能是master是跳过错误的insert或update操作,但是被记录到了二进制日志中,slave会依据二进制中的语句做相同的动作,就会报错。mysql>showslavestatus\G
Master_Log_File:mysql-bin.000288
Read_Master_Log_Pos:627655136
Relay_Log_File:mysql-relay-bin.000990
Relay_Log_Pos:627806457
Relay_Master_Log_File:mysql-bin.000288
Slave_IO_Running:No
Slave_SQL_Running:Yes
Exec_Master_Log_Pos:627655136
Relay_Log_Space:627806663
Last_Errno:1062
Last_Error:Error'Duplicateentry'193'forkey'PRIMARY''onquery.Defaultdatabase:'tso'.Query:'insertintotb_infovalues(193,'y10')'
……
解决办法:mysql>stopslave;
mysql>setgloablesql_slave_skip_counter=1;
mysql>startslave;
在主从库维护中,有时候需要跳过某个无法执行的命令,需要在slave处于stop状态下,执行setglobalsql_slave_skip_counter=N以跳过命令。常用的且不易用错的是N=1的情况,这里详细介绍N的意义,及使用注意事项。
MySQL从库从主库上复制binlog文件内容到本地执行。在binlog上命令以event的形式存在,并非一个命令对应一个event。以一个insert语句为例(引擎InnoDB、binglog_format=statement),在binlog中实际上有三个event,分别为begin\insert\commit。命令类型都是Query_log_event。
而setglobalsql_slave_skip_counter=N的意思,即为在startslave时,从当前位置起,跳过N个event。每跳过一个event,则N--。
如果当前的执行位置是某个insert语句开头,那使用N=1实际上是从begin\insert\commit的第二个开始执行,这个insert语句还是不能被跳过?
实际上这里还有两个策略:
1、若N=1且当前event为BEGIN,则N不变,跳过当前event继续。
2、若N=1且当前event处于一个事务之内(BEGIN之后,COMMIT之前),则N不变,跳过当前event继续。
说明:其实上面两个策略合起来就是一句话,当N=1时,会连续跳过若干个event,直到当前所在的事务结束。
当然如果N>1,则每跳过一个event都要N--.
命令举例:
所以我们平时最常用的N=1的情况,都是下一个事务。
假设某个Pos之后执行如下命令(引擎InnoDB、binglog_format=statement),
insertintotvalues(x1);
begin;
insertintotvalues(x2);
insertintotvalues(x3);
commit;
insertintotvalues(x4);
你的从库stop在Pos上,假设你要跳过前面几个命令直接执行插入x4的操作,则你的N设置为4或5或6或7均可。(X1语句为3个event)
其他说明:
上面举例中都特别说明了在innodb引擎和statement模式下。其他情况区别如下:
1、若引擎为myisam(等不支持事务的引擎),且在statement下,则binlog中不会有begin和commit,每个命令都是一个event;
2、row模式的binlog里,一个insert语句实际上是两个event(Table_map_event和Row_log_event),计算时应与statement不同。
3、在row模式下,不论引擎是否支持事务,一个insert语句都会加上BEGIN和commit,也即变成4个event。
4、基于InnoDB引擎表的insert/delete/update操作都有显式样的BEGIN/COMMIT.
上面举的这个例子中,若为row模式,则要直接执行X4语句需要设置的N为5~10均可。
小结:
1、setglobalsql_slave_skip_counter=N中的N是指跳过N个event
2、最好记的是N被设置为1时,效果跳过下一个事务。
3、跳过第N个event后,位置若刚好落在一个事务内部,则会跳过这整个事务
4、一个insert/update/delete不一定只对应一个event,由引擎和日志格式决定
通常情况下从数据库在复制时发现任何错误都会停止复制,这样做是为了保证与主数据库数据完整性,有时候一些错误不会影响到主从数据完整性的问题我们就可以修改slave配置文件来/etc/f忽略:slave-skip-errors=1062
如果发生代码为1062的错误都会被忽略slave-skip-errors=1062,1054
如果发生代码为1062和1054的错误都会被忽略slave-skip-errors=all
忽略所有错误
3.通用解决办法
在从库上运行以下shell程序,把数据库从主库上导到从库上(红色部分根据实际修改),重新设置同步binlog日志文件和同步点。#!/bin/sh
#
#Description:Recovemysqlreplication.
read-p"MasterIP:"Master_IP
read-p"MasterAdminUserName:"Master_Admin_UserName
read-p"MasterAdminPassword:"Master_Admin_Password
echo"-->LockMaster..."
mysql-h$Master_IP-u$Master_Admin_UserName-p$Master_Admin_Password-e"FLUSHTABLESWITHREADLOCK;"
echo"-->GetMasterLogState..."
mysql-h$Master_IP-u$Master_Admin_UserName-p$Master_Admin_Password-e"showmasterstatus\G;">masterStatus.txt
LogFile=`grep"File"masterStatus.txt|awk'{print$2}'`
LogPosition=`grep"Position"masterStatus.txt|awk'{print$2}'`
rm-rfmasterStatus.txt
echo"DumpMasterDate..."
#/usr/local/mysql/bin/mysqldump-h$Master_IP-u$Master_Admin_UserName-p$Master_Admin_Passwordtso>tso.sql
echo"-->UnlockMaster..."
mysql-h$Master_IP-u$Master_Admin_UserName-p$Master_Admin_Password-e"UNLOCKTABLES;"
echo"-->MasterDone"
read-p"ChangingSlave'sMaster,Enterrootpasswordofmysql:"password
mysql-uroot-p$password<
stopslave;
changemastertomaster_host='$Master_IP',master_user='repl',master_password='itserver',master_log_file='$LogFile',master_log_pos=$LogPosition;
usetso;
sourcetso.sql;
startslave;
EOF
这种办法能解决任何同步错误,但由于主库要锁表,在数据量比较大的情况耗时较长,建议在生产环境下尽量少使用。
一、MySQLInnoDB表空间损坏的恢复
错误日志……
InnoDB:Databasepagecorruptionondiskorafailed
InnoDB:filereadofpage5761.
InnoDB:Youmayhavetorecoverfromabackup.
InnoDB:Itisalsopossiblethatyouroperating
InnoDB:systemhascorrupteditsownfilecache
InnoDB:andrebootingyourcomputerremovesthe
InnoDB:error.
InnoDB:Ifthecorruptpageisanindexpage
InnoDB:youcanalsotrytofixthecorruption
InnoDB:bydumping,dropping,andreimporting
InnoDB:thecorrupttable.YoucanuseCHECK
InnoDB:TABLEtoscanyourtableforcorruption.
InnoDB:Seealso外链网址已屏蔽
InnoDB:aboutforcingrecovery.
InnoDB:Endingprocessingbecauseofacorruptdatabasepage.
……
解决方法为:在配置文件[mysqld]段内添加以下行,重启MySQL服务。待MySQL恢复后,注释这行,再次重启MySQL服务。[mysqld]
innodb_force_recovery=4
说明:
1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行,如主线程需要执行fullpurge操作,会导致crash。
3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
4(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志,InnoDB存储引擎会将未提交的事务视为已提交。
6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。
本文出自 “706737” 博客,谢绝转载!