MySQL主从复制与读写分离实战：从原理到高可用架构部署-育师

1. 项目概述：为什么我们需要主从复制与读写分离？

在任何一个业务量稍具规模的在线系统中，数据库都是最核心、也最容易成为瓶颈的一环。想象一下，你运营着一个电商网站，白天有成千上万的用户同时浏览商品、下单、查询物流，这些操作绝大部分都是对数据库的“读”请求。与此同时，后台的运营人员在进行商品上架、价格调整、订单处理，这些则是“写”操作。如果所有请求都涌向同一台数据库服务器，会发生什么？高峰期时，CPU和I/O资源被争抢，用户会明显感觉到页面加载变慢，甚至出现超时错误，体验极差。更危险的是，一旦这台唯一的服务器因为硬件故障、机房断电或者一次错误的运维操作而宕机，整个业务将瞬间停摆，损失不可估量。

MySQL主从复制（Master-Slave Replication）和读写分离（Read-Write Splitting），正是为了解决上述两个核心痛点而生的经典架构方案。这不是什么高深莫测的新技术，而是经过无数互联网公司验证的、最基础也最有效的数据库高可用与性能扩展手段。简单来说，主从复制就是让一台主数据库（Master）的数据，自动、异步地同步到一台或多台从数据库（Slave）上。而读写分离，则是在应用层面，将“写”操作（如INSERT, UPDATE, DELETE）定向到主库，将“读”操作（如SELECT）分摊到多个从库上。

这套组合拳带来的好处是立竿见影的：首先，它极大地提升了系统的读并发能力，因为读请求可以被多个从库分担；其次，它增强了数据可靠性，即使主库宕机，从库也能迅速顶替上来（需要配合其他高可用方案）；再者，它方便了数据备份、统计分析等离线操作，可以在不影响主库性能的从库上进行。无论你是运维工程师、后端开发者，还是架构师，理解并能够亲手搭建这套环境，都是一项不可或缺的核心技能。接下来，我将抛开理论空谈，带你从原理到实操，一步步构建一个稳定可靠的MySQL主从复制与读写分离环境。

2. 核心原理深度拆解：日志、线程与数据流

在动手配置之前，我们必须吃透其工作原理。很多配置失败或数据不一致的问题，根源都在于对原理的一知半解。MySQL的主从复制本质上是基于二进制日志（Binary Log）的异步数据同步。

2.1 二进制日志：复制的基石

二进制日志（binlog）是MySQL服务层产生的一种逻辑日志，它忠实地记录了所有对数据库执行更改的“事件”（Event），比如一条UPDATE语句影响了哪些行。与存储引擎层的重做日志（redo log）不同，binlog是逻辑的、语句或行格式的，主要用于复制和数据恢复。

binlog的三种格式至关重要：

STATEMENT（SBR）：记录原始的SQL语句。优点是日志量小，节省空间和网络带宽。缺点是某些非确定性函数（如NOW(),RAND(),UUID()）或存储过程可能在主从库上执行结果不一致，存在安全隐患。
ROW（RBR）：记录每一行数据被修改后的内容。优点是最安全，能保证主从数据的绝对一致性。缺点是日志量巨大，尤其是批量更新时，可能对I/O和网络造成压力。
MIXED（MBR）：混合模式。MySQL会自行判断，对可能引起不一致的语句使用ROW格式，其他使用STATEMENT格式。这是目前生产环境最推荐、也最常用的格式，在安全性和性能之间取得了良好平衡。

实操心得：在my.cnf中通过binlog_format = MIXED来设置。务必在主从库上都明确配置，避免因默认值不同导致复制异常。早期版本默认可能是STATEMENT，这是很多复制数据错误的源头。

2.2 复制线程与工作流程

主从复制主要由三个线程协同完成，理解它们就像理解一条生产流水线：

Binlog Dump Thread（主库）：当从库连接上主库时，主库会为每个连接的从库创建一个“倾倒”线程。这个线程的唯一职责就是，当主库的binlog有更新时，主动将新增的日志事件“推”给从库的I/O线程。它就像流水线的源头投料工。
I/O Thread（从库）：从库上运行的线程，负责与主库的Dump线程建立连接，接收主库发送过来的binlog事件，并将其写入从库本地的中继日志（Relay Log）文件中。它扮演着物流运输和临时仓储的角色。
SQL Thread（从库）：从库上另一个核心线程。它不停地读取本地的中继日志，解析出其中记录的日志事件（即当初在主库上执行的SQL语句或行变更），并在从库上重新执行（Replay）一遍，从而让从库的数据与主库保持一致。它就是流水线末端的组装工人。

整个数据流可以概括为：主库事务提交 -> 写入Binlog -> 主库Dump线程读取Binlog并发送 -> 从库I/O线程接收并写入Relay Log -> 从库SQL线程读取Relay Log并重放执行。

2.3 异步复制与半同步复制

默认的复制模式是完全异步的。主库事务提交后，只要将事件写入自身binlog就认为成功，并不关心从库是否收到或执行。这种模式性能最好，但存在数据丢失风险：如果主库在将事件发送给从库前崩溃，那么已提交的事务数据可能丢失。

为了解决这个问题，MySQL 5.5+引入了半同步复制（Semisynchronous Replication）。在半同步模式下，主库在提交事务时，会阻塞等待至少一个从库的I/O线程确认已收到该事件并写入其Relay Log（注意，不是执行完）。收到确认后，主库才返回给客户端事务提交成功。这在一定程度上保证了数据的安全性，但以略微增加写延迟为代价。

注意事项：半同步复制虽然增强了数据可靠性，但它不是强一致的。它只保证事件被从库接收，不保证被执行。且如果超时时间内未收到从库确认，主库会自动降级为异步模式，以保证自身可用性。对于金融等强一致性场景，需考虑MySQL Group Replication或基于Paxos/Raft的第三方方案。

3. 环境准备与配置详解

理论清晰后，我们进入实战环节。假设我们有两台服务器：192.168.1.100作为主库（Master），192.168.1.101作为从库（Slave）。操作系统均为CentOS 7+，MySQL版本为8.0+（版本需尽量一致，避免兼容性问题）。

3.1 主库（Master）配置

首先，登录主库服务器，编辑MySQL配置文件/etc/my.cnf（路径可能因安装方式而异），在[mysqld]段落下添加或修改以下关键参数：

[mysqld] # 服务器唯一ID，这是主从识别的关键，必须唯一 server-id = 100 # 启用二进制日志，并指定日志文件前缀 log-bin = mysql-bin # 设置二进制日志格式，推荐MIXED binlog_format = MIXED # 设定需要复制的数据库（可选，不配置则默认复制所有库） # binlog-do-db = your_database_name # 设定不需要复制的数据库（可选，与上一条二选一） # binlog-ignore-db = mysql # binlog-ignore-db = information_schema # binlog-ignore-db = performance_schema # binlog-ignore-db = sys # 为每个session分配的内存，在事务过程中用来存储二进制日志的缓存 binlog_cache_size = 1M # 设置二进制日志过期时间，避免磁盘被占满（单位：天） expire_logs_days = 7 # 跳过主从复制中遇到的所有错误或指定类型的错误，避免复制中断 # 例如1062错误是主键重复，1032错误是记录不存在。生产环境慎用，建议设为0，遇到错误手动处理。 slave_skip_errors = 1062

参数解读与避坑指南：

server-id：这是整个复制拓扑中的“身份证”。主库、从库以及未来可能添加的级联从库，都必须拥有全局唯一的ID。通常用IP地址的最后一段是个好习惯。
log-bin：不指定路径则默认存放在数据目录（datadir）下。务必确保该目录有足够的磁盘空间。
binlog-ignore-db：通常我们会忽略MySQL自带的系统库，因为它们不需要被复制到从库，且可能包含服务器特定的信息。这是必须配置的一步，否则可能导致复制错误或从库系统表混乱。
slave_skip_errors：在初次搭建测试或处理一些可忽略的冲突时，可以临时设置跳过特定错误。但在生产环境，强烈建议设置为空或0，让复制在出错时停止，以便DBA及时介入排查根本原因，防止数据不一致在沉默中扩散。

配置完成后，重启MySQL服务使配置生效：

systemctl restart mysqld

3.2 创建复制专用账户

出于安全考虑，我们不应使用root账户进行复制。需要在主库上创建一个专门用于复制的用户。

登录主库MySQL命令行：

mysql -u root -p

执行以下SQL：

-- 创建一个用户名为‘repl’，允许从‘192.168.1.101’主机连接的账户，密码为‘Repl@123456’ CREATE USER 'repl'@'192.168.1.101' IDENTIFIED BY 'Repl@123456'; -- 授予该用户复制相关的权限 GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.101'; -- 刷新权限 FLUSH PRIVILEGES;

重要安全提示：密码应足够复杂，且@‘host’部分应严格限定为从库的IP地址，不要使用‘%’通配符，以减少安全风险。在生产环境中，这一步的权限控制至关重要。

3.3 获取主库状态信息

在主库上执行以下命令，记录下关键信息，后续在从库配置时会用到：

SHOW MASTER STATUS;

你会看到类似下面的输出：

+------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000003 | 785 | | | | +------------------+----------+--------------+------------------+-------------------+

请务必记下File(mysql-bin.000003) 和Position(785)这两个值。它们告诉从库：“请从我的这个日志文件的这个位置开始复制”。

3.4 从库（Slave）配置

现在，登录从库服务器，编辑其MySQL配置文件/etc/my.cnf：

[mysqld] # 服务器唯一ID，必须与主库不同 server-id = 101 # 启用中继日志 relay-log = mysql-relay-bin # 将中继日志的索引文件也记录下来 relay-log-index = slave-relay-bin.index # 设定需要复制的数据库（可选，与主库过滤规则配合使用） # replicate-do-db = your_database_name # 设定不需要复制的数据库（可选） # replicate-ignore-db = mysql # replicate-ignore-db = information_schema # replicate-ignore-db = performance_schema # replicate-ignore-db = sys # 设置为只读模式，防止应用误写入从库导致数据不一致 read_only = ON # 以下用户不受read_only限制（例如复制线程、管理员） super_read_only = ON

关键点解析：

server-id：必须唯一，这里设为101。
relay-log：中继日志的文件名前缀。SQL线程就是读取这个日志来重放事件的。
read_only和super_read_only：这是保障从库数据纯洁性的重要屏障。设置为ON后，普通用户连接从库只能执行读操作，无法执行INSERT/UPDATE/DELETE。但具有SUPER权限的用户（如复制线程repl）依然可以写。这有效防止了运维或应用的误操作污染从库数据。

同样，配置完成后重启从库MySQL服务。

3.5 从库关联主库并启动复制

首先，如果主库中已有存量数据，我们需要先将这些数据同步到从库，保证起点一致。最常用的方法是使用mysqldump进行逻辑备份并导入。在从库上执行：

# 1. 在主库执行备份（注意排除系统库，并使用--master-data参数记录binlog位置） # 在主库服务器上执行： mysqldump -u root -p --all-databases --master-data=2 --flush-logs --ignore-table=mysql.gtid_executed --ignore-table=mysql.slave_relay_log_info --ignore-table=mysql.slave_master_info --ignore-table=mysql.slave_worker_info > master_dump.sql # 2. 将备份文件传输到从库 scp master_dump.sql root@192.168.1.101:/tmp/ # 3. 在从库服务器上导入数据 mysql -u root -p < /tmp/master_dump.sql

--master-data=2参数会在导出的SQL文件中以注释形式包含CHANGE MASTER TO语句所需的MASTER_LOG_FILE和MASTER_LOG_POS，非常方便。

现在，登录从库MySQL命令行，执行关键的复制配置命令：

-- 停止从库复制线程（如果是首次配置，可能本来就是停止的） STOP SLAVE; -- 配置主库连接信息，使用之前记录的File和Position CHANGE MASTER TO MASTER_HOST='192.168.1.100', MASTER_USER='repl', MASTER_PASSWORD='Repl@123456', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=785, MASTER_CONNECT_RETRY=30; -- 启动从库复制线程 START SLAVE;

命令详解：

MASTER_HOST/PORT/USER/PASSWORD：指向主库的连接信息。
MASTER_LOG_FILE/POS：这就是之前SHOW MASTER STATUS记下的值，告诉从库从哪个点开始同步。如果使用了--master-data备份，这个信息已经包含在备份文件里，可以不用手动填写。
MASTER_CONNECT_RETRY：连接重试间隔（秒），网络不稳定时可适当调大。

4. 状态检查与故障排查实战

配置完成后，不代表万事大吉。我们必须学会如何检查复制状态，并具备基本的排错能力。

4.1 检查复制状态

在从库上执行：

SHOW SLAVE STATUS\G

使用\G代替分号，可以让结果以垂直格式显示，更易读。在输出的大量信息中，我们最需要关注以下两个字段：

Slave_IO_Running：I/O线程状态。必须是Yes，表示正在从主库接收日志。
Slave_SQL_Running：SQL线程状态。必须是Yes，表示正在执行中继日志中的事件。
Seconds_Behind_Master：从库落后于主库的秒数。这是一个估算值。0表示完全同步；NULL通常表示复制线程未运行；一个持续较大的正数则意味着从库延迟严重，需要关注。
Last_IO_Error/Last_SQL_Error：记录最近一次I/O或SQL线程的错误信息。正常运行时应为空。

一个健康的复制状态输出中，Slave_IO_Running和Slave_SQL_Running都应为Yes，且Seconds_Behind_Master为一个较小的、相对稳定的数值（如0或1）。

4.2 常见错误与解决方案实录

在实际运维中，复制中断是家常便饭。下面是我踩过坑后总结的几种典型错误及处理思路。

问题一：Slave_IO_Running: Connecting或Last_IO_Error: error connecting to master ...

这表示从库的I/O线程无法连接到主库。

排查网络：使用ping和telnet master_ip 3306检查从库到主库的网络连通性和端口可达性。
检查账户权限：确认主库上为repl用户设置的host是否正确，密码是否正确。可以在主库上尝试用此账户密码登录验证。
检查防火墙：确保主库服务器的3306端口对从库IP开放。

问题二：Slave_SQL_Running: No且Last_SQL_Error: Could not execute Write_rows event on table db.table; Duplicate entry 'X' for key 'PRIMARY'...

这是经典的1062错误（主键冲突）。通常发生在以下几种情况：

从库曾被写入过数据（比如在read_only未开启时，应用误连从库做了插入）。
主库某条记录被删除后，从库因为某种原因（如slave_skip_errors）跳过了删除事件，之后主库又插入了相同主键的记录。
备份恢复的数据与当前复制位点不匹配。

处理流程（谨慎操作）：

确定数据以谁为准：与业务方确认，冲突的这条记录，应该以主库的为准，还是以从库的为准？绝大多数情况以主库为准。
临时跳过错误（仅用于紧急恢复）：如果确定以主库为准，可以临时跳过这个错误事件，让复制继续。
```
STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; -- 跳过1个事件 START SLAVE;
```
然后再次检查SHOW SLAVE STATUS\G。SQL_SLAVE_SKIP_COUNTER每次设置后会自动减1，直到0。此方法治标不治本，需后续根治。
根治方法：手动在从库上删除或修改那条冲突数据，使其与主库一致，或直接重新搭建复制。如果冲突数据多，重新搭建可能是更干净的选择。

问题三：Slave_SQL_Running: No且Last_SQL_Error: Error executing row event: 'Cannot add or update a child row: a foreign key constraint fails'

外键约束失败。原因可能是从库上依赖的主表数据缺失，或者主从执行顺序不一致导致暂时性的约束违反。

处理思路：

检查从库上相关的外键关联表，数据是否完整。
对于复杂事务，考虑在从库配置文件中设置slave_parallel_type = LOGICAL_CLOCK和slave_parallel_workers > 0来启用多线程复制，但需注意这可能引入依赖问题。更根本的，是审视数据库设计，或确保应用逻辑不会导致此类问题。

问题四：Seconds_Behind_Master延迟持续很高

这是复制延迟，性能问题的集中体现。

硬件瓶颈：检查从库服务器的CPU、内存、磁盘I/O（尤其是Relay Log和Data目录所在磁盘）是否已成为瓶颈。从库硬件规格不应低于主库。

单线程回放：在MySQL 5.6之前，SQL线程是单线程的，主库并发写入高时，从库串行回放必然延迟。解决方案是升级到5.6+并开启并行复制。

# 在从库my.cnf中配置 slave_parallel_type = LOGICAL_CLOCK # 基于组提交的并行方式 slave_parallel_workers = 4 # 设置并行工作线程数，通常设置为CPU核心数

大事务：主库执行一个耗时很长的大事务（如一次性更新百万行），这个事务的binlog事件会在最后才写入。从库的Seconds_Behind_Master会显示为0，直到主库提交，然后瞬间变成一个很大的值。应避免在业务高峰期运行大事务，将其拆分为小批量操作。
长查询：从库上如果有慢查询，会阻塞SQL线程应用后续的日志。优化从库上的查询，或将在从库上执行的统计、报表等重查询移到专门的离线分析库。

5. 实现读写分离：应用层与中间件方案

主从复制搭建好后，读写分离的实现就水到渠成了。关键在于如何让应用程序知道“写操作找主库，读操作找从库”。主要有两种主流方案。

5.1 应用层直连分离（代码实现）

这是最直接、侵入性最强的方案。在应用程序的数据库连接层（如使用JDBC、连接池）进行判断。

实现思路：

配置两个数据源：一个指向主库（写数据源），一个或多个指向从库（读数据源）。
在代码中，根据要执行的SQL是读（SELECT）还是写（INSERT/UPDATE/DELETE），动态选择对应的数据源获取连接。
对于事务内的操作，为了数据一致性，通常会让整个事务内的所有查询都走主库（写数据源）。

以Spring Boot + MyBatis为例的简化方案：

// 1. 配置多数据源 @Configuration public class DataSourceConfig { @Bean(name = "masterDataSource") @ConfigurationProperties(prefix = "spring.datasource.master") public DataSource masterDataSource() { return DataSourceBuilder.create().build(); } @Bean(name = "slaveDataSource") @ConfigurationProperties(prefix = "spring.datasource.slave") public DataSource slaveDataSource() { return DataSourceBuilder.create().build(); } @Bean @Primary public DataSource routingDataSource( @Qualifier("masterDataSource") DataSource master, @Qualifier("slaveDataSource") DataSource slave) { Map<Object, Object> targetDataSources = new HashMap<>(); targetDataSources.put(DataSourceType.MASTER, master); targetDataSources.put(DataSourceType.SLAVE, slave); AbstractRoutingDataSource routingDataSource = new AbstractRoutingDataSource() { @Override protected Object determineCurrentLookupKey() { // 关键：从线程上下文中获取数据源类型 return DataSourceContextHolder.getDataSourceType(); } }; routingDataSource.setDefaultTargetDataSource(master); routingDataSource.setTargetDataSources(targetDataSources); return routingDataSource; } } // 2. 使用AOP或注解拦截方法，设置数据源类型 @Aspect @Component public class DataSourceAspect { @Before("@annotation(readOnly) || execution(* com..service..*.select*(..)) || execution(* com..service..*.get*(..)) || execution(* com..service..*.find*(..))") public void setReadDataSourceType(JoinPoint joinPoint) { // 如果是读方法，切换到从库 DataSourceContextHolder.setDataSourceType(DataSourceType.SLAVE); } @Before("execution(* com..service..*.insert*(..)) || execution(* com..service..*.update*(..)) || execution(* com..service..*.delete*(..)) || execution(* com..service..*.save*(..))") public void setWriteDataSourceType(JoinPoint joinPoint) { // 如果是写方法，切换到主库 DataSourceContextHolder.setDataSourceType(DataSourceType.MASTER); } @After("execution(* com..service..*.*(..))") public void restoreDataSourceType(JoinPoint joinPoint) { // 方法执行完毕后，清空上下文，避免污染 DataSourceContextHolder.clearDataSourceType(); } }

优缺点分析：

优点：实现简单，可控性强，没有额外中间件开销。
缺点：
- 代码侵入性强：需要修改业务代码或增加大量AOP切面。
- 维护困难：数据源配置硬编码在应用中，增减从库需要修改代码并重启。
- 高可用处理复杂：如果某个从库宕机，需要应用层自己实现健康检查和故障转移逻辑。
- 连接池管理复杂：每个应用实例都需要维护多个连接池。

5.2 使用数据库中间件（推荐方案）

这是目前生产环境更主流、更优雅的方案。引入一个独立的代理层（中间件），应用程序像连接单点数据库一样连接这个代理，由代理自动完成SQL解析、路由、结果聚合等复杂工作。

主流中间件对比：

中间件	特点	适用场景
MySQL Router	MySQL官方出品，轻量级，配置简单。主要做读写分离和故障转移。	对功能要求简单，希望与MySQL生态紧密集成的场景。
ProxySQL	功能强大，高性能。支持查询规则、缓存、连接池、故障转移、负载均衡等。社区活跃。	中大型项目，需要精细化的SQL路由、缓存和监控。
MyCat/ShardingSphere	国产优秀中间件。除了读写分离，更核心的功能是分库分表。功能全面，但部署和配置相对复杂。	数据量极大，需要进行水平拆分的分布式数据库场景。

以ProxySQL为例的快速部署：

安装：可以从官网下载RPM包或源码编译安装。

配置：ProxySQL有分层配置系统（内存层 -> 运行时层 -> 磁盘层）。

-- 登录ProxySQL管理界面（默认端口6032） mysql -u admin -padmin -h 127.0.0.1 -P 6032 --prompt='ProxySQL> ' -- 1. 在后端服务器组中添加主从节点 INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, '192.168.1.100', 3306); -- 主库，hostgroup 10 INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (20, '192.168.1.101', 3306); -- 从库，hostgroup 20 -- 2. 配置监控用户，ProxySQL用此用户检查后端MySQL状态 UPDATE global_variables SET variable_value='monitor' WHERE variable_name='mysql-monitor_username'; UPDATE global_variables SET variable_value='monitor_password' WHERE variable_name='mysql-monitor_password'; LOAD MYSQL VARIABLES TO RUNTIME; SAVE MYSQL VARIABLES TO DISK; -- 3. 配置应用访问的用户和路由规则 INSERT INTO mysql_users(username, password, default_hostgroup) VALUES ('app_user', 'app_password', 10); -- 默认路由到主库组(10) -- 定义路由规则：将SELECT语句路由到从库组(20)，其他语句到主库组(10) INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (1, 1, '^SELECT.*FOR UPDATE', 10, 1); -- SELECT FOR UPDATE 是写操作，走主库 INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (2, 1, '^SELECT', 20, 1); -- 普通SELECT走从库 -- 4. 使配置生效 LOAD MYSQL USERS TO RUNTIME; SAVE MYSQL USERS TO DISK; LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK; LOAD MYSQL QUERY RULES TO RUNTIME; SAVE MYSQL QUERY RULES TO DISK;

应用连接：将应用程序的数据库连接地址改为ProxySQL的地址（默认端口6033），用户名密码使用上面配置的app_user。

中间件方案的巨大优势：

对应用透明：应用无需任何修改，像使用单库一样使用。
动态管理：可以随时在ProxySQL管理端增删后端数据库节点，应用无感知。
内置高可用：中间件可以检测后端节点健康状态，自动剔除故障节点，实现故障转移。
高级功能：如查询缓存、流量控制、SQL审计等。

个人体会：对于绝大多数项目，我强烈建议直接使用ProxySQL这类中间件方案。它把数据库集群的复杂度从应用层剥离出来，让开发者更专注于业务逻辑。初期可能觉得配置有点复杂，但一旦跑通，后期的运维扩展会轻松很多。自己手写代码实现读写分离，后期在连接池管理、故障切换、负载均衡策略上会踩无数的坑。

6. 进阶考量与生产环境建议

搭建一个能跑通的主从复制并不难，但要使其稳定、高效地服务于生产环境，还需要考虑更多。

6.1 监控与告警

“没有监控的系统就是在裸奔”。对于主从复制，必须建立完善的监控体系。

监控指标：
- Slave_IO_Running/Slave_SQL_Running状态。
- Seconds_Behind_Master延迟时间。
- Slave_SQL_Running_StateSQL线程当前状态。
- 主从库的Binlog文件大小和增长速率。
- 主从库的服务器资源（CPU、内存、磁盘空间、I/O）。
告警策略：当复制线程状态异常、延迟超过阈值（如30秒）、磁盘空间不足时，应立即通过邮件、短信、钉钉/企业微信机器人等渠道告警。

可以使用 Prometheus + Grafana 搭配mysqld_exporter来采集和展示这些指标，并设置告警规则。

6.2 备份与恢复策略

主从架构为备份提供了极大便利。我们可以在从库上执行耗时很长的物理备份（如Percona XtraBackup），而完全不影响主库的线上服务。

备份从库：在从库上定期执行全量+增量备份。
恢复演练：定期将备份文件恢复到测试环境，验证备份的有效性和恢复流程。这是保证数据安全的生命线。
延迟从库：可以专门配置一个延迟若干小时（如6小时）的从库。当主库发生误操作（如误删表）时，可以从这个延迟从库上找回未错误操作前的数据。

6.3 一主多从与高可用架构

单从库存在单点风险。生产环境通常采用一主多从架构。

负载均衡：多个从库可以更好地分担读压力。通过中间件（如ProxySQL）可以轻松实现读请求在多个从库间的负载均衡。
高可用：当主库宕机时，需要将从库提升（Promote）为新的主库，并让其他从库和应用程序指向新主库。这个过程称为故障切换（Failover）。手动操作风险高、速度慢。可以采用MHA（Master High Availability）、Orchestrator等工具，或使用InnoDB Cluster、Galera Cluster等MySQL原生集群方案来实现自动故障切换。

6.4 数据一致性校验

即使复制状态显示正常，也不能100%保证主从数据完全一致。网络抖动、非事务引擎（如MyISAM）的使用、某些特殊SQL都可能导致数据不一致。需要定期进行数据一致性校验。

工具推荐：pt-table-checksum是 Percona Toolkit 中的神器。它可以在主库上运行，通过计算数据块的校验和，与从库进行比对，找出不一致的数据。
修复不一致：找出不一致后，可以使用pt-table-sync工具来修复从库上的数据，使其与主库同步。注意：这些操作对线上数据库有性能影响，务必在业务低峰期进行，并充分测试。

搭建和维护MySQL主从复制与读写分离，是一个从“能用”到“好用”再到“稳定”的持续过程。它不仅仅是运行几条配置命令，更涉及到网络、服务器、数据库内核、应用架构和运维流程的方方面面。理解其原理，掌握搭建和排错的方法，并善用成熟的中间件和运维工具，才能让这套经典的架构真正为你的业务系统保驾护航。