mysql数据库做主从复制，不仅可以为数据库的数据做实时备份，保证数据的完整性，还能做为读写分离，提升数据库的整体性能。但是，mysql主从复制经常会因为某些原因使主从数据同步出现异常。因此，下面介绍的是mysql主从同步异常的原因及恢复的方法。
auto.cnf 配置问题
这个问题是在部署主从复制的时候，可能会遇到的
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs;
these UUIDs must be different for replication to work
【2】分析：
当mysql做了主从时，每个mysql都会有个uuid 作为唯一标识的。上面是由于主从复制的mysql数据库了相同的UUID，所以，只需要修改auto.cnf配置文件即可。
【3】解决方法
&1&查找auto.cnf文件的位置(位置一般为:/var/lib/mysql/auto.cnf)
find / -iname auto.cnf
&2&将文件中的uuid修改为不同数值。
my.cnf配置问题
这个问题也是在部署主从复制的时候，可能会遇到的
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL these ids must be different for replication to work (or the –replicate-same-server-id option must be used on slave but this does n please check the manual before using it).
在mysql的主从配置中，每台mysql数据库的my.cnf中的server-id 必须是唯一，但是有的时候可能因为粗心而配成了相同的数值，也有可能mysql没有加载到my.cnf 文件中的server-id。
【3】解决方法
&1&找到mysql的配置文件my.cnf(默认位置为:/etc/my.cnf)
find / -name my.cnf
&2&修改从服务器的my.cnf配置文件中的server-id(注意要改为与主服务器不同的）
&3&在从服务器的数据库中直接添加server_id(此server_id数值与my.cnf中的一致)
set global server_id=2;
主库重启(数据库服务器宕机)
这个问题常见于运维mysql数据库主从的过程中，一般都是由于数据库的误操作引起的，也有可能是数据库服务器因某些原因宕机或重启引起的。
数据库备份一定要定期进行，确保数据万无一失 .
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘binlog truncated in consider out of
the first event ‘mysql-bin.001989’ at 9179, the last event read from ‘./mysql-bin.001989’ at 9179, the last byte read from ‘./mysql-bin.001989’ at 9179.’
由报错可看出是由于从库的二进制文件位置与主库的不一致导致的
【3】解决方法
&1&查看主库的二进制文件的位置
mysql -uroot -p’…..’
进入数据库
重点关注：
&2&查看从库的状态
show slave status\G ；
重点关注下列两个的状态[yes/no]：
Slave_IO_Running
Slave_SQL_Running
&3&解决方法一：
忽略错误后，继续同步
(适用于主库与从库数据相差不大；要求数据可以不完全统一，数据要求不严格的情况）
{1}进入从库操作：
mysql -uroot -p‘…’
{2}停止从库同步
{3}跳过1步错误（后面的数字可更改）
set global sql_slave_skip_counter =1;
{4}开启从库
{5}查看从库状态
show slave status\G;
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
&4&解决方法二
重新做主从，完全同步
(适用于主库从库的数据相差较大；要求数据完全统一的情况 )
{1}先进入主库，进行锁表，此处锁定为只读状态，防止数据写入 (可选，因如有数据库备份，可直接利用备份)
{2}进行数据备份,把数据备份为.sql的文件(可选，因如有数据库备份，可直接利用备份)
mysqldump -uroot -p‘密码’
–all-databases & mysql.back.sql
{3}进入主库，进行解锁(可选，因如有数据库备份，可直接利用备份)
{4}把mysql的备份文件传输到从库服务器上(位置任意，但要能找到)
scp -r /root/mysql.bask.sql root@node2:/tmp/
{5}进入从库，停止从库的状态
清除slave上的同步位置，删除所有旧的同步日志，使用新的日志重新开始.(使用前先停止slave服务）
{6}在从库中导入数据备份
source /tmp/mysql.back.
mysql -uroot -p‘….’
database -f & /tmp/mysql.bask.sql
(-f 为跳过错误的Sql，继续往下执行，可不加)
{7}设置从库同步
change master to master_host = ‘主库的IP’, master_user = ‘设置主从时设定的主库的用户’, master_port=主库的端口, master_password=’主库设定的密码’, master_log_file = ‘mysqld-bin.001989’, master_log_pos=;
master_log_file与master_log_pos
是主库show master status信息里的| File与Position
{8}重新开启从库同步
{9}查看同步状态
mysql& show slave status\G 查看：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
mysql主从同步错误恢复
1 确认错误在mysql从库上执行：show slave status \G;输出从库同步过程中遇到的错误sql语句。2 关闭从库，跳过错误然后执行：SET GLOBAL SQL...
mysql主从同步常见异常及恢复方法
1. 一般的异常只需要跳过一步即可恢复
&SET GLOBAL sql_slave_skip_counter...
因线上项目上使用了主从读写分离，收到了主从同步告警，发现从从上读取到的数据与主数据库上的不一致：
1、使用show slave status\G，查看到seconds_behind_master大于...
MySQL主从故障修复
192.168.1.2 主
192.168.1.3 从
192.168.1.4 主 4又是2的从库
192.168.1.5 从
有人修改了192.168....
MySQL主从同步常见异常及恢复方法
mysql主从同步常见异常及恢复方法
1. 一般的异常只需要跳过一步即可恢复
&SET GLOBAL sql_slave_skip_c...
1.问题一：主从复制，中继日志不断增长，如何设置中继日志自动清除
　　vi 配置文件my.cnf,在mysqld下增添
　　relay_log_purge=1 (自动清除中继日志打开)
　　重启...
打开数据从库（slave），运行
mysql&show slave status\G;
slave_IO_Running:No 说明数据库同步操作失败
报错提示：
1、出现错误提示、
Slave I/O: error connecting to master 'backup@192.168.1.x:3306' - retry-ti...
版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://storysky.blog.51cto.com/28...
没有更多推荐了，01:47 提问
关于读写分离、数据同步的问题
简单了解了一下读写分离的实现机制和具体操作，但是还有部分不是特别明白。
假设现在我有两台服务器，一台线上正式使用，另一台用于作为备用服务器，但是数据和第一台服务器是同步的。现在为了能充分利用其两台机子，做了读写的分离。把查询的所有业务都丢给第二台服务器，而写入、删除、修改等操作都交给第一台服务器。这是我简单理解的读写分离的机制。
不知道这样对不对。
那么 如果我这样理解的话，我发现是有问题的。
如果原来的备用服务器是用来做为提供查询的用的，而原来的正式服务器做了其他的操作的话，那我现在一条数据进行修改了，那么也是应该同步到了第二台机器上面，这样也是一个写入的操作，那么这样设计还有意义吗？
或者说是我理解错误了？
按赞数排序
是这样的，读写分离是指，如果用户执行的sql不修改数据，比如select，那么从任意节点返回数据
如果是修改数据的（update delete insert），那么需要做同步。
在某些场合，查询要比修改的数量多很多（比如微博，浏览的人很多，发布微博的人很少，或者大多时候，人们以浏览为主），那么性能就会有很大的提高。如果写入的数量大，查询的数量小，的确你说的，没有太大的意义。
----------------------biu~biu~biu~~~在下问答机器人小D，这是我依靠自己的聪明才智给出的答案，如果不正确，你来咬我啊！
准确详细的回答，更有利于被提问者采纳，从而获得C币。复制、灌水、广告等回答会被删除，是时候展现真正的技术了！
其他相关推荐standby log的异常状态导致DG数据同步异常显示failure destination_其它数据库-织梦者
当前位置:&>&&>& > standby log的异常状态导致DG数据同步异常显示failure destination
standby log的异常状态导致DG数据同步异常显示failure destination
问题的现像:
1.主库的状态一直显示是failure destion
select switchover_status from v$database
failure destination
2.主库的归档日志不能即时传递至备库，重启备库才能把没传过来的日志伟递到备库。并且传送完之后，仍然主库的switchover_status 仍然显示是failure destinnation
3.主库的alert.log显示
eat failed to connect to standby 'STANDBY'. Error is 12514.
15:07:40.359000 +08:00
Error 12514 received logging on to the standby
PING[ARC2]: Heartbeat failed to connect to standby 'STANDBY'. Error is 12514.
备库显示：
RFS[9]: Assigned to RFS process 19780
RFS[9]: No standby redo logfiles created for thread 1
RFS[9]: No standby redo logfiles selected (reason:7)
解决办法：
初步以为是密码文件问题:
复制主库的密码文件至备库，发现仍然不显示同样的问题
在主备上都可以正常运行以下代码
sqlplus zabbix/zabbix@primary
sqlplus zabbix/zabbix@standby
sqlplus zabbix/zabbix@primary
sqlplus zabbix/zabbix@standby
都是正常登录，说明listener 是没有问题.
所以不是lisenter 问题，不是密码文件问题，也不是网络连接问题，DG参数反复检查没问题,那么问题出在哪？
查看备库的alert.log 一些记录如下：
备库显示：
RFS[9]: Assigned to RFS process 19780
RFS[9]: No standby redo logfiles created for thread 1
RFS[9]: No standby redo logfiles selected (reason:7)
明明是有standby redo logfile 的
SQL& select group#,bytes/,status from v$standby_
GROUP# BYTES/ STATUS
---------- --------------- ----------
4 150 UNASSIGNED
5 150 UNASSIGNED
6 150 UNASSIGNED
7 150 UNASSIGNED
ADG是要使用standby redo logfile 来通过主库的online redo logfile 来同步数据的，同步时这里的状态是active
将备库的standby redo logfile 删除重建，并且大小与主库的redo logfile 一致
SQL& alter system set standby_file_management=
系统已更改。
SQL& alter database drop standby logfile group 4;
数据库已更改。
SQL& alter database drop standby logfile group 5;
数据库已更改。
SQL& alter database drop standby logfile group 6 ;
数据库已更改。
SQL& alter database add standby logfile group 4 ('E:\LMIS\LOG\STDREDO04.LOG') si
数据库已更改。
SQL& alter database add standby logfile group 5 ('E:\LMIS\LOG\STDREDO05.LOG') si
数据库已更改。
SQL& alter database add standby logfile group 6 ('E:\LMIS\LOG\STDREDO06.LOG') si
数据库已更改。
SQL& alter database drop standby logfile group 7 ;
数据库已更改。
SQL& alter database add standby logfile group 7 ('E:\LMIS\LOG\STDREDO07.LOG') si
数据库已更改。
SQL& alter system set standby_file_management=
系统已更改。
SQL& select group#,member from v$logfile order by group#
GROUP# MEMBER
---------- ----------------------------------------
1 E:\LMIS\LOG\REDO01B.LOG
1 E:\LMIS\LOG\REDO01.LOG
2 E:\LMIS\LOG\REDO02.LOG
2 E:\LMIS\LOG\REDO02B.LOG
3 E:\LMIS\LOG\REDO03.LOG
3 E:\LMIS\LOG\REDO03B.LOG
4 E:\LMIS\LOG\STDREDO04.LOG
5 E:\LMIS\LOG\STDREDO05.LOG
6 E:\LMIS\LOG\STDREDO06.LOG
7 E:\LMIS\LOG\STDREDO07.LOG
已选择10行。
SQL& select * from v$managed_
select * from v$managed_log
第 1 行出现错误:
ORA-00942: 表或视图不存在
SQL& desc v$standby
ORA-04043: 对象 v$standby 不存在
SQL& desc v$standby_log
名称 是否为空? 类型
----------------------------------------- -------- ----------------------------
GROUP# NUMBER
DBID VARCHAR2(40)
THREAD# NUMBER
SEQUENCE# NUMBER
BYTES NUMBER
BLOCKSIZE NUMBER
USED NUMBER
ARCHIVED VARCHAR2(3)
STATUS VARCHAR2(10)
FIRST_CHANGE# NUMBER
FIRST_TIME DATE
NEXT_CHANGE# NUMBER
NEXT_TIME DATE
LAST_CHANGE# NUMBER
LAST_TIME DATE
SQL& select group#,status from v$standby_
GROUP# STATUS
---------- ----------
4 UNASSIGNED
6 UNASSIGNED
7 UNASSIGNED
SQL& alter database recover managed standby database using current logfile disco
数据库已更改。
SQL& select process,status,sequence# from v$managed_
PROCESS STATUS SEQUENCE#
--------- ------------ ----------
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CLOSING 45707
ARCH CLOSING 45708
RFS IDLE 0
RFS IDLE 0
RFS IDLE 0
RFS IDLE 45709
MRP0 APPLYING_LOG 45709
已选择9行。
PROCESS STATUS SEQUENCE#
--------- ------------ ----------
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CLOSING 45709
ARCH CLOSING 45708
RFS IDLE 0
RFS IDLE 0
RFS IDLE 0
RFS IDLE 45710
MRP0 APPLYING_LOG 45710
已选择9行。
如上所示ADG恢复正常
standby redo logfile 的异常经常会导致ADG同步失败。
以上就是standby log的异常状态导致DG数据同步异常显示failure destination的全文介绍,希望对您学习和使用数据库有所帮助.
这些内容可能对你也有帮助
更多可查看其它数据库列表页。
猜您也会喜欢这些文章mysql主从同步导致数据同步异常的问题梳理(一)
】 浏览:93次
在同步过程中会出现很多问题，导致数据同步异常。
以下梳理了几种主从同步中可能存在的问题:
1）slave运行过慢不能与master同步，也就是MySQL主从同步延迟
MySQLslave服务器延迟的现象是非常普遍的，MySQL复制允许从机进行SELECT操作，但是在实际线上环境下，由于从机延迟的关系，很难将读取操作转向到从机。这就导致了有了以下一些潜规则：“实时性要求不高的读取操作可以放到slave服务器，实时性要求高的读取操作放到master服务器”，“从机仅能做前一天的统计类查询”。
slave滞后即slave不能快速执行来自于master的所有事件，从而不能避免更新slave数据延迟。
mysql的master-slave架构中master仅做写入、更新、删除操作，slave做select操作。造成slave滞后的原因有很多。
slave同步延迟的原理
MySQL的主从复制都是单线程的操作，主库对所有DDL和DML产生的日志写进binlog，由于binlog是顺序写，所以效率很高。
Slave的IO Thread线程从主库中bin log中读取取日志。
Slave的SQL Thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随即的，不是顺序的，成本高很多。
由于SQL Thread也是单线程的，如果slave上的其他查询产生lock争用，又或者一个DML语句（大事务、大查询）执行了几分钟卡住了，那么所有之后的DML会等待这个DML执行完才会继续执行，这就导致了延时。也许有人会质疑：主库上那个相同的DDL也会执行几分钟，为什么slave会延时？原因是master可以并发执行，而Slave_SQL_Running线程却不可以。
slave同步延迟的可能原因
& & 1--slave的I/O线程推迟读取日志中的事件信息；最常见原因是slave是在单线程中执行所有事务，而master有很多线程可以并行执行事务。
& & 2--带来低效连接的长查询、磁盘读取的I/O限制、锁竞争和innodb线程同步启动等。
& & 3--Master负载；Slave负载
& & 4--网络延迟
& & 5--机器配置（cpu、内存、硬盘）
（主从同步延迟怎么产生的？）总之，当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能处理的承受范围时，主从同步就会产生延时；或者当slave中有大型query语句产生了锁等待也会产生延时。
如何查看同步延迟
& & 1--可以通过比对master、slave上的日志位置
& & 2--通过&show slave status&查看Seconds_Behind_Master的值，这个值代表主从同步延迟的时间，值越大说明延迟越严重。值为0为正常情况，正值表示已经出现延迟，数字越大从库落后主库越多。
& & 3--使用percona-toolkit的pt-hearbeat工具进行查看。
减少同步延迟的操作方案
& & 1--减少锁竞争
如果查询导致大量的表锁定，需要考虑重构查询语句，尽量避免过多的锁。
& & 2--负载均衡
搭建多少slave，并且使用lvs或nginx进行查询负载均衡，可以减少每个slave执行查询的次数和时间，从而将更多的时间用于去处理主从同步。
& & 3--salve较高的机器配置
& & 4--Slave调整参数
为了保障较高的数据安全性，配置sync_binlog=1，innodb_flush_log_at_trx_commit=1等设置。而Slave可以关闭binlog，innodb_flush_log_at_trx_commit也可以设置为0来提高sql的执行效率（这两个参数很管用）
& & 5--并行复制
即有单线程的复制改成多线程复制。
从库有两个线程与复制相关：io_thread 负责从主库拿binlog并写到relaylog， sql_thread 负责读relaylog并执行。
多线程的思路就是把sql_thread 变成分发线程，然后由一组worker_thread来负责执行。
几乎所有的并行复制都是这个思路，有不同的，便是sql_thread 的分发策略。
MySQL5.7的真正并行复制enhanced multi-threaded slave（MTS）很好的解决了主从同步复制的延迟问题。
2）slave同步状态中出现Slave_IO_Running: NO&
报错：Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
原因1：清理数据导致主从库不同步（前提是主库的binlog日志没有被暴力删除或错误删除，即要确保正在使用的那个最新binlog文件在master主库机器上存在）。
解决办法：
1）先进入slave中执行:&&来停止从库同步；
2）再去master中执行:&&来清空日志；
3）然后在master中执行:&&查看下主库的状态，主要是日志的文件和position；
4）然后回到slave中，执行:&CHANGE MASTER TO ......执行同步指令
原因2：该错误发生在从库的io进程从主库拉取日志时，发现主库的mysql_bin.index文件中第一个文件不存在。出现此类报错可能是由于你的slave 由于某种原因停止了好长一段
时间，当你重启slave 复制的时候，在主库上找不到相应的binlog ,会报此类错误。或者是由于某些设置主库上的binlog被删除了，导致从库获取不到对应的binglog file。
解决办法：
1）为了避免数据丢失，需要重新进行slave同步操作。
2）注意主库binlog的清理策略，选择基于时间过期的删除方式还是基于空间利用率的删除方式。
3）记住最好不要使用&rm -rf&命令删除binlog file，这样不会同步修改mysql_bin.index 记录的binlog 条目。在删除binlog的时候确保主库保留了从库&show slave status&
& 的Relay_Master_Log_File对应的binlog file。任何时候都不能删除正在使用的那个最新binlog文件；最好把bin-log文件不要删除，最好给备份出来。
原因2的情况下，使用原因1的处理方案显然是解决不了的！此时的解决方案是：
在从库上执行：
mysql& reset
【】【】【】
【】【】【】
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_92
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_04
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_88
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_28
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_31
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_32
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_91
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_93
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_09
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_55
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_9
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_9
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_9
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_9
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_3
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_3
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_3
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_3
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_3
<div style="font-size:13text-align:height:14padding:0font-weight:"
id="DiggNum_3