5. 主从复制模式

3、从节点的I/O线程接收到内容之后

将接收到的日志内容更新到本机的 relay log 中，并且把读取到的 binary log 文件名和位置保存到 master-info 文件中，方便下一次告知 master 从节点需要更新的位置

4、Slave 的 SQL 线程检测到 relay-log 中新增了内容

将 relay-log 的内容解析成在主节点上实际执行的操作，并在数据库中执行

5. 主从复制模式

1. 异步模式
2. 半同步模式
3. 全同步模式
4. GTID复制模式

6. MySQL高可用方案类型

（1）基于主从复制

一般情况下，采用双节点主从+ keepalived/heartbeat方案在master节点发生故障以后，复用keepalived/heartbeat的高可用机制实现快速切换到slave节点

（2）基于Galera协议（3）基于NDB协议

（4）基于中间件/proxy （5）基于共享存储

（6）基于主机高可用

MySQL架构升级之路

数据库的演变升级

1、单机

（1）请求量大查询慢（2）单机故障导致业务不可用

2、主从

（1）数据库主从同步，从库可以水平扩展，满足更大读需求（2）但单服务器TPS，内存，IO都是有限的

（3）可以考虑用主节点负责业务，从节点负责统计

3、双主

（1）用户量级上来后，写请求越来越多（2）一个Master是不能解决问题的，添加多了个主节点进行写入

（3）多个主节点数据要保存一致性，写操作需要2个master之间同步更加复杂

这边有个数据库-单表1千万数据，未来1年还会增长多500万，性能比较慢，说下你的优化思路？

思路：

千万不要一上来就说分库分表，这个是最忌讳的事项，一定要根据实际情况分析，两个角度思考

不分库分表：

（1）软优化：

1. 数据库参数调优
2. 分析慢查询SQL语句，分析执行计划，进行sql改写和程序改写
3. 优化数据库索引结构
4. 优化数据表结构优化
5. 引入NOSQL和程序架构调整

（2）硬优化

提升系统硬件（更快的IO、更多的内存）：带宽、CPU、硬盘

（3）分库分表

根据业务情况而定，选择合适的分库分表策略（没有通用的策略），外卖、物流、电商领域。

先看只分表是否满足业务的需求和未来增长，数据库分表能够解决单表数据量很大的时,数据查询的效率问题。

无法给数据库的并发操作带来效率上的提高，分表的实质还是在一个数据库上进行的操作，受数据库IO性能的限制如果单分表满足不了需求，再分库分表一起。

结论：在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案，如果数据量极大，且业务持续增长快，再考虑分库分表方案。

5、MySQL数据库分库分表后带来的优点

分库分表解决的现状问题：

可以解决数据库本身的瓶颈以及系统本身的瓶颈解决数据库本身瓶颈：

连接数：连接数过多时，就会出现‘too many connections’的错误，访问量太大或者数据库设置的最大连接数太小的原因

Mysql默认的最大连接数为100可以修改，而mysql服务允许的最大连接数为16384。

数据库分表可以解决单表海量数据的查询性能问题数据库分库可以解决单台数据库的并发访问压力问题

解决系统本身IO、CPU瓶颈

磁盘读写IO瓶颈，热点数据太多，尽管使用了数据库本身缓存，但是依旧有大量IO,导致sql执行速度慢

网络IO瓶颈，请求的数据太多，数据传输大，网络带宽不够，链路响应时间变长

CPU瓶颈，尤其在基础数据量大单机复杂SQL计算，SQL语句执行占用CPU使用率高，也有扫描行数大、锁冲突、