Mysql不能备份序列_mysql主从同步导致数据同步异常的问题梳理

在线QQ客服：1922638

专业的SQL Server、MySQL数据库同步软件

5–利用pt-table-checksum查抄主从库表数据否一致

导致数据同步异样。mysql同步过程中会出现很多成绩。

以下梳理了几种主从同步中可能存在成绩:

也就是MySQL数据库主从同步延迟1slave运行过慢不能与master同步。

但是实际线上环境下，MySQL数据库slave服务器延迟的景象是非常广泛的MySQL复制允许从机进行SELECT操纵。由于从机延迟的联系，很难将读取把持转向到从机。这就导致了有了以下一些潜规则:实时性要求不高的读取把持可以或许放到slave服务器，实时性要求高的读取把持放到master服务器”从机仅能做前一天的统计类查询”

从而不能预防更新slave数据提早。slave滞后即slave不能快速执行来自于master所有事务。

slave做select操纵。形成slave滞后的原由有很多。mysqlmaster-slav架构中master仅做写入、更新、删除操纵。

slave同步提早的道理

主库对所有DDL和DML发生的日志写进binlog因为binlog顺序写，MySQL主从复制都是单线程的操纵。所以效率很高。

SlaveIOThread线程从主库中binlog中读取取日志。

SlaveSQLThread线程将主库的DDL和DML把持事务在slave中重放。DML和DDLIO操纵是随即的不是挨次的老本高很多。

又或者一个DML语句(大事件务、大查询)履行了几分钟卡住了那么所有以后的DML会等待这个DML执行完才会继续执行，因为SQLThread也是单线程的若是slave上的其他盘问发生lock争用。这就导致了延时。也许有人会质疑:主库上那个相同的DDL也会执行几分钟，为何slave会延时？起因是master可以或许并发履行，而Slave_SQL_Run线程却不可以。

slave同步提早的可以或许起因

而master有很多线程可以或许并行执行事件。1–slaveI/O线程推迟读取日志中的事件消息；最常见原因是slave单线程中执行所有事件。

2–带来低效毗连的长查询、磁盘读取的I/O制约、锁竞争和innodb线程同步策动等。

3–Master负载；Slave负载

4–搜集提早

5–机器设置装备摆设(cpu内存、硬盘)

当主库的TPS并发较高时，主从同步提前怎么发生的总之。发生的DDL数量跨越slave一个sql线程所能处理的承受范围时，主从同步就会产生延时；或者当slave中有大型queri语句发生了锁等候也会产生延时。

如何查抄同步提早

1–可以或许通过比对masterslave上的日志地位

这个值代表主从同步延迟的时候，2–经由过程”showslavestatus”检查Seconds_Behind_Mast值。值越大声名提前越严重。值为0为正常情况，正值表示已经出现提早，数字越大从库落伍主库越多。

3–利用percona-toolkitpt-hearbeat工具履行检查。

增添同步提早的把持计划

1–增添锁竞争

必要考虑重构盘问语句，如果盘问导致大批的表锁定。尽量预防过量的锁。

2–负载平衡

可以或许增添每一个slave执行查问的次数和时间，搭建几多slave并且利用lv或nginx履行盘问负载平衡。从而将更多的时辰用于去处理主从同步。

3–salv较高的机器设置装备摆设

4–Slave调整参数

设置装备摆设sync_binlog=1innodb_flush_log_at_trx_commit=1等设置。而Slave可以或许封闭binloginnodb_flush_log_at_trx_commit也可以或许设置为0来提高sql执行效力(这两个参数很管用)为了保障较高的数据保险性。

5–并行复制

即有单线程的复制改成多线程复制。

从库有两个线程与复制相关:io_thread担负从主库拿binlog并写到relaylogsql_thread担负读relaylog并执行。

尔后由一组worker_thread来负责执行。多线程的思路就是把sql_thread变成披发线程。

有不同的便是sql_thread披发战略。的确一切的并行复制都是这个思绪。

MySQL5.7真正并行复制enhancmulti-threadslaveMTS很好的处理了主从同步复制的提前成绩。

2slave同步状态中出现Slave_IO_Running:NO

报错:Last_IO_Error:Gotfatalerror1236frommasterwhenreaddatafrombinarilog:\’Couldnotfindfirstlogfilenameinbinarilogindexfile\’

即要确保正在利用的那个最新binlog文件在master主库机器上存在起因1清理数据导致主从库不同步(条件是主库的binlog日志没有被暴力删除或错误删除。

处置惩罚法子:

1先进入slave中执行:”slavestop;”来停止从库同步；

2再去master中执行:”flushlogs;”来清空日志；

首要是日记的文件和posit3而后在master中执行:”showmasterstatus;”查抄下主库的状况。

履行:”CHA NGEMA STERTO……执行同步指令4尔后回到slave中。

发现主库的mysql_bin.index文件中第一个文件不存在出现此类报错可能是因为你slave由于某种原由遏制了好长一段起因2该错误发生在从库的io历程从主库拉取日志时。

当你重启slave复制的时辰，主库上找不到响应的binlog,时候。会报此类错误。或是由于某些设置主库上的binlog被删除了导致从库获取不到对应的binglogfile

处置惩罚法子:

必要重新执行slave同步操纵。1为了预防数据丧失。

决定基于时辰过时的删除方式还是基于空间把持率的删除体式格局。2重视主库binlog清理战略。

3记住最好不要利用”rm-rf”命令删除binlogfile这样不会同步修改mysql_bin.index记实的binlog条款。删除binlog时刻确保主库保留了从库”showslavestatus”

最好给备份出来。Relay_Master_Log_Fil对应的binlogfile任何时刻都不能删除正在利用的那个最新binlog文件；最好把bin-log文件不要删除。

操纵起因1处理打算明显是处置惩罚不了此时的处置惩罚计划是起因2情况下。

从库上执行:

mysql>stopslave;

mysql>resetslave;

mysql>startslave;

mysql>showslavestatuG;

3slave同步状态中出现Slave_IO_Running:Connecting

导致这个过错的原由个别是

未开启3306端口1–搜集欠亨。

2–权限成绩(毗连master用户名和密码跟master授权不一致)

3–连接时用的logfile和po节点跟”showmasterstatus”功效不一致

4slave同步状态中出现Slave_SQL_Running:No即slave不合步！

处置惩罚法子:

担当同步。第一种方法:忽视错误后。

或者要求数据可以或许不完全统一的环境，该体式格局适用于主从库数据相差不大。数据要求不严格的环境(下面均为在slave机器上的操纵)

mysql>stopslave;

前面的数字可变；或在my.cnf里添加slave-skip-errors=al上面已在配置中添加)mysql>setglobalsql_slave_skip_counter=1;//表示跳过一步错误。

mysql>startslave;

mysql>showslavestatusG//检查:

完全同步第二种方法:重新做主从。

或者要求数据完全同一的环境该体式格局适用于主从库数据相差较大。

1–master主库上操作

防备数据写入。重视该处是锁定为只读状态，mysql>flushtablwithreadlock;//履行锁表。语句不分辩大小写

就备份指定库)重视数据库备份必定要定期进行，#mysqldump–lock-all-t–all-databas–flush-log–master-data=2>/root/allsql.sql//主库完全备份(若是是指定库同步。确保数据满有把握

注重logfile和po节点，mysql>showmasterstatus;//检查master状况。slave同步会用到

履行数据复原#scpmysql.bak.sqlroot@192.168.1.102:/tmp///把备份文件传到slave从库机器。

2–slave从库操作

mysql>stopslave;

mysql>sourc/tmp/mysql.bak.sql

master_user=\’slave\’,mysql>changmastertomaster_host=\’192.168.1.101\’.master_port=3306…….

mysql>startslave;

mysql>showslavestatusG

…….

Slave_IO_Running:Yes

Slave_SQL_Running:Yes

此种体式格局中最为关键重要有两步:

并滚动日志；①主服务器上锁表做完全备份。

②从服务器上进行半道恢复.

5slave中继日志relay-log破坏？

甚么是中继日志？

从服务器将主服务器的二进制日志文件拷贝到本身的主机上放在中继日志中，relay-log寄放在从服务器上。尔后挪用SQL线程按照拷中继日志文件中的二进制日志文件执行以便就可达到数据的同步

如何中继日志避免:

my.cnf文件中开启relay_log_recover=1即可防止。mysql5.6版本后。

6slave连接超时且重新连接频仍

其中一台slave可以或许会频繁超时或损失后重新连接序列。若有几多slave且没有设置server_id或两个slave设置不异的server_id将有可以或许会出现服务器的ID矛盾。这类情况下。

所以必定要确保每台slave及mastermy.cnf中都要设置不一样的server_id

7主库与从库使用不同的存储引擎造成不合步

提示表不存在8从库同步时。

过错:Last_Error:Errorexecutrowevent:\’Tabl\’test.t1\’doesn\’texist\’

处置惩罚方式:从库重建这张表。

9max_allowed_packet设置过小导致slave报错

max_allowed_packet默许是16M主从库的max_allowed_packet值和备库上的不匹配。

主库可以或许会记录一个备库认为过大的包。当备库获取到该二进制日志事件时，这情况下。可以或许会碰到各种成绩，如无限报错和重试、中继日志粉碎等。

具体浮现:

出现以下错误提醒:从库的Slave_IO_Thread死掉了查抄后。

Gotapacketbiggerthan\’max_allowed_packet\’bytes

主库的设置大于从库，很明显是因为max_allowed_packet设置太小导致的尔后查检主从库上的设置。由于max_allowed_packet情况参数，先调整从库上的max_allowed_packet与主库相同，重新单独发动I/O线程就正常了

且当前的事件长度大于了从库的max_allowed_packet,情理申明:binlog事件以RBR格式记实。导致无奈SlaveIO不能正常读取masterbinlogevent.

10master上删除一条记录时出现的毛病

slave上因找不到这条记录而报错。master上删除一条记录后。

处置惩罚方式:

故可以跳过。由于主库上已经对这条语句进行了删除操纵。

声名主从同步可以或许数据会有不一致的情况产生，这类情况下。所以必要利用pt-table-checksum履行数据库不合性比对。

参考:mysql主从同步(3-percona-toolkit对象(数据不合性监测、提前监控)操纵梳理)

而slave却找不到11master更新一条记录。

master有某条记录，主从数据不致时。但在salv上没有这条记录，若在master上进行更新这条记录，则在slave中可能报错。

处置惩罚方式:

查主库上的二进制日志。1–遵照从库发生异常的地位。

找到更新后的整条记录。2–遵照主库二进制日志信息。

执行insert操纵。3–从库上执行在主库上找到记录消息。

再同步slave4–跳过这条语句。