Mysql主从复制
1.什么是主从复制
主从复制用于构建与主数据库完全相同的数据库，称为从数据库。
[En]
Master-slave replication is used to build a database that is exactly the same as the master database, called slave database.
主数据库一般是准实时的业务数据库。
2.主从复制的作用
-
- 做数据的热备 作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。
-
- 有利于架构的扩展。 业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率， 提高单个机器的I/O性能。
-
- 读写分离，使数据库能支撑更大的并发。 在报表服务中尤其重要。由于部分报表服务的sql语句非常的慢，导致锁竞争，影响前台服务。如果前台使用master，报表服务使用slave，那么报表sql将不会造成前台锁，保证了前台速度。
3.主从复制的原理
- 第一步：Master节点将数据的改变记录成二进制日志（Binary log，简称binlog），当Master上的数据发生改变时，则将其改变写入二进制日志中。
- 第二步：Slave节点会在一定时间间隔内对Master的二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/O线程请求Master的二进制事件。
- 第三步：同时Master节点为Slave的每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至Slave节点本地的中继日志（Relay log）中，Slave节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，即解析成sql语句逐一执行，使得其数据和Master节点的保持一致，最后I/O线程和SQL线程将进入睡眠状态，等待下一次被唤醒。
中继日志通常位于OS缓存中，所以中继日志的开销很小。
简言之可分为下面几个步骤：
一、主库的更新事件会被写到bin log日志中。
二、从库启用slave服务，发起连接，连接到主库。
三、从库创建一个I/O线程，从主库读取bin log日志的内容并写入到relay log日志中。
四、从库创建一个SQL线程，从relay log里面读取内容，将更新内容写入到从库。
复制过程有一个很重要的限制，即复制在Slave上是串行化的，也就是说Master上的并行更新操作不能在Slave上并行操作,所以
复制操作是存在延时的！
4.主从同步的延时如何解决？
虽然主从架构帮助我们解决了读取的瓶颈，但由于主从之间需要数据同步，所以存在自然的延迟。
[En]
Although the master-slave architecture helps us solve the bottleneck of reading, due to the need for data synchronization between master and slave, there is a natural delay.
在这个延迟窗口中，只能从从库中读取一个旧数据，这就是主从同步的延迟问题。
[En]
During this delay window, only one old data can be read from the slave library, which is the delay problem of master-slave synchronization.
总共有五种解决方案
为了解决主从延迟和数据不一致的问题，我们可以采用以下解决方案：
[En]
In order to solve the problem of master-slave delay and data inconsistency, we can adopt the following solutions:
- 忍受大法
- 数据库同步写方案
- 选择性强制读主库
- 中间件选择路由法
- 缓存路由大法
方案1：忍受大法
不管他是谁，在这个延迟窗口之后，数据会保持一致，如果业务对数据一致性要求不高，可以使用这种方法。
[En]
Regardless of him, the data will be consistent after this delay window, and this method can be used if the business does not require high data consistency.
方案2：数据同步写方案
主从数据同步方案，一般都是采用的异步方式同步给从库。
我们可以将其修改为同步方案，主从同步完成，可以返回主库上的写操作。
[En]
We can modify it to the synchronization scheme, the master-slave synchronization is completed, and the writes on the master library can be returned.
流程如下：
- 业务系统发起写操作，数据写主库
- 写请求需要等待主从同步完成才能返回
- 数据读从库，主从同步完成就能读到最新数据
在该方案中，只需要修改数据库之间的同步配置，不需要修改业务层，比较简单。
[En]
In this scheme, we only need to modify the synchronization configuration between databases, and the business layer does not need to be modified, which is relatively simple.
不过，由于主库写需要等待主从完成，写请求的时延将会增加，吞吐量将会降低。
这一点对于现在在线业务，可能无法接受。
方案3：选择性强制读主库
对于需要强一致的场景，我们可以将其的读请求都操作主库，这样 读写都在主库，就没有不一致的情况。
这一方案的业务层需要进行改革，使之成为强制性的，这是比较难转型的。
[En]
The business layer of this scheme needs to be reformed to make it mandatory, which is relatively difficult to transform.
不过这种方案相对于浪费了另一个数据库，增加主库的压力。
方案4：中间件路由法
该方案需要使用中间件，其中所有数据库操作首先被发送到中间件，然后被分发到相应的数据库。
[En]
This scheme requires the use of a middleware in which all database operations are first sent to the middleware and then distributed to the corresponding database.
这时流程如下：
- 写请求，中间件将会发到主库，同时记录一下此时写请求的 key（ 操作表加主键等）
- 读请求，如果此时 key 存在，将会路由到主库
一定时间后（*经验值*），中间件认为主从同步完成，删除这个 key，后续读将会读从库
延迟窗口内的读给打到主库，一定时间后，中间件认为延迟窗口的时间到了，主从同步复制完成了，后续请求可以打到从库，即不同时间打到不同库
方案5：缓存路由法
该方案类似于中间件的方案流程，但改造成本相对较低，不需要中间件。
[En]
This scheme is similar to the scheme flow of middleware, but the transformation cost is relatively low and no middleware is needed.
这时流程如下:
- 写请求发往主库，同时缓存记录操作的 key，缓存的失效时间设置为主从的延时
- 读请求首先判断缓存是否存在
- 若存在，代表刚发生过写操作，读请求操作主库
- 若不存在，代表近期没发生写操作，读请求操作从库
将redis的key的过期时间设置为主从的延时，这样就可以决定请求应该打到主库还是从库
5.主从复制需要的配置
主服务器：
1、开启二进制日志
2、配置唯一的server-id
3、获得master二进制日志文件名及位置
4、创建一个用于slave和master通信的用户账号
从服务器：
1、配置唯一的server-id
2、使用master分配的用户账号读取master二进制日志
3、启用slave服务
Original: https://www.cnblogs.com/yinbiao/p/16230289.html
Author: 西*风
Title: Mysql主从复制
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/22103/
转载文章受原作者版权保护。转载请注明原作者出处！
