MySQL主从延迟问题排查

通常情况下我们的业务都是读多写少型的业务模式，数据库层面针对该模式下的优化，一般建议使用MySQL一主多从的读写分离架构。所有的变更操作路由到master实例，所有的非强一致性读可路由到多台slave实例上，当业务量上涨我们可以通过扩展slave实例的个数来横向的扩展业务读能力。

使用读写分离架构，从业务层面来看，我们往往比较关注从slave实例读取数据的一致性，业务是否可以接受读取到落后的数据，可接受落后数据的最大时延是多少？从数据库的角度来看，未避免主从之间复制出现较大延迟，我们也需要从架构的部署、数据库表结构的设置、数据库的规范使用上来尽量的避免这个问题。

一、主从复制概念

1.1 开启主从复制必要条件

对于MySQL的主从复制的搭建，必须保证以下参数的设置：

• 主库开启log-bin，binlog会记录主库所有变更操作，该日志是主从复制的核心日志。
• 主/从库server-id不一致，server-id是数据库的唯一标识，若主从数据库server-id一致将无法创建主从复制关系

1.2 主从复制的大致流程

主从复制流程如下：

• 当两个数据库构建成为主从复制关系时，从库会启动IO线程和SQL线程；主库启动相关的dump线程。
• 主库发生的所有变更操作都会记录到binlog日志中
• 当主库发生变更时，主库的dump线程会通知从库的IO线程，IO线程根据具体的binlog文件以及位点信息将对应的日志写入到从库的relay log中；
• 从库的SQL线程解析应用relay log日志进行回放，以保证从库数据与主库一致

二、主从复制延迟分析与处理

2.1 网络延迟

• 现象
  在主从复制架构中若数据库服务器带宽成为瓶颈，主从复制之间网络延迟比较大