主从复制
读写分离
- 流程
- 原理
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使用的端口
