mysql三高架构之路

1三高
高并发
高性能
高可用：系统可用时间高
复制，扩展，切换
复制
目的：数据冗余
手段：binlog传送
收获：并发量提升，可用性提升
问题：占用更多的资源

拓展
目的：拓展数据库容量
手段：数据库分片分表
收获：性能、并发量的提升
问题：降低可用性

切换
目的：提高可用性
手段：主备切换
手段：并发量提升
问题：丢失切换时期数据

三高

2 复制
原理

relaylog，二道贩子，中继日志
重放：重新执行一遍
概括：binlog传送
复制的类型

异步复制

原理简单
对网络延迟要求较小
不能保证日志被传送到备库，可能丢失数据

半同步复制

只关心日志传送来吗，不关系执行
原理简单
对网络延迟有要求，最好在同一机房
可以保证日志被传送到备库，不易丢失

时间到了切换成异步复制

组复制

用的不多
原理复杂，中间是共识机制，依赖共识算法
是数据库走向原生分布式的方向（Tidb，华为的OCEANdb）

3 主从复制实操
异步
主备打开binlog
配置文件中

systemctl restart mysqld

不能热备
先上全局锁


在12号194位置后面开始同步
备份主库的所有数据

传送到备库

主库撤销锁

备库
执行传送来的文件
source dbdump.sql
配置备库



start slave

半同步
主备配置文件
脱钩时间

4 怎么使得复制配置更方便
binlog位置那部分不方便
思路

GTID

启用
配置文件中


5 为什么binlog格式会影响复制
格式
statement格式

ROW格式的

mixed格式

mixed格式的用的还是比较少，一般都用row

基于语句或者行的复制

6 备库延迟太大，怎么办
备库延迟的原因

处理方式

依然存在的问题

主库的binlog是多线程产生的，而备库复现主库的binlog是一个sql_thread单线程复现的，所以不行

解决思路

分配relaylog是关键，不是随便分配的，有顺序的

mysql5.6并行复制

mysql5.7使用按事物组并行的策略


优化
三个写的同一个binlog文件
1号等23后，最后写，所以把123叫一个事务组
内在原理是123肯定不会有锁，因为基本一起prepare


这两个参数是配合用的
延时多少微秒后，等的人到了多少就提交，万一等了10微妙，来了1000万个就不行了


8 如何在备库读到最新的数据
强制走主库
如何判读备库已经追上主库

备库延时理论上是没办法完全消除的

判断具体事务是否已经重放

怎样实现最简单的高可用架构
主-主复制架构

已经是主备了，再用主配置一下备

只读就是配置参数read only=1

问题

数据冲突问题

客户端切换

循环复制