常见方案：三种

  1. MMM
  2. MHA
  3. MGR

特点：

  1. 对主从结点复制的master进行监控
  2. 自动对master进行迁移，vip方式
  3. 重新配置集群的其他slave对新master进行同步

    MMM

    master-master-replication manager for MySQL ，基于Perl语音实现，可以主从配置，故障迁移
    需要两个master，只有一个对外提供服务，类似主备模式
    通过VIP进行两主之间的切换，但是不能从备用服务切换成主服务
    image.png
    不需要开发切换的脚本
    不支持gtid的复制

MHA

master high availability manager andtools forMySQL
基于Perl脚本的工具
可以实现把slave转成master服务，，会把拥有新数据的slave结点
会避免数据一致性的问题，
淘宝的内部TMHA产品
MHA需要单独部署，分为manager结点和node结点
manger：单独部署
node：部署在每一台MySQL的机器上，会解析各个MySQL进行操作

image.png
优点
：支持GTID
可以从旧的master中恢复二进制日志，
缺点
需要自行开发vip转移脚本
只监控master状态，未监控slave的状态

MGR

MySQL Group Replication ，类似zk的事务，过半提交，保证主从一致，解决异步复制，半同步复制的一致性问题
一个复制组，过半数结点通过后，才会提交。
依赖一致性协议，类似paxos协议，实现
两种模式

  1. 多主模式，
  2. 单主模式

image.png

分库分表

1：作用

提高数据库性能，

2：方式

  1. 垂直分片（纵向分片）
    对业务进行分批，就是专库专用，不同的数据，放在不同的表中，
    image.png
    需要对架构设计进行调整，单点的瓶颈还是有的，
    可以缓解数据量访问量的问题，但是超过单点的阈值，还是需要水平分的

水平分片（横向分片）
不是根据业务逻辑分，而是通过某个字段，吧数据分散到不同的库中，
每个每篇保存一部分的数据
image.png

分片的策略

取模，取余，：可以均匀放数据，但是扩容非常麻烦
范围分配：容易扩容，数据不够均匀
时间分片：容易扩容，
枚举分片：按照地区
各种考虑吧，

3：分库分表的缺点：

  1. 事务一致性问题
  2. 跨节点关联查询问题
  3. 跨节点分页，排序函数
  4. 主键比重问题
  5. 公共表处理问题
  6. 运维工作问题

    4：什么时候需要分库分表

    单表数据500w，或容量达到2G,

如果是增长缓慢的业务，可以预估数据，做好方案

如果是增长快速，且稳定，可以多分一些

考虑降级的问题，比较统计查询，分页，聚合考虑ES方案

5：常见的分库分标组件

提供标准化的数据分片、分布式事务和数据库治理功能