[MySQL]主从复制

主从复制

• 主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库
• 主数据库一般是准实时的业务数据库
• mysql主从复制是mysql高可用性，高性能（负载均衡）的基础
• 简单，灵活，部署方式多样，可以根据不同业务场景部署不同复制结构，复制过程中应该时刻监控复制状态，复制出错或延时可能给系统造成影响mysql主从复制目前也存在一些问题，可以根据需要部署复制增强功能

主从复制作用

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

主从复制的原理

• 数据库有bin-log二进制文件，记录了所有sql语句

• 将主数据库的bin-log文件的sql语句复制过来

• 使其在从数据库的重做日志文件中再执行一次这些sql语句

• 需要三个线程完成主从配置

  • binlog输出线程:每当有从库连接到主库的时候，主库都会创建一个线程然后发送binlog内容到从库。在从库里，当复制开始的时候，从库就会创建两个线程进行处理
  • 从库I/O线程:当START SLAVE语句在从库开始执行之后，从库创建一个I/O线程，该线程连接到主库并请求主库发送binlog里面的更新记录到从库上。从库I/O线程读取主库的binlog输出线程发送的更新并拷贝这些更新到本地文件，其中包括relay log文件
  • 从库的SQL线程:从库创建一个SQL线程，这个线程读取从库I/O线程写到relay log的更新事件并执行
    

主从复制步骤

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

主从复制问题

主库宕机后，数据可能丢失（数据不一致）

半同步复制—解决数据丢失的问题

从库只有一个sql Thread，主库写压力大，复制很可能延时（slave DB 读延迟）

并行复制—-解决从库复制延迟的问题

复制架构

异步复制

• 主库将事务 Binlog 事件写入到 Binlog 文件中，此时主库只会通知一下 Dump 线程发送这些新的Binlog
• 然后主库就会继续处理提交操作，而此时不会保证这些 Binlog 传到任何一个从库节点上

同步复制

• 当主库提交事务之后，所有的从库节点必须收到、APPLY并且提交这些事务，然后主库线程才能继续做后续操作
• 但缺点是，主库完成一个事务的时间会被拉长，性能降低。

半同步复制

主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。半同步复制最好在低延时的网络中使用

• 5.5集成到mysql，以插件的形式存在，需要单独安装
• 确保事务提交后binlog至少传输到一个从库
• 不保证从库应用完这个事务的binlog
• 性能有一定的降低，响应时间会更长
• 网络异常或从库宕机，卡住主库，直到超时或从库恢复

并行复制

并行复制完全解决了MySQL的复制延迟问题

• 社区版5.6中新增，5.7真正的并行复制
• 并行是指==从库多线程apply binlog库级别并行应用binlog，同一个库数据更改还是串行的(5.7版并行复制基于事务组)
• 设置设置sql线程数为10