数据库读写分离与主从同步配置教程

数据库读写分离与主从同步配置教程：从理论到实战的平滑落地

你好，我是源码库的博主。今天我们来深入聊聊一个在业务增长过程中必然会遇到的数据库架构话题：读写分离与主从同步。我记得第一次处理这个问题时，面对线上数据库的CPU和IO压力飙升，单实例已经不堪重负，那种焦头烂额的感觉至今记忆犹新。通过实践，我发现这套方案不仅是提升性能的利器，更是构建高可用架构的基石。下面，我将结合自己的踩坑经验，带你一步步完成MySQL主从同步与读写分离的配置。

一、核心概念与架构设计

在动手之前，我们先理清思路。所谓“主从同步”，就是让一个主数据库（Master）的数据，自动复制到一个或多个从数据库（Slave）上。“读写分离”则是应用层面的策略：让所有写入操作（INSERT、UPDATE、DELETE）都指向主库，而将大部分的读操作（SELECT）分摊到各个从库上。

实战价值：这不仅能极大减轻主库的压力，提升整体吞吐量，还能利用从库做数据备份、报表查询等离线操作，避免影响线上业务。更重要的是，当主库故障时，可以快速切换到从库，实现高可用。

踩坑提示：主从同步有延迟！这是最核心的问题。在“写后立即读”的场景（如用户注册后立即查看个人资料），如果读请求被分发到从库，而此时数据还未同步过来，用户就会看到“数据不存在”。业务设计时必须考虑这一点。

二、环境准备与主库配置

假设我们有两台服务器：192.168.1.10（主库）和192.168.1.11（从库）。确保网络互通，MySQL版本最好一致（这里以MySQL 8.0为例）。

第一步：配置主库（Master）

1. 编辑主库的MySQL配置文件，通常是 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf，在 [mysqld] 段落下增加：

server-id = 1           # 唯一ID，主从不能相同
log_bin = mysql-bin     # 开启二进制日志，这是同步的根源
binlog_format = ROW     # 推荐使用ROW格式，同步更安全
binlog-do-db = myapp_db # 指定要同步的数据库（可选，不配置则同步所有库）

2. 重启MySQL服务使配置生效：

sudo systemctl restart mysqld

3. 登录主库MySQL，创建用于复制的专用账号，并授权：

CREATE USER 'repl'@'192.168.1.11' IDENTIFIED BY 'StrongPassword123!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.11';
FLUSH PRIVILEGES;

4. 关键一步：查看主库当前的状态，记录下File和Position的值，从库配置时会用到。

SHOW MASTER STATUS;

你会看到类似下面的输出，务必记下来：

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

三、从库配置与同步启动

第二步：配置从库（Slave）

1. 编辑从库的MySQL配置文件，修改server-id：

server-id = 2 # 必须与主库不同
# 可选：开启从库的二进制日志，方便它再作为其他从库的主库
relay-log = mysql-relay-bin
read_only = 1 # 设置从库为只读，防止误操作（对超级用户无效）

2. 重启从库MySQL服务。

3. 登录从库MySQL，执行以下命令，配置主库连接信息：

CHANGE MASTER TO
MASTER_HOST='192.168.1.10',
MASTER_USER='repl',
MASTER_PASSWORD='StrongPassword123!',
MASTER_LOG_FILE='mysql-bin.000003', -- 替换为刚才记录的File
MASTER_LOG_POS=785; -- 替换为刚才记录的Position

4. 启动从库复制线程：

START SLAVE;

5. 检查从库同步状态，这是验证是否成功的关键：

SHOW SLAVE STATUSG

请重点关注这两列：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
只有两者都为Yes，才表示同步线程正常运行。如果出现No或Connecting，请检查Last_IO_Error或Last_SQL_Error字段的错误信息。

踩坑提示：常见错误包括网络不通、主从账号密码错误、防火墙端口（3306）未开放、主库记录的File和Position已经失效（如果主库在配置从库期间有写操作）。如果数据已失效，需要对从库进行全量数据导入后再重新配置同步点。

四、应用层实现读写分离

主从数据同步通了，接下来就是让我们的应用“知道”该往哪里写、从哪里读。这里介绍两种主流方式。

方式一：使用中间件（推荐，对应用透明）

像MyCat、ShardingSphere-Proxy、ProxySQL这类数据库中间件，可以屏蔽后端数据库的复杂性。应用像连接单库一样连接中间件，由中间件自动解析SQL，将写请求转发给主库，读请求负载均衡到从库。

以简单配置为例（伪代码概念）：

# 中间件配置片段
dataSources:
  master: jdbc:mysql://192.168.1.10:3306/myapp_db
  slave1: jdbc:mysql://192.168.1.11:3306/myapp_db
rules:
  - !READWRITE_SPLITTING
    dataSources:
      writeDataSourceName: master
      readDataSourceNames:
        - slave1

方式二：在应用代码中抽象数据源（更灵活，但需编码）

在Spring Boot等框架中，我们可以配置多个数据源，并通过AOP或注解（如@Transactional(readOnly = true)）来动态决定使用哪个数据源。

一个简化的Java配置示例：

@Configuration
public class DataSourceConfig {

    @Bean
    @ConfigurationProperties("spring.datasource.master")
    public DataSource masterDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean
    @ConfigurationProperties("spring.datasource.slave")
    public DataSource slaveDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean
    public DataSource routingDataSource(@Qualifier("masterDataSource") DataSource master,
                                        @Qualifier("slaveDataSource") DataSource slave) {
        Map