Mysql主从（主从不同步解决办法，常见问题及解决办法，在线对mysql做主从复制）

一、主从不同步解决办法

先上Master库： 
mysql>show processlist; 查看下进程是否Sleep太多。发现很正常。 
show master status; 也正常。 
mysql> show master status; 
+-------------------+----------+--------------+-------------------------------+ 
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | 
+-------------------+----------+--------------+-------------------------------+ 
| mysqld-bin.000001 | 3260 | | mysql,test,information_schema | 
+-------------------+----------+--------------+-------------------------------+ 
1 row in set (0.00 sec) 
再到Slave上查看 
mysql> show slave status\G 
Slave_IO_Running: Yes 
Slave_SQL_Running: No 
可见是Slave不同步

下面介绍两种解决方法： 
方法一：忽略错误后，继续同步 
该方法适用于主从库数据相差不大，或者要求数据可以不完全统一的情况，数据要求不严格的情况 
解决： 
stop slave; 
#表示跳过一步错误，后面的数字可变 
set global sql_slave_skip_counter =1; 
start slave; 
之后再用mysql> show slave status\G 查看： 
Slave_IO_Running: Yes 
Slave_SQL_Running: Yes 
ok，现在主从同步状态正常了。。。

方式二：重新做主从，完全同步 
该方法适用于主从库数据相差较大，或者要求数据完全统一的情况 
解决步骤如下： 
1.先进入主库，进行锁表，防止数据写入 
使用命令： 
mysql> flush tables with read lock; 
注意：该处是锁定为只读状态，语句不区分大小写 
2.进行数据备份 
#把数据备份到mysql.bak.sql文件 
[[email protected] mysql]#mysqldump -uroot -p -hlocalhost > mysql.bak.sql 
这里注意一点：数据库备份一定要定期进行，可以用shell脚本或者python脚本，都比较方便，确保数据万无一失 
3.查看master 状态 
mysql> show master status; 
+-------------------+----------+--------------+-------------------------------+ 
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | 
+-------------------+----------+--------------+-------------------------------+ 
| mysqld-bin.000001 | 3260 | | mysql,test,information_schema | 
+-------------------+----------+--------------+-------------------------------+ 
1 row in set (0.00 sec) 
4.把mysql备份文件传到从库机器，进行数据恢复 
#使用scp命令 
[[email protected] mysql]# scp mysql.bak.sql [email protected]:/tmp/ 
5.停止从库的状态 
mysql> stop slave; 
6.然后到从库执行mysql命令，导入数据备份 
mysql> source /tmp/mysql.bak.sql 
7.设置从库同步，注意该处的同步点，就是主库show master status信息里的| File| Position两项 
change master to master_host = '192.168.128.100', master_user = 'rsync', master_port=3306, master_password='', master_log_file = 'mysqld-bin.000001', master_log_pos=3260; 
8.重新开启从同步 
mysql> stop slave; 
9.查看同步状态 
mysql> show slave status\G 查看： 
Slave_IO_Running: Yes 
Slave_SQL_Running: Yes

二、错误及解决办法

问题: 从数据库无法同步

Slave_SQL_Running 值为 NO，或 Seconds_Bebind_Master 值为 Null

原因:

1. 程序有可能在 slave 上进行了写操作

2. 也有可能是 slave 机器重启后，事务回滚造成的

解决方法一:

msyql> stop slave;

msyql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;

msyql> start slave;

解决方法二:

msyql> stop slave;

#查看主服务器上当前的 bin-log 日志名和偏移量

msyql> show master status;

#获取到如下内容:

+------------------+----------+--------------+------------------+

| File            | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+------------------+----------+--------------+------------------+

| mysql-bin.000005 |      286 |              |                  |

+------------------+----------+--------------+------------------+

#然后到从服务器上执行手动同步

msyql> change master to

->master_host="192.168.10.1",

->master_user="user",

->master_password="123456",

->master_post=3306,

->master_log_file="mysql-bin.000005",

->master_log_pos=286;

msyql> start slave;

  • 场景1：主库上用系统命令复制或删除表数据文件

    【模拟异常】：

    主库上直接copy表数据文件，或直接rm表数据文件主库上拷贝test表数据文件后，执行insert into test values('111');或主库上执行rm -f test05.*后，执行create table test05(a int(11));

【错误日志】：

从库日志：SHOW SLAVE STATUS \G;

Last_Errno: 1146

Last_Error:Error 'Table'testdb.test 'doesn't exist'on query' insertinto test values('111') '.

Default database: 'testdb'. Query: 'insert into testvalues('111')'

或者如下：

Last_Error: Error 'Table’test05 'already exists' on query.

【错误原因】：

表的创建或删除不是通过执行sql，未写入binlog，从库上没有相关表；

【解决方案】：

在从库上手动创建此表（建表语句可参考主库）；

以后，主库上对表的操作请通过sql完成，避免使用系统命令拷贝或删除

  • 场景2：数据不一致：包括删除失败、主键重复、更新丢失

【问题1】：

主键重复：在slave已经有该记录，又在master上插入了同一条记录。

从库日志：SHOW SLAVE STATUS \G;

Last_Errno: 1062

Last_Error: Error 'Duplicate entry 'xxxn-66-77' for key1' on query. Default database: 'guild'. Query: 'insert into pynpcrecord setMapCode = 'xxxn', UpdateTime = '2015-08-07 00:00:32''

【解决方案】：

方案1：在从库上将重复的主键记录删除，再次重启主从；

deletefrom xxxx where 主键=yyyy;

stopslave;start slave;

方案2：停掉主从同步，忽略一次错误，再开启同步：

stop slave;

set global sql_slave_skip_counter=1;startslave;

若是新配主从，忽略3次还报此错，还可以在my.cnf里加

一 行： slave-skip-errors=1062

然后重启实例，再重启主从同步；

stop slave; start slave;

【问题2】删除失败：在master上删除一条记录，而slave上找不到。

从库日志：SHOW SLAVE STATUS \G;

Last_Errno: 1032;

Last_Error: Could not execute Delete_rows event ontable hcy.t1;

Can't find record in 't1',

【解决方案】：

由于master要删除一条记录，而slave上找不到而报错，这种情况主库都将其删除了，从库可以直接跳过。

可用命令：

stop slave;

set global sql_slave_skip_counter=1;startslave;

【问题3】：更新丢失：在master上更新一条记录，而slave上找不到，丢    失了数据。

从库日志：SHOW SLAVE STATUS \G;

Last_Errno: 1032;

Last_Error: Could not execute Update_rows event ontable hcy.t1; Can't find record in 't1',

【解决方案】：

把丢失的数据在slave上填补，然后跳过报错即可。

  • 场景3：字段不一致：包括字段丢失、不够长等

【问题1】

从库日志：SHOW SLAVE STATUS \G;

Slave_IO_Running: Yes

Slave_SQL_Running: No

Last_Errno: 1264

Last_Error: Error 'Out of range value for column 'JFNow' at row 1' onquery. Default database: 'guild'. Query: 'update pyPHBWS set JFNow =JFNow -1 wherePlayerName = '狂魔''

虽然从库该字段和主库的一致，但从库还是报错：

guild> desc pyPHBWS;

+------------+---------------------+------+-----+---------+-------+

| Field      |Type                | Null | Key |Default | Extra |

+------------+---------------------+------+-----+---------+-------+

| PlayerName | varchar(30)         | NO  | PRI | NULL    |       |

| JFNow   | int(10)unsigned    | YES  |     |NULL    |       |

| JFAll   |int(10) unsigned    | NO   |    | NULL    |       |

【解决方案】

修改字段：

ALTER TABLE guild.pyPHBWS MODIFY JFNowbigint(20) unsigned;

重启主从：stop slave;start slave;

【问题2】

从库日志：

SHOW SLAVE STATUS \G;

Slave_IO_Running: Yes

Slave_SQL_Running: No

Last_Errno: 1054

Last_Error:Error 'Unknown column 'qdir' in 'field list''on query. Default database: 'club'. Query: 'insert into club.question_del (id,pid, ques_name, title, intime, order_d, endtime,qdir) select id, pid,ques_name, title, intime, order_d, endtime ,qdir from club.question whereid=7330212'

【解决方案】

主库：查询 desc club.question_del，发现club.question_del表里面没有qdir这个字段；

从库：执行 alter table question_del add qdirvarchar(30) not null;

  • 场景4：超出MyISAM数据表大小限制

【错误日志】

从库日志：

SHOW SLAVE STATUS \G;

Slave_IO_Running: No

Slave_SQL_Running: Yes

Last_Errno : 1114

Last_Error : Error 'The table   'tbleventlog' is full' onquery. Default database: 'dblog'. Query: 'insert into `tbleventlog`(`PlayerName`, `ACTION`, `VALUE`, `PARAM`, `TIME`) values ('??', '?', '620',':2,:397842703', '2015-07-28 06:56:04')'

找到该实例所在的目录，发现该表大小超过4GB；

【解决方案】

对于MyISAM数据表,单个.MYD和.MYI默认4GB。

利用AVG_ROW_LENGTH和MAX_ROWS建表选项可以把这个最大值扩大到800万TB.

max_rows主要对myisam生效.

从库：调整max_rows并重启slave.

use dblog; ALTER TABLE tbleventlog MAX_ROWS=1000000000;

stop slave; start slave;

  • 场景5：slave的中继日志relay-bin损坏

【模拟异常】

SLAVE在宕机，或者非法关机，例如电源故障、主板烧了等，造成中继日志损坏，同步停掉。

【错误日志】

从库日志：SHOW SLAVE STATUS \G;

Slave_IO_Running: Yes

Slave_SQL_Running: No

Last_Errno: 1593

Last_Error: Error initializing relay log position: I/Oerror reading event at position 4

【解决方案】

在主库上找到同步的binlog和POS点，然后重新做同步，这样就可以有新的中继日志了。

mysql> CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000010',MASTER_LOG_POS=821;

  • 场景6：binlog index记录不一致

【模拟异常】

主数据库突然停止或问题终止，更改了mysql-bin.xxx日志，slave服务器找不到这个文件。

【错误日志】

从库日志：SHOW SLAVE STATUS \G;

Master_Log_File: mysql-bin.000029

Last_Errno: 1594

Last_Error: Relay log read failure: Could not parserelay log event entry.

【解决方案】

找到同步的点和日志文件，然后chage master即可：

change master to master_log_file='mysql-bin.000025',master_log_pos=1010663436;

  • 场景7：时区不一致导致主从数据不一致

【模拟异常】：主从服务器设置不同的时区

主库：show variables like '%timezone%';      #.看到变量timezone值为EDT

从库：showvariables like '%timezone%';       #.看到变量timezone值为 CST

【错误日志】：主库执行insert into tbname(dtime)values(now());

主库：  select* from tbname;  #.看到字段dtime值为 2013-05-08 18:40:18

从库：  select* from tbname;  #.看到字段dtime值为 2013-05-09 06:40:18

【解决方案】：

设置主从为相同时区，并尽量使用相同时间服务器

如果对时间字段用now()写入，在删除时候用delete * from tbname where dtime='xxx',由于主从时间是不一致的，就会造成删除的非同一条记录，也会引起主键冲突问题。

  • 场景8：字段集不一致

【模拟异常】

1.主库：版本MySQL 4.0.18，字符集gb2312，主键字段PlayerName

show create table pybcsltscore;

PRIMARY KEY (`PlayerName`)  ENGINE=MyISAM DEFAULT CHARSET=gb2312

2.从库：版本MySQL 4.1.22，字符集latin1，主键字段PlayerName

show create table pybcsltscore;

PRIMARY KEY (`PlayerName`)  ENGINE=MyISAM DEFAULT CHARSET=latin1

3.主库：执行sql:

mysql> insert into pybcsltscore set PlayerName = '怒☆斩', PT = 'pchg.c8';

mysql> insert into pybcsltscore set PlayerName = '怒★斩', PT = 'pchg.c8';

4. 主库：查询正常

select * from pybcsltscore where playername='怒☆斩' or playername='怒★斩';

【错误日志】

从库：查询异常，查询实心星号，结果却出现空心星号

select * from pybcsltscore_bak where playername='怒★斩';

从库: 从库状态:

Last_Errno: 1062

Last_Error: Error 'Duplicate entry '怒★斩' for key 1' on query. Defaultdatabase: 'test0505'. Query: 'insert into pybcsltscore set PlayerName = '怒★斩', PT = 'pchg.cs68'‘

从库：插入playname=’怒★斩’ 的记录，会提示主键冲突

insert into score_bak set PlayerName = '怒★斩', PT = 'pchg.cs68';

ERROR 1062 (23000): Duplicate entry '怒★斩' for key 1

【解决方案】

方案1. 从库：去掉主键

alter table pybcsltscore_test0513 drop primary key;

stop slave sql_thread; start slave sql_thread;

方案2. 从库：修改默认编码为gb2312

mysql --default-character-set=gb2312 -S mysql3307.sock

从库：再次查询：

select * from pybcsltscore where playername='怒☆斩' or playername='怒★斩';

  • 场景9：max_allowed_packet太小

【模拟异常】

1. 主库：设置max_allowed_packet为特小值，比如12K：

mysql> set global max_allowed_packet=12*1024;

Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'max_allowed_packet';

+--------------------+-------+

| Variable_name      | Value |

+--------------------+-------+

| max_allowed_packet | 12288 |

+--------------------+-------+

2. 重启slave io thread

#说明：slave如果不重启的话，个人觉得主从关系所使用的主库的变

不会改变，重启以便重新加载一些变量

3. 主库：导入r2.txt（仅一行记录

# du -sh r2.txt    80K    r2.txt）

./bin/mysql test0505 -e "load data infile'/tmp/r2.txt' into table test2;"

4. 查看从库状态

Slave_IO_Running: No

Slave_SQL_Running: Yes

5. 从库：

mysql> show variables like 'max_allowed_packet';

+--------------------+----------+

| Variable_name      | Value    |

+--------------------+----------+

| max_allowed_packet | 16776192|

+--------------------+----------+

【错误日志】

查看从数据库的错误日志，找到如下信息:

[ERROR] Got fatal error 1236: 'log event entry exceededmax_allowed_packet;

Increase max_allowed_packet on master' from master whenreading data from binary log

或类似：

[ERROR] Error reading packet from server: Got packetbigger than          'max_allowed_packet' bytes (server_errno=2020)

应该是master上的dump线程在从binlog读取数据时，读取的结果集超出了max_allowed_packet限制，造成往slave发送失败。

【解决方案】

修改max_allowed_packet的大小，然后重启slave。建议主从一致

mysql> set global max_allowed_packet=16*1024*1024;

重启slave, stop salve;start slave;

  • 场景10：临时表太大导致磁盘写满

【错误日志】：从库日志

Last_Errno: 3

Last_Error: Error 'Error writing file '/tmp/FeqMc' (Errcode: 28)'on query.

Default database: 'evt'. Query: 'delete from goodslogwhere OpTime<'2015-07-01''

【错误原因】

1. tmp目录不可写，或磁盘没有空间；

2. tmp还有空间，但是原表太大，所以查询时生成的临时表过大，因此出   错。

【解决方案】

1. 确认/tmp可写入，同时磁盘未写满；

2. 修改socket目录到空间较大的分区，再重启实例；

把 socket = /tmp/mysql.sock 改为 socket = /app/mysql.sock

二、在线对MySQL做主从复制：

http://seanlook.com/2015/12/14/mysql-replicas/

原文地址：http://blog.51cto.com/13407306/2067333

时间： 2024-10-04 04:19:32

Mysql主从（主从不同步解决办法，常见问题及解决办法，在线对mysql做主从复制）的相关文章

MySQL数据库ab不同步几种情况及解决过程

如果AB不同步 1)查看辅助的sql日志    tailf /var/log/mysqld.log 140304 11:59:18 [Note] Slave I/O thread: connected to master '[email protected]:3306',  replication started in log 'binlog.000011' at position 294 #从服务器是否可以顺利到达主服务器 如果发现你的用户名密码有错误  /etc/my.cnf   /var/

MariaDB、MySQL数据库主从同步

1.Mysql主从同步异步概念 异步:主服务器写完日志后立即返回同步完成消息,不受从服务器的状态和影响,mysql默认为异步工作模式 同步:主服务器写入数据到本地磁盘并记录好二进制日志,然后等从服务器发现数据发送改变再把数据同步到从服务器的日志中继并保存到二进制日志和磁盘,最后返回给主服务器同步完成的结果,因此比较影响性能. 2.同步过程: 主 服务器在可能修改数据时会把行内容记录在二进制日志中,而从服务会不停到主服务器请求数据,相当于mysql客户端,不停请求服务器的3306端口,从服 务器请

MySQL主从同步延迟的原因及解决办法

由于历史原因,MySQL复制基于逻辑的二进制日志,而非重做日志.多次被问到何时MySQL能支持基于物理的复制,其实这就看MySQL各位大佬的想法.上次和赖老师脑暴,倏地说道:MySQL会不会来个基于Paxos的redo复制? 物理复制的真正好处不在于正确性,因为基于ROW格式的日志复制也已能完全保证复制的正确性.由于物理日志的写入是在事务执行过程中就不断写入,而二进制日志的写入仅仅在事务提交时.因此物理日志的优势如下所示: 复制架构下,大事务日志提交速度快: 复制架构下,主从数据延迟小: 假设执

mysql数据库主从不同步解决办法

参考:http://blog.51cto.com/13407306/2067333 重新做主从,完全同步?(该方法适用于主从库数据相差较大,或者要求数据完全统一的情况?) 1.先进入主库,进行锁表,防止数据写入 (完事后记得解锁 unlock tables )使用命令:?mysql -uroot -proot_neu -P33061 -S /tmp/mysql_33061.sockmysql> flush tables with read lock;? 注意:该处是锁定为只读状态,语句不区分大小

MYSQL主从同步故障一例及解决过程

公司里有两个mysql服务器做主从同步,某天Nagios发来报警短信,mysqla is down...赶紧联系机房,机房的人反馈来的信息是 HARDWARE ERROR 后面信息省略,让机房记下错误信息后让他们帮忙重启下看是不是能正常起来,结果竟然正常起来了,赶紧导出所有数据.   问题又出现了,nagios 又报警,mysql_AB error,检查从库show slave status \G; 果然 Slave_IO_Running: YesSlave_SQL_Running: No而且出

mysql主从数据库不同步的2种解决方法（转）

今天发现Mysql的主从数据库没有同步 先上Master库: mysql>show processlist; 查看下进程是否Sleep太多.发现很正常. show master status; 也正常. mysql> show master status; +-------------------+----------+--------------+-------------------------------+ | File | Position | Binlog_Do_DB | Binlo

解决mysql 数据库主从不同步

今天发现Mysql的主从数据库没有同步 先上Master库: mysql>show processlist;   查看下进程是否Sleep太多.发现很正常. show master status; 也正常. mysql> show master status; +-------------------+----------+--------------+-------------------------------+ | File              | Position | Binlo

mysql数据库主从不同步的解决方法

故障描述: 进入从数据库 mysql> show slave status\G; 结果如下: ... Slave_IO_Running: Yes Slave_SQL_Running: No Last_Errno: 1062 ... 原因: 程序可能在slave上进行了写操作 可能是slave机器重启后,事物回滚造成的 多数是第二种造成的 解决方法一:忽略错误后继续同步 该方法适用于主从库数据相差不大,或者要求数据可以不完全统一的情况,数据要求不严格的情况 mysql> slave stop;m

mysql主从数据库不同步的3种解决方法

mysql主从数据库不同步的3种解决方法 今天发现Mysql的主从数据库没有同步 先上Master库: mysql>show processlist; 查看下进程是否Sleep太多.发现很正常. show master status; 也正常. mysql> show master status; +-------------------+----------+--------------+-------------------------------+ | File | Position |