mysql数据库主从同步的原理

1.为什么数据库要设置主服务器和从服务器？

• 数据库数据是一个公司或者集团企业最为重要的资产，我得备份。
• 互联网的很多业务，特别是在高并发的场景下，基本都是读远远大于写，如果数据库读和写的压力都同在一台主机上，这显然不太合理
• 为了进一步的降低数据库端的压力(高并发的瓶颈)，这个时候也会在业务层部署分布式缓存集群(redis、memcached)等，把读的压力转移给应用服务器端（与数据主从的设计是遵循同一个原则，降低后端数据库的压力）

问题：

读写分离提高了资源的利用效率的同时也引出了一个问题，就是由于延时（网络传输，操作）而引起的数据库主从不一致的问题

异步复制

• MySQL默认的复制是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，
  问题：
• 主如果crash掉了，此时主上已经提交的事务可能并没有传到从库上。

半同步复制

• 介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性。

  问题：

  • 同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用
  • 主库的写请求时延会增长，吞吐量会降低

  半同步复制原理：

  • 事务在主库写完binlog后需要从库返回一个已接受，才放回给客户端
  • mysql5.5版本以后，以插件的形式存在，需要单独安装
  • 确保事务提交后binlog至少传输到一个从库
  • 不保证从库应用完成这个事务的binlog
  • 性能有一定的降低
  • 网络异常或从库宕机，卡主库，直到超时或从库恢复

同步过程：

1.在备库B上通过change master命令，设置主库A的IP、端口、用户名、密码，以及要从哪个位置开始请求binlog，这个位置包含文件名和日志偏移量
2.在备库B上执行start slave命令，这时备库会启动两个线程，就是图中的io_thread和sql_thread。其中io_thread负责与主库建立连接
3.主库A校验完用户名、密码后，开始按照备库B传过来的位置，从本地读取binlog，发给B
4.备库B拿到binlog后，写到本地文件，称为中转日志
5.sql_thread读取中转日志，解析出日志里的命令，并执行
日志：
undo_log:回滚日志
redo_log:重做日志
binlog: 二进制日志
relay_log:中继日志

主备、主从延迟原因

1、从库配置较主库偏低
2、主库提供写操作，备库和从库提供读操作，读操作频繁，导致备库或从库压力大。
3、执行事务较大，一般是执行比较大的DDl语句。
解决方案：
1、提升从库数量或从库配置
2、sql语句的优化

• 主数据服务器：主要用来从业务服务写入数据或者修改更新数据

• 从数据服务器：主要用来读取业务所需要的数据

• 二进制日志：用来存储写入以及更新的数据信息

• 中继日志：承接主服务器数据信息，转存在从服务器上

• I/O线程：监听主服务器是否发生数据更改的行为

• SQL线程：将主服务器数据更改的数据从中继日志文件中读取数据写入到从数据服务器中

    当主数据服务器master进行写入数据或者更新数据操作的时候，数据更改会记
    录在二进制日志（binary log file）中，主服务器master与从服务器slave进行通
    讯的是I/O线程，它将修改的数据异步复制写入到slave服务器的中继日志
    （relay log file）中,从服务器slave与中继日志之间通信使用SQL线程，SQL线
    程可以异步从中继日志中读取数据后再写入到自己的数据库中，就完成了数据
    的主从同步功能
  

2、数据库中间件同步

同步过程：

• 所有的读写都走数据库中间件，通常情况下，写请求路由到主库，读请求路由到从库

• 记录所有路由到写库的key，在主从同步时间窗口内（假设是500ms），如果有读请求访问中间件，此时有可能从库还是旧数据，就把这个key上的读请求路由到主库。

• 在主从同步时间过完后，对应key的读请求继续路由到从库。

问题：

• 中间件保证了数据绝对一致的同时，伴随着高额的成本

3、缓存写KEY法

写流程：

1）如果key要发生写操作，记录在cache里，并设置“经验主从同步时间”的cache超时时间，例如500ms

2）然后修改主数据库

读流程

1）先到缓存里查看，对应key有没有相关数据

2）有相关数据，说明缓存命中，这个key刚发生过写操作，此时需要将请求路由到主库读最新的数据。

3）如果缓存没有命中，说明这个key上近期没有发生过写操作，此时将请求路由到从库，继续读写分离。

问题：

• 虽然相对数据库中间件，成本较低，但是为了保证“一致性”，引入了一个cache组件，并且读写数据库时都多了缓存操作。