主从复制与读写分离

主从复制

一、主从复制定义

主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库；主数据库一般是准实时的业务数据库。

二、主从复制的作用

1、做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。
2、架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。
3、读写分离，使数据库能支撑更大的并发。
4、容灾实时备份

三、主从复制原理

数据库有个bin-log二进制文件，记录了所有sql语句。我们的目标就是把主数据库的bin-log文件复制到从数据库中。让其在从数据的relay-log中继日志文件中再执行一次这些sql语句即可。

主要涉及三个线程：binlog 线程、I/O 线程和 SQL 线程。

• binlog 线程 ：负责将主服务器上的数据更改写入二进制日志（Binary log）中，并将日志文件发送给从库。 主节点会创建一个log dump 线程，作用是将数据库的操作写入日志文件，并当日志文件更新时，发送bin-log（二进制日志）给从节点
• I/O 线程 ：该线程连接到主库并请求主库发送binlog日志文件到从库，负责从主服务器上读取二进制日志，并写入从服务器的中继日志（Relay log）。该线程连接到master机器，master机器上的binlog dump线程会将binlog的内容发送给该I/O线程。该I/O线程接收到binlog内容后，再将内容写入到本地的relay log。 请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 进程发来的更新之后，保存在本地relay-log(中继日志)中（持久化）
• SQL 线程 ：负责读取中继日志relay log，解析出主服务器已经执行的数据更改并在从服务器中重放（Replay）。该线程读取I/O线程写入的relay log。并且根据relay log的内容对slave数据库做相应的操作

三个线程具体配合执行步骤：

• 步骤一：主库db的更新事件(update、insert、delete)被写到binlog
• 步骤二：从库发起连接，连接到主库
• 步骤三：此时主库创建一个binlog dump thread，把binlog的内容发送到从库
• 步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log
• 步骤五：还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db

主从复制原理总结：master端将具体操作写入二进制日志文件，slave端会复制master端的二进制日志文件，并读取日志的内容，解析成具体的操作并执行，此时主从便是同步的。

四、主从同步模式

主从同步复制有以下几种方式：
（1）全同步复制，master的变化，必须等待slave-1,slave-2,…,slave-n完成后才能返回。
1、逻辑上
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端一个响应。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
2、技术上
当主库提交事务之后，所有的从库节点必须收到、apply并且提交这些事务，然后主库线程才能继续做后续操作。但缺点是，主库完成一个事务的时间会被拉长，性能降低。
（2）异步复制，master只需要完成自己的数据库操作即可，至于slaves是否收到二进制日志，是否完成操作，不用关心。MYSQL的默认设置。

MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从库上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。
技术上：主库将事务 Binlog 事件写入到 Binlog 文件中，此时主库只会通知一下 Dump 线程发送这些新的 Binlog，然后主库就会继续处理提交操作，而此时不会保证这些 Binlog 传到任何一个从库节点上。
注意：由于 mysql 实现的异步复制，所以主库和从库数据之间存在一定的差异，在从库执行查询操作需要考虑这些数据的差异，一般只有更新不频繁和对实时性要求不高的数据可以通过从库查询，实行要求高的仍要从主库查询。

（3）半同步复制，介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay-log中才返回成功信息给客户端（只能保证主库的bin-log至少传输到了一个从节点上，但并不能保证从节点将此事务执行更新到db中。

1、逻辑上
是介于全同步复制与全异步复制之间的一种，主库只需要等待至少一个从库节点收到并且 Flush Binlog 到 Relay Log 文件即可，主库不需要等待所有从库给主库反馈。同时，这里只是一个收到的反馈，而不是已经完全完成并且提交的反馈，如此，节省了很多时间。
2、技术上
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。
所以说，半同步提高了数据完整性，至少存在两个地方。半同步失败，自动降级为异步，直到修复好

五、支持的复制类型/日志格式

日志格式就是指二进制日志的三种格式：基于语句statement的复制、基于行row的复制、基于语句和行（mix）的复制。其中基于row的复制方式更能保证主从库数据的一致性，但日志量较大，在设置时考虑磁盘的空间问题

• 基于语句的复制。在服务器上执行sql语句，在从服务器上执行同样的语句，mysql默认采用基于语句的复制，执行效率高。

优点是只需要记录会修改数据的sql语句到bin-log中，减少了bin-log日质量，节约I/O，提高性能。缺点是在某些情况下，会导致主从节点中数据不一致（比如sleep(),now()等）

• 基于行的复制。把改变的内容复制过去，而不是把命令在从服务器上执行一遍。 复制数据库变化的内容，不是执行命令

mysql master将SQL语句分解为基于Row更改的语句并记录在bin-log中，也就是只记录哪条数据被修改了，修改成什么样。优点是不会出现某些特定情况下的存储过程、或者函数、或者trigger的调用或者触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是修改table的时候会让日志暴增,同时增加bin-log同步时间。也不能通过bin-log解析获取执行过的sql语句，只能看到发生的data变更

• 混合类型的复制。默认采用基于语句的复制，一旦发现基于语句无法精确复制时，就会采用基于行的复制。

六、主从复制配置操作详解
https://blog.csdn.net/qq_15092079/article/details/81672920
https://cloud.tencent.com/developer/article/1701635

七、主从复制架构

1. 一主多从架构
   在主库的请求压力非常大时，可通过配置一主多从复制架构实现读写分离，把大量对实时性要求不是很高的请求通过负载均衡分发到多个从库上去读取数据，降低主库的读取压力。而且在主库出现宕机时，可将一个从库切换为主库继续提供服务

2. 多级复制架构
   因为每个从库在主库上都会有一个独立的Binlog Dump线程来推送binlog日志，所以随着从库数量的增加，主库的IO压力和网络压力也会随之增加，这时，多级复制架构应运而生。
   多级复制架构只是在一主多从的基础上，再主库和各个从库之间增加了一个二级主库Master2，这个二级主库仅仅用来将一级主库推送给它的BInlog日志再推送给各个从库，以此来减轻一级主库的推送压力。
   但它的缺点就是Binlog日志要经过两次复制才能到达从库，增加了复制的延时。
   我们可以通过在二级从库上应用Blackhol存储引擎（黑洞引擎）来解决这一问题，降低多级复制的延时。
   “黑洞引擎”就是写入Blackhole表中数据并不会写到磁盘上，所以这个Blackhole表永远是个空表，对数据的插入/更新/删除操作仅在Binlog中记录，并复制到从库中去

3. 双主复制/Dual Master架构
   双主复制架构适用于需要进行主从切换的场景
   在只有一个主库的架构下，当主库宕机后，将其中一个从库切换为主库继续提供服务。原来的主库就没有数据来源了，那么当这个新的主库接收到新的数据时，原来的主库却没有同步，因此他们的数据差异越来越大，那么原来的主库就无法成为主从复制环境中的一员了。当原来的主库恢复正常后，需要重新将其添加进复制环境中去。
   那为了避免重复添加主库的问题，双主复制应运而生。两个数据库互为主从，当主库宕机恢复后，由于它还是原来从库（现在主库）的从机，所以它还是会复制新的主库上的数据。那么无论主库的角色怎么切换，原来的主库都不会脱离复制环境。

读写分离

一、读写分离定义

读写分离就是在主服务器上修改，数据会同步到从服务器，从服务器只能提供读取数据，不能写入，实现备份的同时也实现了数据库性能的优化，以及提升了服务器安全。

MySQL读写分离的基础：实现方式主要基于mysql的主从复制，通过路由的方式使应用对数据库的写请求只在master上进行，读请求在slave上进行。

读写分离能提高性能的原因在于：

• 主从服务器负责各自的读和写，极大程度缓解了锁的争用；
• 从服务器可以使用 MyISAM，提升查询性能以及节约系统开销；
• 增加冗余，提高可用性。

二、读写分离实现方式

• 基于程序代码内部实现
  在代码中根据select 、insert进行路由分类，这类方法也是目前生产环境下应用最广泛的。优点是性能较好，因为程序在代码中实现，不需要增加额外的硬件开支，缺点是需要开发人员来实现，运维人员无从下手。
  
  实现方案
  基于spring的aop实现: 用aop来拦截spring项目的dao层方法，根据方法名称就可以判断要执行的sql类型(即是read还是write类型)，进而动态切换主从数据源。

• 基于中间代理层实现
  代理一般介于应用服务器和数据库服务器之间，代理数据库服务器接收到应用服务器的请求后根据判断后转发到后端数据库。代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器。
  
  开源方案：
  MySQL的代理最常见的是mysql-proxy、cobar、mycat、Atlas等。这种方式对于应用来说，MySQL Proxy是完全透明的，应用需要连接到MySQL Proxy的监听端口即可，同时再代理服务器中配置文件中配置后面要路由的主从架构的MySQL服务器即可。当然，这样proxy机器可能成为单点失效，但完全可以使用多个proxy机器做为冗余，在应用服务器的连接池配置中配置到多 个proxy的连接参数即可。

三、读写分离引入的问题

1、主从同步延迟
使用读写分离架构时，数据库主从同步具有延迟性，数据一致性会有影响，对于一些实时性要求比较高的操作，可以采用以下解决方案。

• 写后立刻读：在写入数据库后，某个时间段内读操作就去主库，之后读操作访问从库。
• 二次查询：先去从库读取数据，找不到时就去主库进行数据读取。该操作容易将读压力返还给主库，为了避免恶意攻击，建议对数据库访问API操作进行封装，有利于安全和低耦合。
• 根据业务特殊处理：根据业务特点和重要程度进行调整，比如重要的，实时性要求高的业务数据读写可以放在主库。
• 对于次要的业务，实时性要求不高可以进行读写分离，查询时去从库查询。

2、读写分配机制： 同时也伴随着读写分配机制的实现
读写路由分配机制是实现读写分离架构最关键的一个环节，就是控制何时去主库写，何时去从库读。目前较为常见的实现方案分为以下两种：

• 基于编程和配置实现（应用端）：程序员在代码中封装数据库的操作，代码中可以根据操作类型进行路由分配，增删改时操作主库，查询时操作从库。这类方法也是目前生产环境下应用最广泛的。优点是实现简单，因为程序在代码中实现，不需要增加额外的硬件开支。缺点是需要开发人员来实现，运维人员无从下手，如果其中一个数据库宕机了，就需要修改配置重启项目。
• 基于服务器端代理实现（服务器端）：中间件代理一般介于应用服务器和数据库服务器之间。应用服务器并不直接进入到master数据库或者slave数据库，而是进入MySQL proxy代理服务器。代理服务器接收到应用服务器的请求后，先进行判断然后转发到后端master和slave数据库。