mysql 集群

主从模式：

• 主从复制模式场景：实时灾备，用于故障切换（高可用）读写分离，从服务器提供查询服务数据备份，（高可用）

• 主从复制实现原理主从复制主要依赖的是数据库的 binlog 日志，主库会把变更的信息写入到 binlog 日志中，从库的 IO Thread 同步主库的 binlog 日志到从库的本地 replay log 中，然后从库中的 sqlThread 线程解析 replay log 在从库执行。

• 从在的问题主机宕机，数据可能从在丢失，解决方案：半同步复制，在主库收到从库同步 binlog 日志后再提交事务；主从数据同步有延迟解决方案：并行复制，再从库解析 replay log 时 多增加一些 SQLThread

双主模式：

互为主从，提高主库的高可用

• 双主双写存在问题：id 冲突问题，如果使用的自增主键，在没有同步的时候可能会出现冲突（可以使用 mysql 的自动增长步长来解决）更新丢失问题，同一条记录在两个不同的库里面更新时后面的更新会覆盖前面的更新

• 双主单写写性能相对双写小点，但是没有更新丢失的问题（推荐使用）

分库分表存在问题

1. 跨节点数据库 Join 关联查询（.数据库切分前，多表关联查询，可以通过 sql join 进行实现 2.分库分表后，数据可能分布在不同的节点上，sql join 带来的问题就比较麻烦）利用空间换时间、字段冗余，把要关联查询的字段冗余全局表，对于一些依赖的数据表，在灭格尔数据库中都保存一份绑定表、对一些业务关联的表保存在同一个分片中 跨节点 join 问题，可以在代码中分开查询，

2. 分库操作带来的分布式事务问题

使用分布式事务：TCC 或者是两段提交

1. 执行的 SQL 排序、翻页、函数计算问题

可以根据分片的方式，在每个节点上进行对应的操作，然后再在代码中合并，得到最终的结果

1. 数据库全局主键重复问题

使用分布式主键解决方案：1、使用 redis 自增、2、mysqsl 维护一张主键表，3、uuid，4、雪花算法

1. 容量规划,分库分表后二次扩容问题停机扩容停机，使用提前准备的脚本，进行数据迁移修改新的分片规则启动服务器免迁移扩容（采用双倍扩容，一半数据迁移至新库）