Mysql8.0 version slave database data out of sync problem handling
Case 1: Error during synchronization
During the synchronization process of the slave library, the master library has operations to delete data.
1. The slave library does not synchronize the data of the main library
Cause analysis: It is caused by data synchronization error.
Operation from library
show slave status\G
查看Slave_IO_Running、Slave_SQL_Running
If both are NO, or if one is NO, there will be asynchronous situation.
Last_SQL_Error Use this field to check the error problem and handle it
Second, the solution (repair)
Handle the wrong sql in one
implement
start slave sql_thread;
show slave status\G
Slave_IO_Running、Slave_SQL_Running变YES;
Seconds_Behind_Master为从落后主的时间，为0的时候就说明已经追赶上了。
Three, the solution (global)
Clear all data (slave), resync
1、从库操作
-- 停止slave
stop slave
-- 重置slave
reset slave all
--删除同步的数据
drop database db*
2、主库操作
-- 查看状态
show master status
查看position的数值，如果多次查询有变化，就说明对数据有操作。
-- 重置master
reset master
-- 锁表只读
flush tables with read lock
此时进行备份，还原从库
3、从库操作
-- 重新建立关系 子厚两个参数查看master状态即可 和主库保持一致
change master to master_host = '192.168.22.22', master_user = 'user', master_port=3306, master_password='pwd', master_log_file = 'mysqld-bin.000001', master_log_pos=1234;
-- 启动slave
start slave
4、主库解锁
unlock tables
5、查看从库状态
-- 查看slave状态
show slave status
查看Slave_IO_Running、Slave_SQL_Running的值，都为YES就说明没问题，主库写入数据测试即可。
Case two:
view from library
mysql> show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
master没问题，Slave不同步
Here are two workarounds:
Method 1: After ignoring the error, continue to synchronize
This method is suitable for the situation where the master-slave database data is not much different, or the data is not required to be completely unified, and the data requirements are not strict. Solution
:
mysql> stop slave;
# 表示跳过一步错误，后面的数字可变
mysql> set global sql_slave_skip_counter =1;
mysql> start slave;
# 之后再用
mysql> show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
ok, now the master-slave synchronization status is normal. . .
Method 2: Specify to skip the error code and continue to synchronize
Error codes such as primary key conflicts and tables already exist, such as 1062, 1032, 1060, etc., can be specified in the mysql master configuration file to skip such exceptions and continue to the next sql synchronization, which can also avoid many abnormal interruptions of master-slave synchronization
[mysqld]
slave-skip-errors = 1062,1032,1060
重新启动mysql
service mysqld restart
# 或者
/etc/init.d/mysqld
# 启动命令根据实际情况
之后再用mysql> show slave status\G 查看：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Specific error handling
Solution to 'Could not find first log file name in binary log index file'
数据库主从出错：
Slave_IO_Running: No 一方面原因是因为网络通信的问题也有可能是日志读取错误的问题。以下是日志出错问题的解决方案：
Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
解决办法：
从机器停止slave
mysql> slave stop;
到master机器登陆mysql：
记录master的bin的位置，例如：mysql> show mster status;
+-------------------+----------+--------------+-------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+-------------------------------------------+
| mysqld-bin.000010 | 106 | | information_schema,mysql |
+-------------------+----------+--------------+-------------------------------------------+
日志为mysqld-bin.000010
刷新日志：mysql> flush logs;
因为刷新日志file的位置会+1，即File变成为:mysqld-bin.000011
马上到slave执行
mysql> CHANGE MASTER TO MASTER_LOG_FILE='mysqld-bin.000011',MASTER_LOG_POS=106;
mysql> slave start;
mysql> show slave status\G;
==================================================================================
Mysql master-slave synchronization show slave status\G
Let's talk about the specific meaning of the parameters displayed by the show slave status command.
*1) Display format based on binary log replication*
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Queueing master event to the relay log
Master_Host: 172.18.16.22
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.010362
Read_Master_Log_Pos: 555176471
Relay_Log_File: mysqld-relay-bin.004136
Relay_Log_Pos: 502564
Relay_Master_Log_File: mysql-bin.010327
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: blog
Replicate_Ignore_DB:
Replicate_Do_Table: blog.archives
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 555176471
Relay_Log_Space: 3642164873
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: 1042
Master_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: 1622
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:
Explanation of the specific meaning of the parameters:
Slave_IO_State
这个是指Slave连接到Master的状态，就是当前IO线程的状态，MySQL主从复制线程状态转变。
Master_User
这个是Master上面的一个用户，用来负责主从复制的用户 ，创建主从复制的时候建立的（具有reolication slave权限）。
Master_Port
Master服务器的端口，一般是3306。
Connect_Retry
连接尝试次数，使用change master时可以使用master-connect-retry选项指定当前值。
Master_Log_File
显示当前I/O线程当前正在读取的主服务器二进制日志文件的名称，上面显示是mysql-bin.010362。
Read_Master_Log_Pos
显示当前同步到主服务器上二进制日志的偏移量，I/O线程已经读取的位置，单位是字节，上述的示例显示当前同步到mysql-bin.010362的555176471偏移量位置，即已经同步了mysql-bin.010362这个二进制日志中529MB（555176471/1024/1024）的内容。
Relay_Log_File
显示Slave的SQL线程当前正在读取和执行的中继日志文件的名称。
Relay_Log_Pos
显示在当前的中继日志中，Slave的SQL线程已读取和执行的中继日志的偏移量。
Relay_Master_Log_File
显示Slave中继日志同步到Master的二进制日志文件，本示例中为mysql-bin.010327。
Slave_IO_Running
显示I/O线程是否被启动并成功地连接到主服务器上，成功为Yes，否则为No。
Slave_SQL_Running
显示SQL线程是否被启动，启动为Yes，否则为No。
Replicate_Do_DB
Replicate_Ignore_DB
Replicate_Do_Table
Replicate_Ignore_Table
Replicate_Wild_Do_Table
Replicate_Wild_Ignore_Table
这些参数都是为了用来指明哪些库或者表在复制的时候不要同步到备库，但是这些参数用的时候要小心，因为当跨库使用的时候可能会出现问题。另外当仅忽略或仅允许多个库或表时，要多次使用忽略语句才可以。
Last_Errno,Last_Error
显示Slave的SQL线程读取日志参数的的错误数量和错误消息，错误数量为0并且消息为空字符串表示没有错误；如果Last_Error值不是空值，它也会在从属服务器的错误日志中作为消息显示。
Skip_Counter
显示最近被使用的用于SQL_SLAVE_SKIP_COUNTER的值，就是用于跳过Slave错误的。
Exec_Master_Log_Pos
表示SQL线程已经执行的Relay log相对于主库二进制日志偏移量的位置。
Relay_Log_Space
表示所有原有的中继日志结合起来的总大小，在START SLAVE语句的UNTIL子句中指定的值，Until_Condition具有以下值：Until_Condition、Until_Log_File、Until_Log_Pos。
Until_Condition
如果没有指定UNTIL子句，则没有值。如果从属服务器正在读取，直到达到主服务器的二进制日志的给定位置为止，则值为Master，如果从属服务器正在读取，直到达到其中继日志的给定位置为止，则值为Relay。
Until_Log_File
Until_Log_Pos
Until_Log_File和Until_Log_Pos用于指示日志文件名和位置值，日志文件名和位置值定义了SQL线程在哪个点中止执行。
Master_SSL_Allowed
显示了从服务器是否使用SSL连接到主服务器。如果允许对主服务器进行SSL连接，则值为Yes；如果不允许对主服务器进行SSL连接，则值为No；如果允许SSL连接，但是从服务器没有让SSL支持被启用，则值为Ignored。
Master_SSL_CA_File
Master_SSL_CA_Path
Master_SSL_Cert
Master_SSL_Cipher
Master_SSL_Key
如果Slave使用SSL连接Master服务器，这里就会显示对应的证书和私钥信息。使用CHANGE MASTER与SSL相关的选项有：–master-ca,–master-capath,–master-cert,–master-cipher和–master-key等。
Seconds_Behind_Master
表示主从之间延迟的时间，单位是秒。就是SQL线程当前执行的binlog（实际上是relay log）中的timestamp和IO线程最新的timestamp的差值。
实质上，此字段计算Slave SQL线程和Slave i/o线程之间的时间差 (以秒为单位)。如果主节点和从服务器之间的网络连接速度较快，则Slave i/o线程非常接近主服务器，因此此字段是对从SQL线程与主服务器进行比较的后的一个很好的近似值。如果网络很慢，这不是一个好的近似；从SQL线程可能经常被从i/o线程所捕获，因此Seconds_Behind_Master通常显示值为0，即使i/o线程比主服务器慢很多。换言之，此列仅适用于快速网络。
Master_SSL_Verify_Server_Cert
显示是否认证Master证书。
Master_Server_Id
显示主服务器的Server_id。
Using_Gtid
表示是否开启了基于Gtid的复制，开启为Yes，否则为No。
Gtid_IO_Pos
如果开启了基于Gtid的复制，这里会显示当前执行到的事物ID。
*2) Display format copied based on GTIDs*
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.30.65
Master_User: mysql_slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 790
Relay_Log_File: relay-log.000008
Relay_Log_Pos: 1003
Relay_Master_Log_File: mysql-bin.000003
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: 790
Relay_Log_Space: 2591
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: 0
Master_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: 1
Master_UUID: 5f0b7791-a499-11e6-901c-44a84227448b
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 5f0b7791-a499-11e6-901c-44a84227448b:2-11
Executed_Gtid_Set: 3ec6f284-a4a8-11e6-a3fe-44a84220797c:1-4,5f0b7791-a499-11e6-901c-44a84227448b:1-11
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
Master_UUID
记录Master的UUID。
Master_Info_File
记录Master info信息的存储位置。
SQL_Delay
记录Slave设置延迟复制的时间，0表示无延迟。
SQL_Remaining_Delay
Slave_SQL_Running_State
记录SQL线程的状态。
Last_IO_Error_Timestamp
记录最近IO线程错误的时间戳。
Last_SQL_Error_Timestamp
记录最近SQL线程错误的时间戳。
Retrieved_Gtid_Set
接收的二进制日志集合，对应IO线程。
execute_Gtid_Set
执行的二进制日志集合，对应SQL线程。
Auto_Position
记录在GTID模式下是否开启了自动事务校验。
Channel_Name
在多源复制下（5.7支持），复制通道的名称，可以有多个。