Java MySQL 数据库中怎么配置主从复制实现读写分离架构-java教程-PHP中文网

java应用不直接配置mysql主从复制，需先完成数据库层主从部署，再通过shardingsphere-jdbc或abstractroutingdatasource实现读写分离，确保写走主库、读走从库，并关注延迟监控、事务一致性、只读控制与故障切换。

java mysql 数据库中怎么配置主从复制实现读写分离架构

Java 应用本身不直接配置 MySQL 主从复制，主从复制是数据库层面的部署任务；读写分离则需要在 Java 应用层或中间件层做路由控制。两者配合才能真正落地“写走主库、读走从库”的架构。

这是读写分离的前提，必须确保主库（Master）和至少一个从库（Slave）之间数据能稳定同步。

主库配置：修改 /etc/my.cnf，启用 binlog 并设唯一 server-id：
[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
expire_logs_days = 7
创建复制用户：
CREATE USER 'repl'@'%' IDENTIFIED BY 'StrongPass2026!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
记录主库位点：
执行 FLUSH TABLES WITH READ LOCK; 后运行 SHOW MASTER STATUS;，记下 File（如 mysql-bin.000003）和 Position（如 154），之后 UNLOCK TABLES;
从库配置：修改 my.cnf，设置不同 server-id，并开启中继日志：
server-id = 2
relay_log = /var/log/mysql/relay-bin.log
read_only = 1（防止误写）
启动复制链路：
CHANGE MASTER TO
  MASTER_HOST='主库IP',
  MASTER_USER='repl',
  MASTER_PASSWORD='StrongPass2026!',
  MASTER_LOG_FILE='mysql-bin.000003',
  MASTER_LOG_POS=154;
START SLAVE;
验证：SHOW SLAVE STATUS\G，确认 Replica_IO_Running 和 Replica_SQL_Running 均为 Yes

主从就绪后，Java 需把写操作发给主库、读操作分发到从库。不推荐手写路由逻辑，优先使用成熟方案。

Java JDK 25

Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。

下载

用 ShardingSphere-JDBC（轻量嵌入式）：
引入 Maven 依赖：
<dependency></dependency>
  <groupid>org.apache.shardingsphere</groupid>
  <artifactid>shardingsphere-jdbc-core-spring-boot-starter</artifactid>
  <version>5.3.2</version>

在 application.yml 中配置数据源与读写分离规则：
spring:
  shardingsphere:
    datasource:
      masterslave:
        master-data-source-name: ds_master
        slave-data-source-names: ds_slave_1,ds_slave_2
      props:
        sql-show: true
用 MyBatis + AbstractRoutingDataSource（手动路由）：
自定义数据源路由类，根据方法名或注解判断读写：
@Override
protected Object determineCurrentLookupKey() {
  if (TransactionSynchronizationManager.isActualTransactionActive()) {
    return "master"; // 有事务走主库
  } else if (method.getName().startsWith("get") || method.getName().startsWith("select")) {
    return "slave"; // 约定读方法走从库
  } else {
    return "master";
  }
}

配置看似简单，但几个细节决定是否真正可用。

主从延迟必须监控：
异步复制天然存在延迟，SHOW SLAVE STATUS 中的 Seconds_Behind_Master 是核心指标；超过阈值时，读请求应自动降级到主库，避免脏读。
事务内读写必须同库：
同一事务中若先写后读，必须全部落在主库，否则可能读不到刚写入的数据。ShardingSphere 和自定义路由都需支持事务上下文感知。
从库只读要真正生效：
仅靠 read_only=1 不够，还需限制应用账号权限，避免从库被意外写入导致主从不一致。
故障切换不能全自动依赖：
主库宕机时，不能仅靠从库提升为主库就完事——需人工校验数据一致性、重置复制关系、更新应用配置。生产环境建议搭配 MHA 或 Orchestrator 等高可用工具。

不要只看配置文件，动手验证最可靠。

在主库执行：INSERT INTO user(name) VALUES('test');
立刻在从库查：SELECT * FROM user WHERE name='test'; —— 若能查到，说明复制通；若查不到，检查 SHOW SLAVE STATUS 错误信息。
在 Java 应用中调用一个 select 方法，打开 MySQL 的 general log 或使用 ShardingSphere 的 sql-show，确认 SQL 发到了从库 IP。
故意停掉从库的 START SLAVE，再执行读操作——应仍能返回结果（因连接池缓存了从库连接），但后续新建连接会失败，借此测试容错逻辑。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南