文章摘要(AI生成)

主从复制从库的IO线程负责读取并保存到relay-log主库的进程返回对应上次同步时间之后的bin-log信息从库的sql线程监听relay-log变动并在从库执行binlog和relaylogbinlog: 位于主库，记录主库所有数据的更改，可用于本机数据恢复和主从同步。relaylog: 位于从

主从复制

• 从库的IO线程负责读取并保存到relay-log
• 主库的进程返回对应上次同步时间之后的bin-log信息
• 从库的sql线程监听relay-log变动并在从库执行

binlog和relaylog

binlog: 位于主库，记录主库所有数据的更改，可用于本机数据恢复和主从同步。

relaylog: 位于从库，记录主节点同步的变更内容。从库会定时重放relaylog完成从库的数据写入

binlog的三种日志模式

1. statement level模式

   每一条会修改数据的sql都会记录到master的bin-log中。slave在复制的时候sql进程会解析成和原来 master端执行过的相同的sql来再次执行。

   优点：statement level下的优点，首先就是解决了row level下的缺点，不需要记录每一行数据的变化， 减少bin-log日志量，节约io，提高性能。因为他只需要记录在master上所执行的语句的细节，以及执行 语句时候的上下文的信息。

   缺点：由于它是记录的执行语句，所以为了让这些语句在slave端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在slave端被执行的时候能够得到和在master端执行时候相同的结果。另外就是,由于mysql现在发展比较快，很多的新功能加入，使mysql的复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug也就越容易出现。在statement level下，目前已经发现的就有不少情况会造成mysql的复制问题，主要是修改数据的时候使 用了某些特定的函数或者功能的时候会出现，比如sleep()在有些版本就不能正确复制。

2. row level模式

   日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改

   优点：bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了， 修改成什么样了。所以row level的日志的内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function,以及trigger的调用和触发无法被正确复制的问题。

   缺点：row level下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改记录，这样可能会产生大量的日志内容，比如有这样一条update语句：update product set owner_member_id='d' where owner_member_id='a',执行之后，日志中记录的不是这条update语句所对应的事件（mysql是以事件的形式来记录bin-log日志），而是这条语句所更新的每一条记录的变化情况，这样就记录成很多条记录被更新的很多事件。自然，bin-log日志的量会很大。

3. mixed模式

   前两种模式的结合，在mixed模式下，mysql会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在statement和row之间选一种。新版本中的statement level还是和以前一 样，仅仅记录执行的语句。而新版本的mysql中对row level模式被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录，如果sql语句确实就是update 或者delete 等修改数据的语句，那么还是会记录所有行的变更。

主从延迟

当某个SQL在从服务器上执行的时间稍长或者由于某个SQL要进行锁表就会导致，主服务器的SQL大量积压，未被同步到从服务器里。这就导致了主从不一致， 也就是**主从延迟**。

诊断：可以通过show slave status判断是否发生主从延迟。

解决：

1. 调整从库设置。适当降低数据安全设置，例如关闭binlog, innodb_flushlog等参数。
2. 在读写分离时，增加一台从服务器做备份不提供查询，提高relay_log中sql的执行效率
3. 读写分离的场景下，增加从服务器，分散从库读的压力

读写分离

读写分离，即是针对数据库的读操作和写操作分别在两个数据库上进行，在主库上执行写操作，在从库上执行读操作。分散数据库的请求压力。

支持读写分离的中间件：

中间件	特征	优缺点
Mysql-Proxy	提供一个中间代理，为我们屏蔽了主从节点数据库配置信息。	无稳定版本，无法在生产环境使用
Atlas	基于Mysql-Proxy改造，同样提供了代理层	开发者不需要知道自己的主从信息；但是需要提供额外的机器资源部署服务
Sharing JDBC	数据库客户端驱动的维度对读写分离提供支持	不需要部署额外的代理层；用户只需要在自己的项目配置相应的主从数据源即可。

分库分表

数据切分

1. 垂直切分

   • 垂直分库：按照业务分类，每个业务都有自己的独立数据库。

   • 垂直分表：按列切分，常见的方式为业务核心表与业务拓展表。

2. 水平切分

   • 库内分表：将表进行拆分，但是所有子表还在同一个数据库中
   • 分库分表：将拆分后的表，分散到不同的数据库中

切分类型	优点	缺点
垂直切分	业务间解耦，不同业务的数据进行独立的维护、监控、扩展；在高并发场景下，一定程度上缓解了数据库的压力	提升了开发的复杂度，由于业务的隔离性，很多表无法直接访问，必须通过接口方式聚合数据；分布式事务管理难度增加；数据库还是存在单表数据量过大的问题，并未根本上解决，需要配合水平切分
水平切分	单表数据量是可控的；水平扩展简单只需增加节点即可，无需对其他分片的数据进行迁移；能快速定位要查询的数据在哪个库	由于连续分片可能存在数据热点，如果按时间字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查询

数据路由

路由类型	优点	缺点
根据取值范围	单表数据量是可控的；水平扩展简单只需增加节点即可，无需对其他分片的数据进行迁移；能快速定位要查询的数据在哪个库	由于连续分片可能存在数据热点，如果按时间字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查询
hash取模	数据分片相对比较均匀，不易出现某个库并发访问的问题	但这种算法存在一些问题，当某一台机器宕机，本应该落在该数据库的请求就无法得到正确的处理，这时宕掉的实例会被踢出集群，此时算法变成hash(id) mod N-1，用户信息可能就不再在同一个库中。