江苏龙网

  1. 主页 > 生活百科 > >

MySQL主从不一致情形与解决方法( 二 )

MySQL主从不一致


1 row in set (0.00 sec)
复制代码
4.把mysql备份文件传到从库机器 ， 进行数据恢复
使用scp命令
[root@server01 mysql]# scp mysql.bak.sql root@192.168.1.206:/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.1.206’, master_user = ‘rsync’, master_port=3306, master_password=”, master_log_file = ‘mysqld-bin.000001’, master_log_pos=3260;
8.重新开启从同步
mysql> start slave;
9.查看同步状态
mysql> show slave statusG 查看：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
好了 ， 同步完成啦
三、如何监控mysql主从之间的延迟
3.1 前言：
日常工作中 ， 对于MYSQL主从复制的检查有两方面
保证复制的整体结构是否完整；
需要检查数据是否一致；
对于前者我们可以通过监控复制线程是否工作正常以及主从延时是否在容忍范围内 ， 对于后者则可以通过分别校验主从表中数据的md5码是否一致 ， 来保证数据一致 ， 可以使用Maatkit工具包中的mk-table-checksum工具去检查 。
本文档介绍下关于如何检查主从延迟的问题 。
主从延迟判断的方法 ， 通常有两种方法：Seconds_Behind_Master和mk-heartbeat
3.2方法1.
通过监控show slave statusG命令输出的Seconds_Behind_Master参数的值来判断 ， 是否有发生主从延时 。
mysql> show slave statusG;
1. row **
Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.205 Master_User: repl Master_Port: 3306 Connect_Retry: 30 Master_Log_File: edu-mysql-bin.000008 Read_Master_Log_Pos: 120 Relay_Log_File: edu-mysql-relay-bin.000002 Relay_Log_Pos: 287 Relay_Master_Log_File: edu-mysql-bin.000008 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB:Replicate_Ignore_DB:Replicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table:
Last_Errno: 0 Last_Error:Skip_Counter: 0 Exec_Master_Log_Pos: 120 Relay_Log_Space: 464 Until_Condition: None Until_Log_File:Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master: 0Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0 Last_IO_Error:Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids:
Master_Server_Id: 205 Master_UUID: 7402509d-fd14-11e5-bfd0-000c2963dd15 Master_Info_File: /home/mysql/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it Master_Retry_Count: 86400 Master_Bind:Last_IO_Error_Timestamp:Last_SQL_Error_Timestamp:Master_SSL_Crl:Master_SSL_Crlpath:Retrieved_Gtid_Set:Executed_Gtid_Set:Auto_Position: 01 row in set (0.00 sec)
复制代码以上是show slave statusG的输出结果 ， 这些结构给我们的监控提供了很多有意义的参数 。
Slave_IO_Running
该参数可作为io_thread的监控项 ， Yes表示io_thread的和主库连接正常并能实施复制工作 ， No则说明与主库通讯异常 ， 多数情况是由主从间网络引起的问题；
Slave_SQL_Running
该参数代表sql_thread是否正常 ， 具体就是语句是否执行通过 ， 常会遇到主键重复或是某个表不存在 。
Seconds_Behind_Master
是通过比较sql_thread执行的event的timestamp和io_thread复制好的event的timestamp(简写为ts)进行比较 ， 而得到的这么一个差值；NULL—表示io_thread或是sql_thread有任何一个发生故障 ， 也就是该线程的Running状态是No ， 而非Yes 。0 — 该值为零 ， 是我们极为渴望看到的情况 ， 表示主从复制良好 ， 可以认为lag不存在 。
正值 — 表示主从已经出现延时 ， 数字越大表示从库落后主库越多 。负值 — 几乎很少见 ， 我只是听一些资深的DBA说见过 ， 其实 ， 这是一个BUG值 ， 该参数是不支持负值的 ， 也就是不应该出现 。
备注Seconds_Behind_Master的计算方式可能带来的问题
我们都知道的relay-log和主库的bin-log里面的内容完全一样 ， 在记录sql语句的同时会被记录上当时的ts ， 所以比较参考的值来自于binlog ， 其实主从没有必要与NTP进行同步 ， 也就是说无需保证主从时钟的一致 。你也会发现 ， 其实比较真正是发生在io_thread与sql_thread之间 ， 而io_thread才真正与主库有关联 ， 于是 ， 问题就出来了 ， 


推荐阅读


上一篇：刘封要是救关羽可以救得下吗

下一篇：孙膑庞涓大战的马陵在哪里 马陵之战中孙膑用了什么计策