MySQL高可用

MySQL主从复制的过程是怎么样的

分为3个阶段：

• 写入binlog：主库修改数据后，会写入binlog日志，从库连接到主库后，主库会创建一个log dump线程，用于发送bin log的内容
• 同步binlog：从库会专门创建一个I/O线程来连接主库的log dump线程，来接受主库的binlog日志，再把binlog信息写入relay log的中继日志里，再返回给主库“复制成功”的响应
• 回放binlog：从库会专门创建一个用于回放binlog的SQL线程，去读relay log中继日志，然后回放binlog更新存储引擎的数据，实现主从的数据一致性

MySQL提高了哪些复制策略

主要有三种复制策略：同步复制、异步复制、半同步复制，MySQL默认的复制模型是异步复制

同步复制： 主库提交事务的线程要等待所有从库的复制成功响应，才返回客户端结果。性能最差，但是安全性最好。

异步复制：主库提交事务的线程不会等待binlog同步到从库，就返回客户端结果。性能最好但是安全性最差。

半同步复制：主库提交事务的线程不用等待所有的从库复制成功响应，只需要等待一部分复制成功响应回来就可以。优点是出现主库宕机，至少还有一个从库有最新的数据，不会出现数据丢失的风险。

MySQL主从复制的数据延迟怎么解决

• 使用缓存解决：可以在写入数据主库的同时，把数据写到Redis中，这样其他线程再获取数据时会先到Redis中查，也可以保证数据的一致性，不过这种方式会带来缓存和数据库的一致性问题。
• 直接查询主库：对于数据延迟铭感的业务，可以强制读取主库，但是查询数据量不能太大，不然会出现主库写请求锁行，影响读请求的执行。

MySQL主从架构中，读写分离怎么实现

• 一种简单的做法：提前将所有数据源配置在工程中，每一个数据源对应一个主库或者从库，然后改造代码，将某一个SQL语句交给其中一个数据源来处理。但是SQL路由规则侵入代码逻辑，不利用代码的维护
• 另一种做法：独立部署的代理中间件，如MyCat，这一类中间件独立部署在独立的服务器上，一般用标准的MySQL通信协议，可以代理多个数据库。优点是隔离底层数据库与上层应用访问的复杂度，比较适合有独立运维团队的公司；缺点是所有的SQL语句都要跨两次网络传输，有一点的性能损耗，再就是运维中间件是一个专业且复杂的工作，需要技术沉淀。

MySQL主库挂了怎么办

MySQL没有实现主服务器宕机和处理故障的功能，要实现自动主从故障迁移的功能，可以使用开源的MySQL高可用套件MHA,MHA可以在主数据库发生宕机的时候，剔除原有主机，选出新的主机，然后对外服务。

什么是分库分表，什么时候需要分库，什么时候需要分表

• 分库分表是把原本存储于单个数据库上的数据拆分到多个数据库，把原来存储在单张表的数据拆分到多张表中。
• 分库：当单台MySQL扛不住高并发流量的时候，就需要分库。
• 分表：当单张表数据量太大的时候，经验值是500W以上的时候，就需要分表，通过减少每次查询数据总量来解决查询慢的问题。

分库分表后，会产生什么问题

• 分布式事务问题： 对业务进行分库之后，一次大的操作由多个小操作组成，这些小的操作分布在不同的服务器上，分布式事务需要保证这些小操作要么全部成功，要么全部失败。金融类的服务，可以使用分布式中间件实现TCC事务模型；互联网业务通常对一致性要求比较低，可以用本地消息表来实现分布式事务。
• 全局唯一性问题：在单库单表的情况下，业务ID可以依赖数据库的自增来实现。但在分库。分表后，如果还是这样，会导致主键重复。我们可以使用雪花算法或者美团leaf算法来生成全局唯一性主键ID
• 跨库跨表关联问题：分库分表后，跨库和跨表的查询操作实现起来比较复杂。可以通过冗余额外字段避免跨库跨表。或者交给数据库分库分表中间件来实现，也可以将数据全量存到ES中，在ES中查询。
• 跨库跨表COUNT查询问题：数据在不同的库不同的表，进行COUNT查询比较复杂。可以将计数的数据单独存到一张表中，或者将聚合查询的数据同步到ES中，交给ES去处理