MySQL主从复制与读写分离深度解析及实战

基于二进制日志文件位置的复制：传统复制方式，通过指定主库二进制日志文件名和偏移量实现同步。这种方式配置灵活，但在主从切换时需要手动定位日志位置，运维成本较高。
基于全局事务标识符（GTID）的复制：通过全局唯一的事务ID标识每个事务，无需手动指定日志文件和位置，极大简化了主从配置和故障切换流程。GTID复制能保证主从数据的一致性，只要主库提交的事务都能在从库应用。

2. MySQL主从复制的工作过程

主从复制的核心流程可分为三个阶段，涉及主库的二进制日志生成、日志传输和从库的日志重放三个关键环节，具体步骤如下：

主库日志生成阶段：当主库执行写操作（INSERT/UPDATE/DELETE）时，会先将事务记录到二进制日志（binlog）中，这是复制的数据源。二进制日志会按事务提交顺序记录，确保日志的完整性和一致性。
日志传输阶段：从库启动后，会创建一个I/O线程连接主库，向主库请求二进制日志。主库会创建一个Binlog Dump线程，将二进制日志内容实时推送给从库的I/O线程。从库I/O线程接收日志后，会将其写入本地的中继日志（Relay Log）。
从库日志重放阶段：从库的SQL线程会实时读取中继日志中的内容，解析为具体的SQL语句并执行，从而实现与主库数据的同步。中继日志的作用是解耦日志接收和执行过程，避免因执行慢查询导致日志接收阻塞。

核心注意点：I/O线程仅负责日志接收，SQL线程负责日志执行，两者独立运行。主库的Binlog Dump线程会根据从库的请求进度推送日志，不会影响主库的正常业务操作。

2.1 MySQL主从复制延迟

主从延迟是指主库执行完事务后，到从库完全同步该事务的时间差，是主从架构中常见的问题。其主要成因及优化方案如下：

常见成因

网络延迟：主从服务器之间的网络带宽不足或不稳定，导致日志传输受阻。
从库性能瓶颈：从库CPU、内存不足或磁盘IO性能差，无法及时执行中继日志中的SQL语句。
大事务或高并发写入：一次性执行大量数据更新（如批量插入10万条数据）会导致二进制日志过大，从库重放耗时增加；高并发写入会使主库日志生成速度超过从库执行速度。
慢查询：从库存在未优化的慢查询，导致SQL线程执行受阻。

优化方案

硬件升级：为从库配置多核CPU、高主频内存和SSD磁盘，提升IO和计算性能。
启用并行复制 ：MySQL 5.7+支持基于逻辑时钟的并行复制，通过设置slave_parallel_workers = 8（根据CPU核心数调整）和slave_parallel_type = 'LOGICAL_CLOCK'，让从库多线程并行执行事务，提升重放效率。
事务拆分：将大事务拆分为多个小事务，避免单次日志过大导致的重放延迟。
复制过滤 ：通过binlog-ignore-db或replicate-wild-do-table配置，忽略无需同步的系统库（如mysql、sys）或非核心业务库，减少同步数据量。
监控告警 ：通过SHOW SLAVE STATUS\G查看Seconds_Behind_Master指标，当延迟超过阈值（如30秒）时触发告警，及时排查问题。

3. MySQL的同步方式

根据主库等待从库确认的机制不同，MySQL提供四种同步方式，分别在数据一致性和性能之间取得不同平衡：

3.1 异步复制（Async Replication）

异步复制是MySQL默认的复制方式，其核心特点是"主库提交事务后无需等待从库确认"。具体流程为：主库执行事务→写入二进制日志→立即向客户端返回成功→异步将日志推送给从库。

优势：主库性能最优，无需等待从库响应，写入延迟极低。劣势：数据一致性最差，若主库崩溃，未传输到从库的事务会丢失。适用场景：对数据一致性要求不高的场景，如日志存储、非核心业务数据存储。

3.2 同步复制（Sync Replication）

同步复制要求"主库提交事务前，必须等待所有从库都执行完该事务并确认"。只有当所有从库返回执行成功后，主库才向客户端返回事务提交成功。

优势：数据一致性最强，主从数据实时一致，无数据丢失风险。劣势：性能极差，主库写入速度完全依赖从库执行速度，任一从库故障都会导致主库阻塞。适用场景：金融核心交易等对数据一致性要求极高的场景，实际生产中极少使用纯同步复制，多采用集群方案实现。

3.3 半同步复制（Semi-Sync Replication）

半同步复制是异步复制和同步复制的折中方案，需通过插件（semisync_master和semisync_slave）启用。其核心机制是：主库提交事务后，会等待至少一个从库确认"已接收并写入中继日志"，然后再向客户端返回成功；若超过指定时间（默认10秒）未收到确认，则降级为异步复制。

优势：兼顾数据一致性和性能，确保主库崩溃时至少有一个从库拥有完整数据，无数据丢失风险。劣势：相比异步复制，主库写入延迟略有增加（取决于网络和从库响应速度）。适用场景：绝大多数业务场景，如电商订单、用户中心等核心业务。

3.4 增强半同步复制（Lossless Semi-Sync Replication、无损复制）

增强半同步复制是MySQL 5.7.2及以上版本对传统半同步的优化，核心改进是"主库在事务提交前等待从库确认"。具体流程为：主库执行事务→写入二进制日志→等待至少一个从库确认接收日志→主库提交事务并向客户端返回成功。

优势：彻底避免数据丢失，因为主库提交前已确保日志已传输到从库，即使主库崩溃也不会丢失事务。相比传统半同步，一致性更优；相比同步复制，性能损耗更小。适用场景：对数据一致性要求高且需兼顾性能的场景，如支付系统、金融对账系统。

4. MySQL主从复制的应用场景

负载均衡：通过读写分离将读请求分发到从库，主库专注于写操作，提升整体并发处理能力。例如电商平台的商品详情查询、订单历史查询等读密集型操作可分流到从库。
数据备份：从库实时同步主库数据，可作为数据备份节点，避免因主库故障导致的数据丢失。同时可在从库执行备份操作，不影响主库性能。
高可用架构：通过主从复制搭建故障转移架构，当主库故障时，可快速将从库切换为主库，减少业务中断时间。
数据分析分流：将报表统计、数据分析等耗资源的读操作部署在从库，避免占用主库资源影响核心业务。
异地容灾：将从库部署在异地机房，通过主从复制实现数据异地同步，当本地机房故障时，可通过异地从库恢复业务。

二、主从复制实验

本实验基于CentOS 7.9虚拟机环境，搭建"一主两从"的MySQL主从架构，使用MySQL 5.7版本，采用基于二进制日志位置的复制方式（兼容低版本环境）。

1. 实验环境及服务器信息

服务器角色	IP地址	操作系统	MySQL版本	核心配置
Master（主库）	192.168.10.16	CentOS 7.9	5.7	开启binlog，server_id=1
Slave1（从库1）	192.168.10.14	CentOS 7.9	5.7	server_id=2，配置主库同步信息
Slave2（从库2）	192.168.10.15	CentOS 7.9	5.7	server_id=3，配置主库同步信息

前置条件：三台服务器已完成MySQL 5.7手工编译安装（步骤忽略），并关闭防火墙（systemctl stop firewalld && systemctl disable firewalld）和SELinux（setenforce 0 && sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config），避免端口拦截。

2. 主从服务器时间同步

主从服务器时间不一致会导致二进制日志时间戳混乱，影响复制准确性，需通过NTP服务实现时间同步。本实验以Master作为NTP服务器，Slave同步Master时间。

2.1 Master服务器配置（NTP服务端）

安装NTP服务

bash 复制代码

yum install -y ntp

配置NTP服务器时间同步

apache 复制代码

# 默认上游时间服务器
server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst

# 允许192.168.10.0网段同步本地时间
restrict 192.168.10.0 mask 255.255.255.0 nomodify notrap

# 本地时间作为备用同步源（无网络时生效）
server 127.127.1.0
fudge 127.127.1.0 stratum 10

启动NTP服务并设置开机自启

bash 复制代码

systemctl start ntpd && systemctl enable ntpd

2.2 两台Slave服务器配置（NTP客户端）

安装NTP客户端工具

bash 复制代码

yum install -y ntpdate

立即同步Master时间

bash 复制代码

# /etc/chrony.conf 中添加
server 192.168.10.16 iburst

以下是实现将NTP同步定时任务写入root用户crontab的完整代码：

写入定时任务到root用户的crontab

bash 复制代码

echo "0 * * * * /usr/sbin/ntpdate 192.168.10.16 > /var/log/ntpdate.log 2>&1" >> /var/spool/cron/root

设置crontab文件权限

bash 复制代码

chmod 600 /var/spool/cron/root

重启crond服务

bash 复制代码

systemctl restart crond

验证定时任务

bash 复制代码

crontab -l

该代码实现了每小时执行NTP时间同步，将输出日志记录到/var/log/ntpdate.log，并通过权限设置确保安全性。最后通过crontab -l命令可验证任务是否添加成功。

3. 配置主从同步

3.1 Master服务器配置

修改MySQL配置文件/etc/my.cnf，开启二进制日志并配置复制核心参数（配置后需重启MySQL）：

配置 MySQL 主从复制的 `[mysqld]` 参数

ini 复制代码

[mysqld]
# 开启二进制日志（复制的核心数据源）
log-bin = mysql-bin

# 二进制日志格式（ROW格式仅记录数据变更，复制更稳定）
binlog-format = ROW

# 主库唯一标识（1-2^32-1，需与从库不同）
server_id = 1

# 自增步长和偏移量（一主两从场景，避免主从切换主键冲突）
auto-increment-increment = 3
auto-increment-offset = 1

# 忽略无需同步的系统库（减少同步数据量）
binlog-ignore-db = mysql
binlog-ignore-db = information_schema
binlog-ignore-db = performance_schema
binlog-ignore-db = sys

# 二进制日志校验（防止日志损坏）
binlog-checksum = CRC32

# 强制事务提交时刷新日志到磁盘（确保主库崩溃不丢日志）
sync-binlog = 1

关键参数说明

log-bin

启用二进制日志功能，指定日志文件前缀（如 mysql-bin.000001）。主库必须开启此功能才能支持复制。

binlog-format=ROW

ROW 格式记录行级别的数据变更，相比 STATEMENT 格式更精确，避免因函数或触发器导致的主从不一致。

server_id

唯一标识服务器，主从库必须不同。范围 1 到 4294967295。

auto-increment-increment/offset

在一主多从架构中，设置自增步长为从库数量（如 3），主库偏移量为 1，从库依次为 2、3，避免主键冲突。

binlog-ignore-db

排除系统库的同步，减少网络传输和存储开销。

sync-binlog=1

每次事务提交后立即刷新日志到磁盘，确保数据安全性，但可能影响性能。

重启MySQL服务使配置生效

bash 复制代码

systemctl restart mysqld && systemctl enable mysqld

登录MySQL创建从库复制专用账号并授权（遵循最小权限原则）

MySQL主从复制配置代码

sql 复制代码

-- 登录MySQL
mysql -uroot -p123456

-- 创建复制专用账号（仅允许192.168.10.0网段访问）
CREATE USER 'slave'@'192.168.10.%' IDENTIFIED BY 'Slave@123';

-- 授予复制权限（仅REPLICATION SLAVE权限即可满足需求）
GRANT REPLICATION SLAVE ON *.* TO 'slave'@'192.168.10.%';

-- 刷新权限使配置生效
FLUSH PRIVILEGES;

-- 查看主库二进制日志状态（记录File和Position值，从库配置需用到）
SHOW MASTER STATUS;

执行结果示例

复制代码

+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      154 |              | mysql,sys        |                   |
+------------------+----------+--------------+------------------+-------------------+

数据备份说明

若主库已有业务数据，需执行以下操作确保数据一致性：

bash 复制代码

mysqldump -uroot -p123456 --all-databases --lock-all-tables > master_backup.sql

关键配置项

必须记录SHOW MASTER STATUS输出的File和Position值
从库配置时需要用到主库的二进制日志位置信息
备份时--lock-all-tables参数确保备份期间数据一致性

3.2 从服务器配置（Slave1和Slave2配置相同）

修改MySQL配置文件/etc/my.cnf，配置从库核心参数（Slave1的server_id=2，Slave2的server_id=3）

ini 复制代码

[mysqld]
# 从库唯一标识（需与主库、其他从库不同）
server_id = 2

# 开启中继日志（存储主库同步的二进制日志）
relay-log = mysql-relay-bin

# 中继日志重放后自动删除（节省磁盘空间）
relay-log-purge = 1

# 忽略无需同步的系统库（与主库保持一致）
replicate-ignore-db = mysql
replicate-ignore-db = information_schema
replicate-ignore-db = performance_schema
replicate-ignore-db = sys

# 启用并行复制（MySQL 5.7+特性，提升同步效率）
slave_parallel_type = 'LOGICAL_CLOCK'
slave_parallel_workers = 4

# 从库只读模式（禁止普通用户写操作，保护数据一致性）
read_only = 1

重启MySQL服务

bash 复制代码

systemctl restart mysqld && systemctl enable mysqld

登录MySQL配置主从复制参数并启动复制进程

routeros 复制代码

-- 登录MySQL
mysql -uroot -p123456

-- 停止现有复制进程（若之前配置过）
STOP SLAVE;

-- 重置复制配置（清除历史同步信息）
RESET SLAVE;

-- 配置主库信息（替换为实际的主库IP、账号密码、日志文件和位置）
CHANGE MASTER TO
MASTER_HOST='192.168.10.16',
MASTER_USER='slave',
MASTER_PASSWORD='Slave@123',
MASTER_LOG_FILE='mysql-bin.000001', -- 主库SHOW MASTER STATUS的File值
MASTER_LOG_POS=154, -- 主库SHOW MASTER STATUS的Position值
MASTER_PORT=3306,
MASTER_CONNECT_RETRY=30; -- 连接失败重试间隔（秒）

-- 启动复制进程
START SLAVE;

-- 查看复制状态（核心关注Slave_IO_Running和Slave_SQL_Running是否为Yes）
SHOW SLAVE STATUS\G;

正常状态关键参数示例

yaml 复制代码

Slave_IO_Running: Yes -- I/O线程正常（成功接收主库日志）
Slave_SQL_Running: Yes -- SQL线程正常（成功重放日志）
Seconds_Behind_Master: 0 -- 主从延迟为0（同步正常）

4. 测试数据同步

通过在主库执行写操作，验证从库是否能实时同步数据：

在Master主库执行写操作（创建测试数据）

sql 复制代码

-- 登录主库
mysql -uroot -p123456 -h192.168.10.16

-- 创建测试库
CREATE DATABASE IF NOT EXISTS test_db;
USE test_db;

-- 创建含自增主键的测试表
CREATE TABLE IF NOT EXISTS user_info (
  id INT PRIMARY KEY AUTO_INCREMENT,
  username VARCHAR(50) NOT NULL COMMENT '用户名',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间'
) COMMENT '用户信息测试表';

-- 插入测试数据
INSERT INTO user_info (username) VALUES 
  ('test_user1'), 
  ('test_user2');

在Slave1和Slave2查询数据，验证同步结果

查询主从同步状态的MySQL命令示例

Slave1查询命令：

bash 复制代码

mysql -uroot -p123456 -h192.168.10.14 -e "USE test_db; SELECT * FROM user_info;"

Slave2查询命令：

bash 复制代码

mysql -uroot -p123456 -h192.168.10.15 -e "USE test_db; SELECT * FROM user_info;"

预期同步成功的查询结果示例

sql 复制代码

+----+------------+---------------------+
| id | username   | create_time         |
+----+------------+---------------------+
| 1  | test_user1 | 2025-12-04 10:00:00 |
| 4  | test_user2 | 2025-12-04 10:00:00 |
+----+------------+---------------------+

主键自增配置说明

该示例中id呈现1和4的间隔是因为主库配置了：

ini 复制代码

auto-increment-increment=3
auto-increment-offset=1

这种配置确保在MySQL主从架构中，主库和从库生成的主键不会冲突，便于主从切换时的数据一致性维护。

三、MySQL读写分离

主从复制解决了数据同步问题，而读写分离则通过将读请求和写请求分发到不同的服务器，实现负载均衡，提升系统并发处理能力。

1. 什么是读写分离？

读写分离是一种数据库架构优化方案，核心思想是"写操作集中在主库，读操作分散到从库"。通过中间件或程序代码控制，将INSERT、UPDATE、DELETE等写操作路由到主库，将SELECT读操作路由到一个或多个从库，从而避免单库的读写冲突和性能瓶颈。

2. 为什么要读写分离呢？

读写分离的核心价值在于解决高并发场景下的性能瓶颈，具体优势如下：

提升并发处理能力：将读请求分流到多个从库，突破单库的连接数和CPU瓶颈。例如，主库处理写请求，3个从库处理读请求，整体并发能力可提升3-4倍。
优化主库性能：主库无需承担读压力，可专注于写操作，减少锁竞争和IO开销，提升写操作响应速度。
提高系统可用性：单个从库故障不会影响写操作和其他从库的读操作，通过故障转移可快速恢复服务。
灵活扩展读能力：当读压力增加时，可通过增加从库数量横向扩容，无需修改核心业务代码。

3. 什么时候要读写分离？

读写分离并非适用于所有场景，以下情况是引入读写分离的最佳时机：

读多写少场景：读请求QPS远高于写请求（如读:写=10:1及以上），例如电商商品详情页、新闻资讯、博客等场景。
单库性能瓶颈：单库的CPU利用率超过80%，或读请求响应时间明显增加（如超过200ms），且通过索引优化、SQL优化等手段无法有效提升性能。
高并发业务：系统整体并发QPS超过500，单库无法支撑，需要通过多库分流实现扩容。
数据备份与分析需求：需要在不影响主库性能的前提下，进行数据备份、报表统计或数据分析。

4. 主从复制与读写分离的关系

主从复制是读写分离的基础，读写分离是主从复制的核心应用，两者相辅相成：

没有主从复制，读写分离无法实现数据一致性------从库数据无法同步主库的写操作，会导致读请求获取旧数据。
仅做主从复制不做读写分离，无法发挥多库的性能优势------主库仍需承担所有读写压力，从库仅作为备份节点，资源利用率低。

理想架构：主从复制保证数据一致性，读写分离实现负载均衡，共同构建高可用、高并发的数据库架构。

5. MySQL读写分离原理

读写分离的核心是"请求路由"，即通过特定规则将不同类型的SQL请求分发到对应的数据库节点，具体流程如下：

请求接收：客户端发送SQL请求到中间件或应用程序。
SQL解析：中间件或应用程序解析SQL语句，判断请求类型（读/写）。通常通过关键字判断：包含INSERT、UPDATE、DELETE、ALTER等为写请求；包含SELECT为读请求（特殊场景如SELECT ... FOR UPDATE需路由到主库）。
请求分发：写请求：路由到主库（Master）执行。
读请求：路由到从库（Slave）执行，可通过轮询、加权轮询、哈希等算法实现负载均衡。
结果返回：数据库执行完成后，将结果通过中间件或应用程序返回给客户端。

6. 企业使用MySQL读写分离的场景

企业中实现读写分离主要有两种方案，分别适用于不同的技术架构和团队规模：

6.1 基于程序代码内部实现

在应用程序代码中嵌入读写分离逻辑，通过配置多个数据源（主库数据源、从库数据源），在DAO层或ORM框架中实现请求路由。例如，使用Spring Boot + MyBatis时，可通过自定义数据源路由实现读写分离。

优势：架构简单，无额外中间件开销，响应速度快；可根据业务需求定制路由规则（如特定表的读请求路由到指定从库）。劣势：代码侵入性强，读写分离逻辑与业务代码耦合；多语言架构下需重复开发路由逻辑；从库扩容或故障转移时需修改代码配置。

适用场景：小型团队、单一语言架构（如纯Java架构）、业务逻辑简单的场景。

6.2 基于中间代理层实现

在客户端和数据库之间部署中间代理层，由代理层统一接收请求并完成路由。主流的中间件包括Amoeba、MyCat、ProxySQL、MaxScale等。本实验将采用Amoeba实现读写分离，其轻量、易配置的特点适合中小规模架构。

优势：无代码侵入，业务代码无需修改；支持多语言客户端；集中管理数据源，扩容或故障转移时仅需修改代理层配置；支持更复杂的路由规则（如分库分表、读写分离结合）。劣势：引入中间件增加系统复杂度；代理层可能成为性能瓶颈（需集群部署规避）。

适用场景：中大型团队、多语言架构、业务逻辑复杂且需要灵活扩展的场景（如电商、金融、社交平台）。

四、读写分离实验

本实验基于"一主两从"的主从复制环境，通过Amoeba中间件实现读写分离。Amoeba是阿里开源的轻量级数据库代理工具，专注于读写分离和负载均衡，支持MySQL、Oracle等数据库。

1. 实验环境及服务器信息

服务器角色	IP地址	操作系统	核心软件	核心作用
Master（主库）	192.168.10.16	CentOS 7.6	MySQL 5.7	处理所有写请求，同步数据至从库
Slave1（从库1）	192.168.10.14	CentOS 7.6	MySQL 5.7	处理读请求，同步主库数据
Slave2（从库2）	192.168.10.15	CentOS 7.6	MySQL 5.7	处理读请求，同步主库数据
Amoeba服务器	192.168.10.80	CentOS 7.6	JDK 1.6、Amoeba 2.2.0	接收客户端请求，实现读写分离路由
客户端服务器	192.168.10.13	CentOS 7.6	MySQL客户端	模拟业务请求，测试读写分离效果

前置条件：已完成"一主两从"主从复制环境搭建，确保主从数据同步正常；所有服务器已关闭防火墙和SELinux。

2. 搭建MySQL读写分离

读写分离搭建的核心是配置Amoeba服务器，实现请求路由规则。Amoeba依赖Java环境，需先安装JDK 1.6（Amoeba 2.2.0兼容JDK 1.5/1.6，JDK 1.8可能存在兼容性问题）。

2.1 Amoeba服务器配置

步骤1：安装JDK 1.6

上传JDK安装包（jdk-6u14-linux-x64.bin）到/usr/local目录，添加执行权限并安装：
bash 复制代码
```
cd /usr/local
chmod +x jdk-6u14-linux-x64.bin
./jdk-6u14-linux-x64.bin
mv jdk1.6.0_14 /usr/local/jdk1.6
 
```

配置Java环境变量，编辑/etc/profile文件，添加以下内容：

bash 复制代码

export JAVA_HOME=/usr/local/jdk1.6
export CLASSPATH=$CLASSPATH:$JAVA_HOME/lib:$JAVA_HOME/jre/lib
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH

使环境变量生效并验证：

bash 复制代码

source /etc/profile
java -version 2>&1 | grep "1.6.0_14" > /dev/null
if [ $? -eq 0 ]; then
    echo "JDK 1.6.0_14 installation successful"
else
    echo "JDK 1.6.0_14 not found"
fi

步骤2：安装Amoeba 2.2.0

上传Amoeba压缩包（amoeba-mysql-binary-2.2.0.tar.gz）到/opt目录，解压到指定目录并修改权限：
bash 复制代码
```
mkdir /usr/local/amoeba
tar zxvf /opt/amoeba-mysql-binary-2.2.0.tar.gz -C /usr/local/amoeba/
chmod -R 755 /usr/local/amoeba/
 
```
配置Amoeba环境变量，编辑/etc/profile文件，添加以下内容：
routeros 复制代码
```
export AMOEBA_HOME=/usr/local/amoeba
export PATH=$PATH:$AMOEBA_HOME/bin
 
```
使环境变量生效并验证Amoeba安装：
bash 复制代码
```
source /etc/profile
amoeba
 
```
text 复制代码
```
Usage: amoeba {start|stop}
 
```

步骤3：授权Amoeba访问MySQL主从库

在Master、Slave1、Slave2上执行以下SQL，创建Amoeba访问MySQL的专用账号并授权（确保Amoeba服务器能通过该账号访问所有数据库节点）：

以下是实现创建Amoeba用户并授权指定IP访问的MySQL代码片段：

创建用户并授权

sql 复制代码

-- 创建amoeba用户，允许192.168.10.80（Amoeba服务器IP）访问
CREATE USER 'amoeba'@'192.168.10.80' IDENTIFIED BY 'Amoeba@123';

-- 授予所有库表的操作权限（生产环境可根据需求细化权限）
GRANT ALL PRIVILEGES ON *.* TO 'amoeba'@'192.168.10.80';

-- 刷新权限使设置立即生效
FLUSH PRIVILEGES;

安全建议

生产环境中建议根据最小权限原则细化授权范围，例如仅授权特定数据库：

sql 复制代码

GRANT ALL PRIVILEGES ON `target_db`.* TO 'amoeba'@'192.168.10.80';

验证配置

可通过以下命令检查用户权限：

sql 复制代码

SHOW GRANTS FOR 'amoeba'@'192.168.10.80';

步骤4：配置Amoeba核心文件

Amoeba的核心配置文件为/usr/local/amoeba/conf/amoeba.xml（主配置文件）和/usr/local/amoeba/conf/dbServers.xml（数据库服务器配置文件）。

配置dbServers.xml（数据库服务器信息）：

xml 复制代码

<?xml version="1.0" encoding="gbk"?>
<!DOCTYPE amoeba:dbServers SYSTEM "dbserver.dtd">
<amoeba:dbServers xmlns:amoeba="http://amoeba.meidusa.com/">

<!-- 全局默认配置，可被具体数据库配置覆盖 -->
<dbServer name="abstractServer" abstractive="true">
    <factoryConfig class="com.meidusa.amoeba.mysql.net.MysqlServerConnectionFactory">
        <property name="connectionManager">$connectionManager</property>
        <property name="sendBufferSize">64</property>
        <property name="receiveBufferSize">64</property>
        <property name="user">amoeba</property>
        <property name="password">Amoeba@123</property>
    </factoryConfig>
    <poolConfig class="com.meidusa.amoeba.net.poolable.PoolableObjectPool">
        <property name="maxActive">500</property>
        <property name="maxIdle">500</property>
        <property name="minIdle">10</property>
        <property name="minEvictableIdleTimeMillis">600000</property>
        <property name="timeBetweenEvictionRunsMillis">300000</property>
        <property name="testOnBorrow">true</property>
        <property name="testOnReturn">true</property>
        <property name="testWhileIdle">true</property>
    </poolConfig>
</dbServer>

<!-- 主库配置（name为master，与amoeba.xml对应） -->
<dbServer name="master" parent="abstractServer">
    <factoryConfig>
        <property name="ipAddress">192.168.10.16</property>
        <property name="port">3306</property>
        <property name="schema">mysql</property>
    </factoryConfig>
</dbServer>

<!-- 从库1配置（name为slave1） -->
<dbServer name="slave1" parent="abstractServer">
    <factoryConfig>
        <property name="ipAddress">192.168.10.14</property>
        <property name="port">3306</property>
        <property name="schema">mysql</property>
    </factoryConfig>
</dbServer>

<!-- 从库2配置（name为slave2） -->
<dbServer name="slave2" parent="abstractServer">
    <factoryConfig>
        <property name="ipAddress">192.168.10.15</property>
        <property name="port">3306</property>
        <property name="schema">mysql</property>
    </factoryConfig>
</dbServer>

<!-- 从库池配置（轮询负载均衡） -->
<dbServer name="slaves" virtual="true">
    <poolConfig class="com.meidusa.amoeba.server.MultipleServerPool">
        <property name="loadbalance">1</property>
        <property name="poolNames">slave1,slave2</property>
    </poolConfig>
</dbServer>
</amoeba:dbServers>

配置amoeba.xml（主配置文件，路由规则）：

xml 复制代码

<?xml version="1.0" encoding="gbk"?>
<!DOCTYPE amoeba:configuration SYSTEM "amoeba.dtd">
<amoeba:configuration xmlns:amoeba="http://amoeba.meidusa.com/">
  <proxy>
    <port>8066</port>
    <ipAddress>0.0.0.0</ipAddress>
    
    <threadPool>
      <property name="corePoolSize">10</property>
      <property name="maximumPoolSize">100</property>
      <property name="keepAliveTime">120000</property>
    </threadPool>

    <connectionManagerList>
      <connectionManager name="defaultManager" class="com.meidusa.amoeba.net.MultiConnectionManagerWrapper">
        <property name="maxConnections">1000</property>
        <property name="readTimeout">600000</property>
      </connectionManager>
    </connectionManagerList>

    <authentication>
      <property name="user">amoeba_client</property>
      <property name="password">Client@123</property>
      <property name="filter">com.meidusa.amoeba.mysql.server.MysqlAuthenticationFilter</property>
    </authentication>

    <queryRouter class="com.meidusa.amoeba.mysql.parser.MysqlQueryRouter">
      <property name="ruleLoader">
        <bean class="com.meidusa.amoeba.route.TableRuleFileLoader">
          <property name="ruleFile">${amoeba.home}/conf/rule.xml</property>
          <property name="functionFile">${amoeba.home}/conf/ruleFunctionMap.xml</property>
        </bean>
      </property>
      <property name="sqlFunctionFile">${amoeba.home}/conf/functionMap.xml</property>
      <property name="LRUMapSize">1500</property>
      <property name="defaultPool">master</property>
      <property name="writePool">master</property>
      <property name="readPool">slaves</property>
      <property name="needParse">true</property>
    </queryRouter>
  </proxy>

  <logger>
    <property name="logImpl">com.meidusa.amoeba.log.stdout.StdoutLoggerFactory</property>
    <property name="level">INFO</property>
  </logger>
</amoeba:configuration>

步骤5：启动Amoeba服务

以下是根据需求生成的代码片段和操作说明，用于启动Amoeba服务并验证其状态：

启动Amoeba服务

bash 复制代码

cd /usr/local/amoeba/bin
./amoeba start &  # 后台启动Amoeba

验证服务状态

bash 复制代码

netstat -antp | grep 8066  # 检查8066端口监听状态

预期输出示例

成功启动时会显示类似以下信息：

复制代码

tcp6    0    0 :::8066    :::*    LISTEN    12345/java

注意事项

确保执行脚本前具有/usr/local/amoeba/bin目录的操作权限
若端口未监听，可检查logs/目录下的错误日志
停止服务可使用./amoeba stop命令

2.2 测试读写分离

测试核心目标：验证写请求路由至主库、读请求分发至从库，且主从数据同步正常。通过客户端服务器连接Amoeba代理，执行读写操作进行验证。

步骤1：客户端连接Amoeba代理

在客户端服务器（192.168.10.13）安装MySQL客户端，使用amoeba.xml配置的客户端账号密码连接Amoeba（默认端口8066）：

bash 复制代码

yum install -y mysql

bash 复制代码

mysql -uamoeba_client -pClient@123 -h192.168.10.80 -P8066

出现MySQL命令行提示符，说明客户端与Amoeba连接成功。

步骤2：验证写请求路由（仅主库执行）

通过"写操作后即时查询从库"验证写请求仅路由至主库（从库开启只读模式，普通用户无法写操作）：

客户端连接Amoeba后执行写操作（插入数据）：

sql 复制代码

-- 切换至测试库
USE test_db;

-- 插入测试数据
INSERT INTO user_info (username) VALUES ('rw_test_write');

立即登录Slave1（192.168.10.14）查询数据：

sql 复制代码

#!/bin/bash

MAX_RETRIES=5
RETRY_DELAY=2
DB_HOST="192.168.10.14"
DB_USER="root"
DB_PASS="123456"
DB_NAME="test_db"
QUERY_USER="rw_test_write"

for ((i=1; i<=$MAX_RETRIES; i++)); do
    result=$(mysql -u$DB_USER -p$DB_PASS -h$DB_HOST -e "USE $DB_NAME; SELECT * FROM user_info WHERE username='$QUERY_USER';" 2>/dev/null)
    
    if [ -n "$result" ]; then
        echo "$result"
        exit 0
    fi
    
    if [ $i -lt $MAX_RETRIES ]; then
        sleep $RETRY_DELAY
    fi
done

echo "Error: Data not found after $MAX_RETRIES retries"
exit 1

登录Master（192.168.10.16）查询数据：

bash 复制代码

mysql -uroot -p123456 -h192.168.10.16 -e "USE test_db; SELECT * FROM user_info WHERE username='rw_test_write';"

步骤3：验证读请求路由（从库轮询）

通过"修改从库数据标识+多次读查询"验证读请求在从库间轮询分发（利用Amoeba配置的轮询负载均衡规则）：

分别登录Slave1和Slave2，修改测试数据的标识（用于区分读请求来源）：

以下是根据要求格式化的MySQL操作代码，用于在从库修改测试数据并添加注释说明：

登录Slave1修改数据
sql 复制代码
```
mysql -uroot -p123456 -h192.168.10.14
USE test_db;
UPDATE user_info SET username='rw_test_read_slave1' WHERE username='rw_test_write';
```
登录Slave2修改数据
sql 复制代码
```
mysql -uroot -p123456 -h192.168.10.15
USE test_db;
UPDATE user_info SET username='rw_test_read_slave2' WHERE username='rw_test_write';
```
注意事项：该操作仅在从库临时修改测试数据主库原始数据保持'rw_test_write'不变后续主库写入操作会覆盖从库的临时修改适用于读写分离环境下的数据同步测试场景

客户端连接Amoeba后，多次执行读查询：

sql 复制代码

USE test_db;
SELECT username FROM user_info WHERE username LIKE 'rw_test_read_%';

观察结果：多次查询后，会交替返回"rw_test_read_slave1"和"rw_test_read_slave2"，证明读请求在Slave1和Slave2间轮询分发，符合预期路由规则。

步骤4：验证主从同步一致性

验证"主库写操作后，从库能同步数据"，确保读写分离架构的数据一致性：

客户端连接Amoeba执行写操作（更新数据）：

sql 复制代码

USE test_db;
UPDATE user_info 
SET username = 'rw_test_sync' 
WHERE username LIKE 'rw_test_read_%';

分别登录Master、Slave1、Slave2查询数据：

bash 复制代码

# Master查询
mysql -uroot -p123456 -h192.168.10.16 -e "USE test_db; SELECT username FROM user_info WHERE username='rw_test_sync';"

# Slave1查询
mysql -uroot -p123456 -h192.168.10.14 -e "USE test_db; SELECT username FROM user_info WHERE username='rw_test_sync';"

# Slave2查询
mysql -uroot -p123456 -h192.168.10.15 -e "USE test_db; SELECT username FROM user_info WHERE username='rw_test_sync';"

观察结果：三台服务器均能查询到"rw_test_sync"数据，证明主从同步正常，数据一致性达标。

3. 常见问题及解决办法

问题现象	可能原因	解决办法
客户端无法连接Amoeba	1. Amoeba未启动；2. 防火墙未关闭；3. 账号密码错误	1. 执行./amoeba start启动服务；2. 执行systemctl stop firewalld关闭防火墙；3. 核对amoeba.xml中authentication配置
写操作报错"read-only"	写请求被路由至从库	核对amoeba.xml中writePool是否配置为master，重启Amoeba生效
读请求仅路由至单个从库	dbServers.xml中slaves池配置错误	检查poolNames是否包含slave1和slave2，确保loadbalance=1（轮询）
从库数据同步延迟高	1. 从库性能不足；2. 主库大事务	1. 升级从库硬件，启用并行复制；2. 拆分主库大事务

读写分离测试的核心是验证"写请求路由到主库，读请求路由到从库"，并通过主从数据同步验证架构一致性。本实验通过客户端服务器连接Amoeba，分别执行读、写操作进行验证。

步骤1：客户端连接Amoeba

在客户端服务器（192.168.10.13）上安装MySQL客户端，并连接Amoeba代理服务（Amoeba的默认端口为8066，使用amoeba.xml中配置的客户端账号密码）：

bash 复制代码

yum install -y mysql

bash 复制代码

mysql -uamoeba_client -pClient@123 -h192.168.10.80 -P8066

出现MySQL命令行提示符表示连接成功。

步骤2：验证写请求路由（仅主库执行）

通过"写操作后直接查询从库"的方式验证写请求仅路由到主库：

在客户端连接Amoeba的会话中执行写操作（插入数据）：

sql 复制代码

USE test_db;
-- 插入新测试数据
INSERT INTO user_info (username) VALUES ('read_write_test');

立即登录Slave1（192.168.10.14）和Slave2（192.168.10.15）查询数据，观察是否能立即查到新数据：

sql 复制代码

mysql -uroot -pRoot@123 -h192.168.10.14
USE test_db;
SELECT * FROM user_info WHERE username='read_write_test';

sql 复制代码

SELECT * FROM user_info WHERE username='read_write_test';

登录Master（192.168.10.16）查询数据，确认新数据已存在：

sql 复制代码

mysql -uroot -pRoot@123 -h192.168.10.16 -e "USE test_db; SELECT * FROM user_info WHERE username='read_write_test';"

sql 复制代码

-- 在主库执行插入测试
mysql -uroot -pRoot@123 -h192.168.10.16 -e "USE test_db; INSERT INTO user_info(username) VALUES('read_write_test');"

-- 立即查询主库确认数据
mysql -uroot -pRoot@123 -h192.168.10.16 -e "USE test_db; SELECT NOW(), @@server_id, * FROM user_info WHERE username='read_write_test' ORDER BY id DESC LIMIT 1;"

-- 从库验证命令（需替换从库IP）
mysql -uroot -pRoot@123 -h192.168.10.17 -e "USE test_db; SELECT NOW(), @@server_id, * FROM user_info WHERE username='read_write_test' ORDER BY id DESC LIMIT 1;"

原理：若写请求路由到从库，会因从库开启read_only=1（普通用户无写权限）而报错；本实验中写操作成功且主库立即存在数据，说明写请求仅路由到主库。

步骤3：验证读请求路由（从库轮询执行）

通过"修改从库数据标识+查询"的方式验证读请求路由到从库，且从库池采用轮询负载均衡。由于从库会同步主库数据，直接修改从库数据会被同步覆盖，因此通过"临时修改从库表数据的标识字段"进行测试：

分别登录Slave1和Slave2，修改测试表的标识字段（用于区分读请求来自哪个从库）：

sql 复制代码

-- 登录Slave1并修改数据
mysql -uroot -pRoot@123 -h192.168.10.14
USE test_db;
UPDATE user_info SET username='read_write_test_slave1' WHERE username='read_write_test';

-- 登录Slave2并修改数据
mysql -uroot -pRoot@123 -h192.168.10.15
USE test_db;
UPDATE user_info SET username='read_write_test_slave2' WHERE username='read_write_test';

在客户端连接Amoeba的会话中多次执行读操作（查询数据），观察返回结果的标识后缀：
sql 复制代码
```
USE test_db;
SELECT username FROM user_info WHERE username LIKE 'read_write_test%';
 
```
观察结果：多次执行查询后，会交替返回read_write_test_slave1和read_write_test_slave2，证明读请求在Slave1和Slave2之间轮询分发，符合amoeba.xml中配置的轮询负载均衡规则。

步骤4：验证主从同步一致性

验证"主库写操作后，从库能同步数据"，确保读写分离架构的数据一致性：

在客户端连接Amoeba的会话中执行写操作（更新数据）：

sql 复制代码

USE test_db;
UPDATE user_info 
SET username = 'sync_test' 
WHERE username LIKE 'read_write_test%';

分别登录Master、Slave1、Slave2查询数据：

sql 复制代码

USE test_db;
SELECT username FROM user_info WHERE username='sync_test';

观察结果：三台服务器均能查询到username='sync_test'的数据，证明主库写操作后，数据已同步到从库，架构一致性正常。

3. 读写分离常见问题及解决方法

常见问题	排查方向	解决方法
客户端无法连接Amoeba	1. Amoeba服务未启动；2. 防火墙/SELinux未关闭；3. 账号密码错误；4. 端口被占用	1. 执行`ps -ef
写操作报错"read-only"	写请求被路由到从库（从库开启read_only）	1. 检查amoeba.xml中`writePool`是否配置为master；2. 重启Amoeba服务：`./amoeba restart`
读请求仅路由到单个从库	1. dbServers.xml中从库池配置错误；2. 负载均衡算法配置错误	1. 核对dbServers.xml中slaves节点的`poolNames`是否包含slave1和slave2；2. 确保`loadbalance=1`（轮询）
从库数据同步延迟过高	1. 从库性能不足；2. 主库存在大事务；3. 并行复制未启用	1. 升级从库硬件；2. 拆分主库大事务；3. 核对从库my.cnf中`slave_parallel_workers`配置并重启MySQL

五、总结与生产环境建议

本文通过原理解析和实战实验，搭建了"一主两从+Amoeba读写分离"的MySQL架构，实现了负载均衡和数据高可用。结合实验过程和生产经验，提出以下建议：

1. 架构优化建议

主从复制升级：生产环境建议使用GTID复制替代基于日志位置的复制，简化故障切换；启用增强半同步复制，避免数据丢失。
中间件选型：中小规模架构可使用Amoeba；大规模或复杂场景（如分库分表）建议使用MyCat或ProxySQL，支持更丰富的路由规则和高可用特性。
从库扩容：当读压力持续增加时，可通过增加从库节点扩展读能力，仅需在Amoeba的dbServers.xml中新增从库配置并更新从库池即可。

2. 运维监控重点

主从复制状态 ：通过监控Slave_IO_Running、Slave_SQL_Running和Seconds_Behind_Master指标，及时发现复制故障和延迟。
Amoeba状态：监控Amoeba的连接数、CPU利用率和日志错误信息，避免代理层成为瓶颈；建议部署Amoeba集群（配合Keepalived）实现高可用。
数据库性能：通过Prometheus+Grafana监控主从库的QPS、慢查询、CPU和IO使用率，提前识别性能瓶颈。

3. 数据一致性保障

特殊读请求处理：对于"写后立即读"的场景（如用户注册后立即查询个人信息），需在程序中强制路由到主库，避免主从延迟导致的旧数据问题。
定期数据校验：使用pt-table-checksum工具定期校验主从数据一致性，发现不一致时通过pt-table-sync工具修复。

MySQL主从复制与读写分离是高并发场景的基础架构方案，需结合业务特点选择合适的复制方式和中间件，通过完善的监控和运维保障架构稳定运行。