MySQL主从复制架构实践：主从不同步的解决方案
Posted 我是沐风晓月
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了MySQL主从复制架构实践：主从不同步的解决方案相关的知识，希望对你有一定的参考价值。
前言
大家好，我是沐风晓月，本文收录于《mysql入门到精通》专栏，希望对你有用；
之前在做MySQL主从架构的时候，遇到了形形色色的问题，比如：
- 主从配置好之后，双yes的情况下，居然不能同步；
- 切换主从之后，数据丢失了；
- 主从只更新了一条数据，从库却出来多条数据；
- 模拟从宕机，修复后，无法同步停机时间内，主服务器更新的数据；
文章目录
一. MySQL主从架构思想
1.1 什么是MySQL主从复制
主从复制是指一台服务器充当主数据库服务器，另一台或多台服务器充当从数据库服务器，主服务器中的数据自动复制到从服务器之中。对于多级复制，数据库服务器即可充当主机，也可充当从机。
主从同步的原理：
默认情况下，MySQL 采用异步复制的方式，执行事务操作的线程不会等复制 Binlog 的线程.
MySQL 主库在收到客户端提交事务的请求之后，会先写入 Binlog，然后再提交事务，更新存储引擎中的数据，事务提交完成后，给客户端返回操作成功的响应。
同时，从库会有一个专门的复制线程，从主库接收 Binlog，然后把 Binlog 写到一个中继日志里面，再给主库返回复制成功的响应。
从库还有另外一个回放 Binlog 的线程，去读中继日志，然后回放 Binlog 更新存储引擎中的数据，提交事务和复制这两个流程在不同的线程中执行，互相不会等待，这是异步复制。
需要注意的是：异步复制它没有办法保证数据能第一时间复制到从库上。
与异步复制相对的就是同步复制。同步复制和异步复制唯一的区别是，什么时候给客户端返回响应。
异步复制时，主库提交事务之后，就会给客户端返回响应；而同步复制时，主库在提交事务的时候，会等待数据复制到所有从库之后，再给客户端返回响应。
同步复制这种方式在实际项目中，基本上没法用，原因有两个：
- 一是性能很差，因为要复制到所有节点才返回响应；
- 二是可用性也很差，主库和所有从库任何一个数据库出问题，都会影响业务。
为了解决这个问题，MySQL 从 5.7 版本开始，增加一种半同步复制（Semisynchronous Replication）的方式。
异步复制是，事务线程完全不等复制响应；同步复制是，事务线程要等待所有的复制响应；半同步复制介于二者之间，事务线程不用等着所有的复制成功响应，只要一部分复制响应回来之后，就可以给客户端返回了。
1.2 MySQL主从同步的作用
- 一份数据被放在了多个数据库中，其中一个是master，其余的是slave从库。 当主库进行更新的时候，会自动将数据复制到从库中，而我们在客户端读取数据的时候，会从从库中进行读取，也就是采用读写分离的方式，分担了服务器的压力
- 数据备份。我们通过主从复制将主库上的数据复制到了从库上，相当于是一种热备份机制，也就是在主库正常运行的情况下进行的备份，不会影响到服务。
- 具有高可用性。数据备份实际上是一种冗余的机制，通过这种冗余的方式可以换取数据库的高可用性，也就是当服务器出现故障或宕机的情况下，可以切换到从服务器上，保证服务的正常运行。
1.3 MySQL主从复制的形式
- 一主一从
- 一主多从
- 双主
- 多主一从
- 级联复制
当架构中slave节点较多时，master节点就会损耗一部分性能用于replication，我们可以将少量slave节点连接到master节点，其他slave节点连接到二级节点，这样不仅可以缓解主节点的压力，并且对数据一致性没有负面影响。
1.4 MySQL主从复制模式
- STATEMENT模式（SBR）
记录每一条SQL修改：
每一条会修改数据的SQL语句会记录到binlog中。优点是并需要记录每一条SQL语句和每一行的数据变化，减少了binlog日志量，节约IO，提高性能。
缺点是在某些情况下会导致master-slave中的数据不一致（如sleep()函数，last_insert_id()，以及user-defined functions(udf)等会出现问题）。 - ROW模式（RBR）
仅记录修改的内容，不记录具体的SQL：
不记录每条SQL语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样子。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法正确复制的问题。
缺点是会产生大量的日志，尤其是altertable的时候会让日志暴涨。 - MIXED模式（MBR）
以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。
在 MySQL 中，无论是复制还是备份恢复，依赖的都是全量备份和 Binlog，全量备份相当于备份那一时刻的一个数据快照，Binlog 则记录了每次数据更新的变化，也就是操作日志。
主从同步，也是数据复制，全量快照+增量操作日志的备份恢复和数据复制，是几乎所有存储系统使用的方案。
二. 主从不同步的解决方案
在模拟主从不同步之前，要提前安装好MySQL主从同步，可以参考沐风晓月的上篇文章：提高MySQL数据可靠性的必备技能：基于MySQL8实现主从同步。
接下来我们来模拟从库宕机的情况，然后将其恢复。
- 插入数据测试
- 在master中插入数据
mysql> use aa
Database changed
mysql> show tables;
Empty set (0.00 sec)
mysql> create table student(name varchar(20),age int(11));
Query OK, 0 rows affected, 1 warning (0.01 sec)
mysql> insert into student values("mufeng",19);
Query OK, 1 row affected (0.01 sec)
mysql> select * from student;
+--------+------+
| name | age |
+--------+------+
| mufeng | 19 |
+--------+------+
1 row in set (0.00 sec)
- 在从数据库中查看
mysql> use aa
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from student;
+--------+------+
| name | age |
+--------+------+
| mufeng | 19 |
+--------+------+
1 row in set (0.00 sec)
mysql>
- slave节点关闭slave同步
在mufeng42服务器中关闭从服务器：
mysql> stop slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql>
- 在master插入数据测试是否还能够同步
- 在mufeng41 master服务器中插入数据
mysql> insert into student values("mufeng1",20);
Query OK, 1 row affected (0.00 sec)
mysql> select * from student;
+---------+------+
| name | age |
+---------+------+
| mufeng | 19 |
| mufeng1 | 20 |
+---------+------+
2 rows in set (0.00 sec)
mysql>
- 在mufeng42 从服务器中测试：
mysql> use aa
Database changed
mysql> select * from student;
+--------+------+
| name | age |
+--------+------+
| mufeng | 19 |
+--------+------+
1 row in set (0.00 sec)
mysql>
此时我们发现无法同步，如果想继续同步怎么办？
需要重新配置下同步，先设置master
- 重新配置MySQL主从同步
- master节点查看状态
这一步之前最好先重启下MySQL服务
mysql> show master status;
+---------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000003 | 157 | | | |
+---------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
- slave 节点重新设置同步
这里我们需要在mufeng42从服务器上来设置：
mysql> change master to master_host='192.168.1.41',master_user='slave21',master_password='Root!2#mufeng',master_log_file='binlog.000003',master_log_pos=157;
Query OK, 0 rows affected, 8 warnings (0.01 sec)
## 最好重启一下MySQLd服务
mysql> start slave ;
Query OK, 0 rows affected, 1 warning (0.01 sec)
mysql> show slave status \\G
发现两个都为yes，表示已经同步成功
- 在主服务器插入数据在从服务器查看
- 主服务器插入数据
mysql> use aa
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> insert into student values("mufeng3",23);
Query OK, 1 row affected (0.00 sec)
- 从服务器查看
mysql> select * from student;
+---------+------+
| name | age |
+---------+------+
| mufeng | 19 |
| mufeng2 | 21 |
| mufeng3 | 23 |
+---------+------+
3 rows in set (0.00 sec)
可以看到，主从数据库又重新同步了， 有时候主库的数据无法同步过来，可以跳过错误：
1、先停掉slave
mysql> stop slave;
2、跳过错误步数，后面步数可变
mysql> set global sql_slave_skip_counter=1;
3、再启动slave
mysql> start slave;
4、查看同步状态
mysql> show slave status\\G;
总结
本文的理论部分参考了众多网上的博客和权威文献，无法一 一列出，若侵权，可以联系我删除。
💕 好啦，这就是今天要分享给大家的全部内容了，我们下期再见！
💕 本文由沐风晓月原创，首发于CSDN博客， 博客主页：mufeng.blog.csdn.net
💕 每一次学习都很枯燥，单调，孤独，甚至看不到未来，每一次遇到问题都让人疑惑，焦虑，怀疑，甚至想要放弃。 但坚定的走下来，会收获很多。收获的不单单是技术的成长还有一颗强大的心。
💕 喜欢的话记得点赞收藏哦
MySQL主从复制原理及实践
第1章 MySQL的主从复制介绍
MySQL的主从复制方案，和上述文件及文件系统级别同步是类似的，都是数据的传输。只不过MySQL无需借助第三方工具，而是其自带的同步复制功能。另外一点，MySQL的主从复制并不是磁盘上文件直接同步，而是逻辑的binlog日志同步到本地再应用执行的过程。
复制可以单向：M=>S，也可以是双向M<==>M，也可以是多M换装同步等。如果设置了链式级联复制，那么，从（slave）服务器本身除了充当从服务器外，也会同时充当其下面从服务器的主服务器。链式级联复制类似A-->B-->C-->D的复制形式。
主从复制条件：
1、开启binlog功能
2、主库建立同步账号
3、从库配置master.info（change master）
4、start slave 复制开关
1.1 主从复制原理介绍
MySQL的主从复制是一个异步的复制过程（虽然一般情况下感觉是实时的），数据将从一个MySQL数据库（Master）复制到另外一个MySQL数据库（Slave），两个数据库之间实现整个主从复制的过程是由三个线程参与完成的。其中两个线程（SQL和I/O）在Slave端，另外一个线程（I/O）在Master端。
要实现MySQL的主从复制，首先必须打开Master端的binlog记录功能，否则就无法实现。因为整个复制过程实际上就是Slave从Master端获取binlog日志，然后在Slave上以相同顺序执行获取的binlog日志中记录的各种SQL操作。
[mysqld] log-bin = /data/3306/mysql-bin
1.2 MySQL主从复制原理过程详细描述
第一步：
在Slave服务器上执行start slave命令开启主从复制开关，开始进行主从复制。
第二步：
此时，Slave服务器的I/O线程会通过在Master上已经授权的复制用户权限请求连接Master服务器，并请求从指定binlog日志文件的指定位置（日志文件名和位置就是在配置主从复制服务时执行change master命令指定的）之后开始发送binlog日志内容。
第三步：
Master服务器接受到来自Slave服务器的I/O线程请求后，其上负责复制的I/O线程会根据Slave服务器的I/O线程请求的信息分批读取指定binlog日志文件指定位置之后的binlog日志信息，然后返回给Slave端I/O线程。返回的信息中除了binlog日志内容外，还有在Master服务器段记录的新的binlog文件名称，以及在新的binlog中的下一个指定更新位置。
第四步：
当Slave服务器I/O线程获取到Master服务器上I/O线程发送的日志内容、日志文件及位置点后，会将binlog日志内容依次写到Slave端自身的Relay Log（即中继日志）文件（MySQL-relay-bin.xxxxxx）的最末端，并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取Master端新binlog日志能够告诉Master服务器从新binlog日志的指定文件及位置开始请求新的binlog日志内容。
第五步：
Slave服务器段的SQL线程会实时检测本地的Relay Log中I/O线程新增加的日志内容，然后及时地把Relay Log文件中的内容解析成SQL语句，并在自身的Slave服务器上按解析SQL语句的位置顺序执行应用这些SQL语句，并在relay-log.info中记录当前应用中继日志的文件名及位置点。
第2章 主从复制步骤案例
2.1 开启主库binlog功能
[[email protected] ~]# grep log-bin /data/3306/my.cnf log-bin = /data/3306/mysql-bin
2.2 确保所有实例server-id不同
[[email protected] ~]# grep server-id /data/330{6..7}/my.cnf /data/3306/my.cnf:server-id = 1 /data/3307/my.cnf:server-id = 3
2.3 主库授权复制的用户rep
mysql> grant replication slave on *.* to 'rep'@'10.0.0.%' identified by '123456'; Query OK, 0 rows affected (0.00 sec) mysql> flush privileges; Query OK, 0 rows affected (0.01 sec)
2.4 主库导出备
q 对主数据库锁表
mysql> flush table with read lock; Query OK, 0 rows affected (0.00 sec)
注：锁表之后窗口不能退出！！再开一个窗口登录。
q 查看binlog文件及位置点（--master-data=2）
mysql> show master status; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000010 | 5218 | | | +------------------+----------+--------------+------------------+ 1 row in set (0.00 sec)
q 新开一个shell窗口导出全备数据
[[email protected] backup]# mysqldump -uroot -p123456 -S /data/3306/mysql.sock -A -B --events |gzip> /service/backup/rep_bak_$(date +%F).sql.gz [[email protected] backup]# ll /service/backup/ total 144 -rw-r--r-- 1 root root 145138 Feb 6 01:04 rep_bak_2018-02-06.sql.gz
q 解锁，开放用户写入
mysql> unlock table; Query OK, 0 rows affected (0.00 sec)
2.5 从库确保server-id不同
[[email protected] ~]# grep server-id /data/3307/my.cnf server-id = 3
2.6 主库全备导入从库
[[email protected] backup]# mysql -uroot -p123456 -S /data/3307/mysql.sock < rep_bak_2018-02-06.sql [[email protected] backup]# mysql -uroot -p123456 -S /data/3307/mysql.sock -e "show databases;" +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | test | | test_dbk | +--------------------+
2.7 从库找位置点，配置master.info
在上面的show master info得到的位置信息。
mysql-bin.000010 | 5218
从库连接主库的配置如下：
CHANGE MASTER TO MASTER_HOST='10.0.0.16', MASTER_PORT=3306, MASTER_USER='rep', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000010', MASTER_LOG_POS=4547;
登录备库，执行如上指令：
[[email protected] 3307]# mysql -uroot -p123456 -S /data/3307/mysql.sock mysql> CHANGE MASTER TO -> MASTER_HOST='10.0.0.15', -> MASTER_PORT=3306, -> MASTER_USER='rep', -> MASTER_PASSWORD='123456', -> MASTER_LOG_FILE='mysql-bin.000010', -> MASTER_LOG_POS=5218; Query OK, 0 rows affected (0.03 sec) mysql>
注：1、默认情况下是没有master.info文件的。在运行了如上命令之后，会在备库的数据目录/data/3307/data/下面生成一个master.info文件！
2、如果change错误，可以使用reset sleav all，再次重新设置！！
2.8 开启从库备份开关
mysql> start slave; Query OK, 0 rows affected (0.00 sec)
2.9 查看从库同步状态
mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.0.0.15 Master_User: rep Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000010 Read_Master_Log_Pos: 536031 Relay_Log_File: relay-log.000002 Relay_Log_Pos: 531066 Relay_Master_Log_File: mysql-bin.000010 Slave_IO_Running: Yes Slave_SQL_Running: Yes #<==看到有这两个线程在的时候基本就成功了。 Replicate_Do_DB: Replicate_Ignore_DB: mysql 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: 536031 Relay_Log_Space: 531216 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 1 row in set (0.00 sec)
q Slave_IO_Running: Yes，这个是I/O线程状态，I/O线程负责从从库去主库读取binlog日志，并写入到从库的中继日志中，状态为Yes表示I/O线程正常工作。
q Slave_SQL_Running: Yes，这个是SQL线程状态，SQL线程负责读取中继日志(relay-log)中的数据并转换为SQL语句应用到从数据库中，状态为Yes表示I/O线程正常工作。
q Seconds_Behind_Master: 0，这个是在复制过程中，从库比主库延迟的秒数，这个参数很重要，但还有更准确地判断主从延迟的方法：在主库写时间戳，然后从库读取时间戳和当前数据库的时间进行比较，从而认定是否延迟。
2.10 查看主库线程状态
使用show processlist;命令可以查看mysql的线程状态：
mysql> show processlist; +----+------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+ | 57 | root | localhost | NULL | Query | 0 | NULL | show processlist | | 61 | rep | 10.0.0.16:34487 | NULL | Binlog Dump | 347 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL | +----+------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+ 2 rows in set (0.00 sec)
线程状态说明：
主库I/O线程工作状态 | 解释说明 |
Sending binlog event to slave | 线程已经从二进制binlog日志读取了一个事件并且正将它发送到从服务器。 |
Finished reading one binlog; switching to next binlog | 线程已经读完二进制binlog日志文件，并且正打开下一个要发送到从服务器的binlog日志文件。 |
Has sent all binlog to slave; waiting for binlog to be updated | 线程已经从binlog日志读取所有更新并已经发送到了从数据库服务器。线程现在为空闲状态，等待由主服务器上二进制binlog日志中的新事件更新。 |
Waiting to finalize termination | 线程停止时发生的一个很简单的状态。 |
第3章 主从复制故障解决办法
故障再现步骤：1、主库新建数据库test；2、从库删除同步过来的数据库test；3、主库上再删除数据库test。简单 执行如上步骤，则在从库就会出现复制故障问题：
show slave status:报错；且show slave status\G:
Slave_IO_Running: Yes Slave_SQL_Running: No Seconds_Behind_Master: NULL Last_Errno: 1008 Last_SQL_Error: Error 'Can't drop database 'test'; database doesn't exist' on query. Default database: 'test'. Query: 'drop database test'
q 解决方法1
stop slave; #<==临时停止同步开关 set global sql_slave_skip_counter =1; #<==将同步指针向下移动一个，可多次重复操作 start slave; #<==开启同步开关
q 解决方法2
根据忽略的错误号事先在配置文件中配置，跳过指定的不影响业务数据的错误，例如：
grep slave-skip /data/3306/my.cnf slave-skip-errors = 1032,1062,1007，1008 #<==可忽略的错误号自行设置
1007：数据库已存在，创建数据库失败
1008：数据库不存在，删除数据库失败
1032：记录不存在
1062：字段值重复，入库失败
以上是关于MySQL主从复制架构实践：主从不同步的解决方案的主要内容，如果未能解决你的问题，请参考以下文章