主从复制

读写分离

• 流程
  
• 原理

bin log

• STATEMENT
  • 优点：记录的是执行的SQL,比较省空间，降低了主从复制时的IO开销
  • 缺点：由于记录的是SQL，所以MySQL多个节点之间复制的时候，特定场景下会导致数据不一致的情况
• ROW
  • 优点：记录的是每条数据的变化，内容比较容易理解，不会有多个节点数据不一致的问题
  • 缺点：由于记录的是每行数据的变化，所以占用的空间较大，特别是对于字段较多的表的操作、大批量操作来说
• MIXED
  • 两种模式的结合
  • MySQL会根据执行的具体SQL自动选择用STATEMENT或ROW
• 如何选择？
  • STATEMENT：希望更好的性能，更小的主从复制开销，并且项目并未使用STATEMENT不支持的一些语法
  • ROW：希望更好的数据一致性、希望binlog的记录更加直观

主从复制的部署架构

一主一从，一主多从

级联复制

双主

MySQL复制

异步复制

• 默认的复制方式
• 主节点写入binlog文件后就返回客户端，不考虑binlog是否已完整同步到从节点、是否已完整存放到从节点的relay log中去
• 优点：性能好，无阻塞
• 缺点：如果主节点发生宕机，主节点上已提交的事务尚未同步到从节点，如果此时强行将从节点晋升为主节点，会导致新主节点数据不完整

半同步复制

• 主库提交事务后，不立即返回，而是等待至少一个从库接收到binlog，并写入relay log才返回，从而保证主库出问题时，至少有一个从库的数据是完整的
• 当等待超时时，会降低到异步复制，保证主库的正常更新

方案1：5.6及以前

• 存在的问题：主库在等待从库确认ACK时，尽管没有返回给客户端，但是事务已被提交了。如果在binlog还未发送到从库瞬间，主库发生宕机，那么主从切换后新的主库无法读到尚未同步过来的数据

方案2：5.7开始

GTID复制

• GTID（Global Transaction ID，全局事务标识）的简称，是对一个已提交事务的编号，并且全局唯一，一个事务对应一个GTID
• GTID由UUID + TID组成，UUID是MySQL实例的唯一标识；TID则是事务在该实例上提交的顺序
  

多源复制

• 适用场景
  • 数据分析团队可能要分析多个微服务的数据，可使用多源复制，将多个微服务的数据复制到一个数据库中去，以便统一分析
  • 数据备份，一个大型项目往往有多个微服务、多个数据库实例，可以把多个数据库复制到一个数据库实例实现数据备份

Percona XtraDB Cluster（PXC）

Galera

• Codeaship开源的MySQL集群方案
• 

概念

• 组通信（Group Communication）：定义了数据库节点间的通信模式，保证复制数据的一致性
• Write-Set Replication API（wsrep API）：为上层提供丰富的状态信息及回调函数，实现多点写入及同步复制
• 写集（Write-Set）：一个将要被复制的事务
  • 写集中不仅包括对事务影响的所有行的主键（组成写集的key），还包括事务产生的binlog（组成写集的data），key-data就是写集
  • key用来验证和其他事务没有冲突
  • data用来验证通过后应用与提交
• 数据传输方式
  • SST全量传输，支持Mysqldump、rsync、XtraBackup三种方式
  • IST增量传输，支持XtraBackup
• 使用端口
  • 3306，MySQL对外服务的端口号
  • 4444，SST使用的端口
  • 4567，组成员之间通信的端口
  • 4568，IST使用的端口