1.问题原因
今天突然发现从库的数据和主库的数据对不上了从库少了好多数据，赶紧排查了一下从库发现从库断了，将修复的操作记录一下。
2.查看从服务器状态
mysql> show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
Slave_IO_Running：连接到主库，并读取主库的日志到本地，生成本地日志文件
Slave_SQL_Running:读取本地日志文件，并执行日志里的SQL命令。
3.解决办法一
#停止从服务
mysql> slave stop; #有些版本执行这个命令可能会报错，无法识别，使用stop slave;即可
#表示跳过一步错误，后面的数字可变
mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
#重启slave服务
mysql> slave start;
之后再用mysql> show slave status\G 查看：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
ok，现在主从同步状态正常了。。。
4.解决办法二 (重新做主从，完全同步)
该方法适用于主从库数据相差较大，或者要求数据完全统一的情况
解决步骤如下：
1.先进入主库，进行锁表，防止数据写入
使用命令：
mysql> flush tables with read lock;
注意：该处是锁定为只读状态，语句不区分大小写
2.进行数据备份
#把数据备份到mysql.bak.sql文件
[root@server01 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命令
[root@server mysql]# scp mysql.bak.sql root@192.168.124.100:/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> start slave;
9.查看同步状态
mysql> show slave status\G 查看：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
10.解锁主表
mysql> UNLOCK TABLES;
5.show slave status\G 详解
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event --IO thread的状态
Master_Host: 10.10.10.10 -- 主库的地址
Master_User: repl -- 用于连接主库复制账号（这个账号是在主库上创建）
Master_Port: 3300 -- 主库的端口
Connect_Retry: 10 -- 连接重试之间的秒数（默认 60）
Master_Log_File: mysql-bin.005395 -- I/O 线程当前正在读取的主库的二进制日志文件名称。
Read_Master_Log_Pos: 684976832 -- I/O 线程已读取的当前主库二进制日志文件中的位点
Relay_Log_File: dd-relay.000063 -- SQL线程正在读取和执行的中继日志名称
Relay_Log_Pos: 684953253 -- SQL线程正在读取和执行的当前中继日志的位点
Relay_Master_Log_File: mysql-bin.005395 -- SQL 线程执行的最新事件 对应在主库上的二进制日志文件名称。
Slave_IO_Running: Yes -- IO线程是否已启动并已成功连接到主库
Slave_SQL_Running: Yes -- SQL线程是否启动。
Replicate_Do_DB: -- 需要复制的DB
Replicate_Ignore_DB: -- 复制忽略的DB
Replicate_Do_Table: -- 需要复制的表
Replicate_Ignore_Table: -- 复制忽略的表
Replicate_Wild_Do_Table: -- 用于指定需要复制的数据库表，支持通配符（wildcard）的形式
Replicate_Wild_Ignore_Table: -- 用于指定需要忽略（不复制）的数据库表，同样支持通配符的形式。
Last_Errno: 0 -- Last_SQL_Errno的别名
Last_Error: -- Last_SQL_Error的别名
Skip_Counter: 0 -- 系统变sql_slave_skip_counter 的当前值 （从库跳过的SQL数量）
Exec_Master_Log_Pos: 684953080 -- SQL线程已经读取和执行过的中继日志 对应在主库二进制日志文件的位点
Relay_Log_Space: 684977292 -- 所有现有中继日志文件的总大小。
Until_Condition: None -- start slave 中制定 until 语句
Until_Log_File: -- start slave 中制定 until 语句
Until_Log_Pos: 0 -- start slave 中制定 until 语句
Master_SSL_Allowed: No -- 是否允许与源的 SSL 连接
Master_SSL_CA_File: -- 指定用于验证主服务器证书的证书颁发机构（CA）文件的路径
Master_SSL_CA_Path: -- 指定用于验证主服务器证书的证书颁发机构（CA）路径的路径
Master_SSL_Cert: -- 指定从服务器的 SSL 证书文件的路径
Master_SSL_Cipher: -- 指定在 SSL 通信中使用的密码套件
Master_SSL_Key: -- 指定从服务器的 SSL 私钥文件的路径
Seconds_Behind_Master: 0 -- 主从延迟
Master_SSL_Verify_Server_Cert: No -- 表示是否验证主服务器的 SSL 证书。
Last_IO_Errno: 0 -- 导致IO线程停止的最近一次的错误码，Errno :0 表示表示没有错误
Last_IO_Error: -- 导致IO线程停止的最近的错误信息 。Erro为空表示没有错误
Last_SQL_Errno: 0 -- 导致SQL线程停止的最近的错误码。Errno :0 表示没有错误
Last_SQL_Error: -- 导致SQL线程停止的错误信息,Erro为空表示没有错误
Replicate_Ignore_Server_Ids: -- 忽略复制的主库的server_id
Master_Server_Id: 181323300 -- 主库的参数server_id的值
Master_UUID: 127ef593-1826-11eb-8a97-6c92bf7d39de -- 主库参数server_uuid的值
Master_Info_File: mysql.slave_master_info -- 在从库上存储主库信息的文件或表
SQL_Delay: 0 -- 从库延迟主库多少秒
SQL_Remaining_Delay: NULL -- 当Slave_SQL_Running_State为 时 Waiting until MASTER_DELAY seconds after master executed event，该字段包含剩余延迟秒数。其他时候，该字段为 NULL。
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates -- SQL线程的运行状态
Master_Retry_Count: 86400 -- 在连接丢失的情况下，从库可以尝试重新连接到主库的次数。
Master_Bind: --
Last_IO_Error_Timestamp: -- 最近的I/O 线程发生错误的时间 格式YYMMDD hh:mm:ss
Last_SQL_Error_Timestamp: -- 最近的SQL 线程发生错误的时间 格式YYMMDD hh:mm:ss
Master_SSL_Crl: -- 指定撤销列表 (CRL) 文件的路径，该文件包含已被撤销的 SSL 证书列表
Master_SSL_Crlpath: -- 指定撤销列表 (CRL) 文件的路径，该文件包含已被撤销的 SSL 证书列表
Retrieved_Gtid_Set: 127ef593-1826-11eb-8a97-6c92bf7d39de:330411-2764671 -- 从库已经接收到的GTID的集合（I/O线程），如果GTID模式没有开启则为空。这个值是现在存在或者已经存在在relay log中的GTID集合
Executed_Gtid_Set: 127ef593-1826-11eb-8a97-6c92bf7d39de:1-2764671,
3133d0b5-8d65-11e7-9f2e-c88d83a9846a:1-12697883,
657b7d6b-8d60-11e7-b85f-6c92bf4e09e6:1-1661102840 -- 已经被写进binlog的GTID的集合（SQL线程），这个值和 系统参数 gtid_executed 相同。也和在该实例上执行 show master status 中的Executed_Gtid_Set 值相同
Auto_Position: 1 -- 如果正在使用自动定位1；否则为 0。
Replicate_Rewrite_DB: -- 用于指定需要在主从复制过程中进行数据库名重写的规则。
Channel_Name: -- 正在显示的复制通道
Master_TLS_Version: -- 源上使用的 TLS 版本
3483
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
