MySQL 从单机到集群迁移

迁移概述

从单机到集群迁移是指将MySQL数据库从单实例部署迁移到高可用集群部署，以提高系统的可用性、可扩展性和容错能力。随着业务的发展，单实例数据库可能无法满足高并发、高可用的需求，此时需要考虑迁移到集群架构。

迁移目标：

提高系统可用性，实现99.9%以上的服务可用
实现读写分离，提高系统并发处理能力
实现故障自动或手动切换，减少停机时间
提高系统可扩展性，支持横向扩展

迁移挑战：

应用架构需要适配集群环境
数据一致性保证
故障切换机制设计
性能监控和优化
迁移过程中业务连续性保障

迁移前准备

业务需求评估

可用性需求
- 业务允许的最大停机时间
- 是否需要自动故障切换
- 数据一致性要求（强一致性、最终一致性）
性能需求
- 当前系统QPS/TPS
- 预期增长情况
- 是否需要读写分离
- 是否需要横向扩展
成本预算
- 服务器硬件成本
- 软件许可成本
- 维护成本

源数据库评估

数据库基本信息
- 版本：MySQL 5.6/5.7/8.0
- 存储引擎：InnoDB/MyISAM
- 字符集：utf8/utf8mb4
- 数据量：数据库总大小
数据库负载情况
- QPS/TPS
- 读写比例
- 慢查询情况
- 连接数
数据库健康状态
- 表碎片情况
- 索引使用情况
- 锁等待情况
- 主从延迟（如果已有复制）

集群架构设计

节点规划
- 主节点数量
- 从节点数量
- 混合节点（只读、延迟复制等）
网络规划
- 内网连接
- 跨机房部署（可选）
- 网络带宽要求
存储规划
- 存储类型：SSD/HDD
- 存储容量
- 存储冗余
备份策略
- 集群环境下的备份策略
- 备份验证机制
- 灾难恢复方案

集群架构选择

1. 主从复制架构

架构概述：一主多从架构，主节点负责写操作，从节点负责读操作。

主要特性：

简单易用，配置方便
支持读写分离
支持横向扩展读能力
主节点故障后需要手动切换

适用场景：

读写比例较高的业务
对可用性要求不极致
预算有限

版本支持：

MySQL 5.6：支持基本主从复制
MySQL 5.7：支持增强半同步复制、多源复制
MySQL 8.0：支持Group Replication

2. MySQL Group Replication (MGR)

架构概述：MySQL官方提供的高可用解决方案，支持多主模式和单主模式。

主要特性：

自动故障检测和恢复
强一致性保证
支持多主模式
内置成员管理

适用场景：

对可用性要求较高
需要强一致性
预算充足

版本支持：

MySQL 5.7.17+：支持
MySQL 8.0：完全支持，功能增强

3. Galera Cluster

架构概述：基于WSREP协议的同步复制集群，支持多主模式。

主要特性：

同步复制，强一致性
自动故障检测和恢复
支持多主模式
无主从延迟

适用场景：

对数据一致性要求极高
读写比例较均衡
允许写性能略有下降

版本支持：

MySQL 5.6+：支持
MySQL 5.7+：完全支持
MySQL 8.0：支持

4. 主从复制+ProxySQL

架构概述：主从复制基础上增加ProxySQL作为中间件，实现读写分离和自动故障切换。

主要特性：

支持读写分离
支持自动故障切换
支持查询路由
支持连接池

适用场景：

已有主从复制架构
需要自动故障切换
需要更灵活的查询路由

版本支持：

MySQL 5.6+：支持

架构选择建议

架构类型	可用性	一致性	写性能	读扩展性	复杂度	成本	适用场景
主从复制	中	最终一致性	高	高	低	低	读写比例高、预算有限
MGR	高	强一致性	中	高	中	中	对可用性和一致性要求高
Galera Cluster	高	强一致性	中	高	中	中	对一致性要求极高
主从+ProxySQL	高	最终一致性	高	高	中	中	已有主从架构、需要自动切换

迁移方法详解

1. 基于复制的迁移

适用场景：

大型数据库在线迁移
业务不允许长时间停机
主从复制或MGR架构

主要步骤：

部署集群节点
配置主从复制或MGR
待数据同步完成后切换应用

优点：

在线迁移，无需停机
数据同步实时性高
可以进行切换演练

缺点：

配置复杂
需要额外监控

2. 基于备份恢复的迁移

适用场景：

中小型数据库
可以接受短时间停机
所有集群架构

主要步骤：

备份源数据库
在集群节点上恢复备份
配置集群
切换应用连接

优点：

操作简单
配置容易
适合所有集群架构

缺点：

需要停机
迁移时间长

3. 混合迁移方法

适用场景：

超大型数据库
业务不允许长时间停机
主从复制或MGR架构

主要步骤：

使用备份恢复初始化集群
配置增量复制
待增量数据同步完成后切换应用

优点：

结合了备份恢复和复制的优点
迁移时间短
数据一致性高

缺点：

配置复杂
需要更多资源

操作步骤（以主从复制+ProxySQL为例）

1. 部署集群节点

准备3台服务器：

主节点：192.168.1.101
从节点1：192.168.1.102
从节点2：192.168.1.103
ProxySQL节点：192.168.1.104

安装MySQL：

bash

# 在所有节点上安装MySQL
# 以CentOS 7为例
yum install -y mysql-community-server

2. 配置主节点

编辑my.cnf：

ini

[mysqld]
# 基本配置
server-id = 101
port = 3306
datadir = /var/lib/mysql
socket = /var/lib/mysql/mysql.sock

# 二进制日志配置
binlog-format = ROW
log-bin = mysql-bin
log-slave-updates = 1
expire_logs_days = 7

# InnoDB配置
innodb_buffer_pool_size = 2G
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1
innodb_log_file_size = 512M

# 其他配置
skip_name_resolve = 1
read_only = 0

启动主节点：

bash

systemctl start mysqld
systemctl enable mysqld

创建复制用户：

sql

CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.%';
FLUSH PRIVILEGES;

-- 获取主节点状态
SHOW MASTER STATUS;

3. 配置从节点

编辑my.cnf（从节点1）：

ini

[mysqld]
# 基本配置
server-id = 102
port = 3306
datadir = /var/lib/mysql
socket = /var/lib/mysql/mysql.sock

# 二进制日志配置
binlog-format = ROW
log-bin = mysql-bin
log-slave-updates = 1
expire_logs_days = 7

# InnoDB配置
innodb_buffer_pool_size = 2G
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1
innodb_log_file_size = 512M

# 复制配置
relay-log = relay-bin
read_only = 1
skip_name_resolve = 1

启动从节点并配置复制：

bash

systemctl start mysqld
systemctl enable mysqld

sql

-- 配置主从复制
CHANGE MASTER TO 
  MASTER_HOST='192.168.1.101',
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=107;

-- 启动复制
START SLAVE;

-- 检查复制状态
SHOW SLAVE STATUS\G;

从节点2配置：与从节点1相同，仅需修改server-id为103。

4. 部署和配置ProxySQL

安装ProxySQL：

bash

# 以CentOS 7为例
yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
percona-release enable proxysql-2.5
yum install -y proxysql

启动ProxySQL：

bash

systemctl start proxysql
systemctl enable proxysql

配置ProxySQL：

sql

-- 连接到ProxySQL管理界面
mysql -u admin -padmin -h 127.0.0.1 -P 6032

-- 添加MySQL服务器
INSERT INTO mysql_servers (hostgroup_id, hostname, port, weight, max_connections) VALUES 
(10, '192.168.1.101', 3306, 100, 1000),
(20, '192.168.1.102', 3306, 100, 1000),
(20, '192.168.1.103', 3306, 100, 1000);

-- 添加监控用户
INSERT INTO mysql_monitor_users (username, password, active) VALUES ('monitor', 'monitor_password', 1);

-- 添加应用用户
INSERT INTO mysql_users (username, password, active, default_hostgroup, max_connections) VALUES ('app_user', 'app_password', 1, 10, 1000);

-- 配置读写分离规则
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply) VALUES 
(1, 1, '^SELECT.*FOR UPDATE$', 10, 1),
(2, 1, '^SELECT', 20, 1);

-- 加载配置到运行时
LOAD MYSQL SERVERS TO RUNTIME;
LOAD MYSQL USERS TO RUNTIME;
LOAD MYSQL QUERY RULES TO RUNTIME;

-- 保存配置到磁盘
SAVE MYSQL SERVERS TO DISK;
SAVE MYSQL USERS TO DISK;
SAVE MYSQL QUERY RULES TO DISK;

5. 数据同步验证

检查主从同步状态：

sql

-- 在从节点上执行
SHOW SLAVE STATUS\G;
-- 确保Slave_IO_Running和Slave_SQL_Running都为Yes
-- 检查Seconds_Behind_Master是否为0或较小值

数据一致性验证：

bash

# 使用pt-table-checksum验证数据一致性
pt-table-checksum h=192.168.1.101,u=root,p=password

6. 应用切换

切换前准备：

通知相关业务团队
暂停应用写入（如果需要）
确保所有从节点同步完成

切换步骤：

修改应用配置，将数据库连接地址指向ProxySQL节点
重启应用或刷新连接池
监控应用运行状态
监控数据库性能

切换后验证：

应用能否正常连接数据库
读写分离是否生效
数据库性能是否正常
没有出现错误日志

应用改造

1. 连接方式改造

从直接连接改为通过中间件连接：

修改应用配置，将数据库连接地址指向ProxySQL或其他中间件
确保中间件高可用，避免单点故障

连接池配置优化：

调整连接池大小，适应集群环境
配置连接超时和重试机制
启用连接健康检查

2. SQL语句优化

读写分离适配：

确保写操作发送到主节点
读操作尽量发送到从节点
避免在事务中混合读写操作

避免使用影响复制的SQL：

避免使用SET GLOBAL等全局语句
避免使用非确定性函数，如NOW()、RAND()
确保表有主键，便于复制和故障切换

3. 事务处理

长事务处理：

尽量缩短事务时间
避免在事务中进行耗时操作
考虑将大事务拆分为小事务

分布式事务：

集群环境下尽量避免分布式事务
如必须使用，考虑使用XA事务或其他解决方案

迁移验证

1. 集群状态验证

检查主从同步状态：

sql

SHOW SLAVE STATUS\G;

检查MGR状态（如果使用MGR）：

sql

SELECT * FROM performance_schema.replication_group_members;
SELECT * FROM performance_schema.replication_group_member_stats;

检查ProxySQL状态：

sql

-- 连接到ProxySQL管理界面
mysql -u admin -padmin -h 127.0.0.1 -P 6032

-- 查看MySQL服务器状态
SELECT * FROM mysql_servers;

-- 查看连接统计
SELECT * FROM stats_mysql_commands_counters;

2. 数据一致性验证

使用pt-table-checksum：

bash

pt-table-checksum h=192.168.1.101,u=root,p=password

手动验证：

sql

-- 在主节点上执行
SELECT COUNT(*) FROM dbname.tablename;

-- 在从节点上执行
SELECT COUNT(*) FROM dbname.tablename;

-- 对比结果是否一致

3. 性能验证

监控关键性能指标：

QPS/TPS变化
响应时间变化
连接数变化
缓存命中率
主从延迟

压力测试：

使用sysbench或其他工具进行压力测试
对比迁移前后的性能差异
测试故障切换后的性能变化

4. 业务功能验证

测试核心业务功能：

用户注册、登录
数据查询、修改、删除
事务处理
报表生成

测试边界情况：

大量并发请求
大数据量查询
长时间运行的事务

故障切换演练

手动故障切换

主节点故障切换步骤：

确认主节点故障
选择一个从节点作为新主节点
停止该从节点的复制
将该从节点设置为可写
其他从节点指向新主节点
修改ProxySQL配置
验证新主节点状态

操作示例：

sql

-- 在从节点1上执行
-- 停止复制
STOP SLAVE;
-- 重置复制信息
RESET SLAVE ALL;
-- 设置为可写
SET GLOBAL read_only = OFF;

-- 在其他从节点上执行
-- 指向新主节点
CHANGE MASTER TO 
  MASTER_HOST='192.168.1.102',
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=107;
-- 启动复制
START SLAVE;

自动故障切换

ProxySQL自动故障切换配置：

sql

-- 连接到ProxySQL管理界面
mysql -u admin -padmin -h 127.0.0.1 -P 6032

-- 启用自动故障切换
UPDATE global_variables SET variable_value='1' WHERE variable_name='mysql-monitor_enabled';
UPDATE global_variables SET variable_value='2000' WHERE variable_name='mysql-monitor_connect_interval';
UPDATE global_variables SET variable_value='2000' WHERE variable_name='mysql-monitor_ping_interval';
UPDATE global_variables SET variable_value='5' WHERE variable_name='mysql-monitor_max_failures';

-- 加载配置到运行时
LOAD MYSQL VARIABLES TO RUNTIME;

-- 保存配置到磁盘
SAVE MYSQL VARIABLES TO DISK;

故障切换验证：

模拟主节点故障（停止MySQL服务）
监控ProxySQL自动故障切换过程
验证应用能否继续正常运行
检查新主节点状态

回滚方案

回滚条件

当出现以下情况时，需要执行回滚操作：

集群部署失败
应用在集群环境下运行异常
性能下降超出预期
数据一致性问题无法解决

回滚步骤

停止应用访问集群
恢复应用连接到源单机数据库
监控应用运行状态
清理集群环境

回滚注意事项

确保源单机数据库状态良好
回滚过程中可能会丢失部分数据，需要从备份恢复
回滚后需要重新评估迁移方案

最佳实践

迁移前
- 制定详细的迁移计划和回滚方案
- 在测试环境进行充分的测试
- 评估业务需求和集群架构
- 通知相关业务团队
迁移中
- 严格按照迁移计划执行
- 实时监控迁移过程
- 记录每一步操作和结果
- 及时解决迁移过程中的问题
迁移后
- 进行全面的验证
- 监控集群状态和性能
- 进行故障切换演练
- 优化集群配置和应用
版本特定建议
- MySQL 5.6：建议使用主从复制架构，注意binlog格式设置
- MySQL 5.7：可以考虑MGR架构，支持更多高级特性
- MySQL 8.0：推荐使用MGR架构，性能和稳定性更好
监控和告警
- 监控集群状态、主从延迟、连接数等指标
- 设置合理的告警阈值
- 定期检查和分析监控数据
备份和恢复
- 集群环境下定期进行备份
- 测试备份恢复流程
- 制定灾难恢复方案

常见问题处理

主从延迟大
- 优化主节点binlog写入性能
- 增加从节点硬件配置
- 减少从节点上的查询负载
- 考虑使用并行复制
复制错误
- 查看错误日志，定位问题
- 修复错误（如跳过错误事务、修复数据）
- 重新启动复制
应用连接失败
- 检查ProxySQL配置
- 检查中间件和数据库节点之间的网络连接
- 验证应用用户名和密码
读写分离不生效
- 检查ProxySQL查询规则配置
- 验证SQL语句是否匹配规则
- 检查应用连接是否使用了正确的端口
故障切换失败
- 检查自动故障切换配置
- 验证监控用户权限
- 检查节点之间的网络连接
性能下降
- 分析慢查询日志
- 调整集群配置参数
- 优化应用SQL语句
- 考虑增加集群节点

总结

从单机到集群迁移是一项复杂的系统工程，需要DBA充分了解业务需求、评估源数据库状态、选择合适的集群架构，并制定详细的迁移计划和回滚方案。

在实际生产环境中，DBA应该：

充分评估业务需求和集群架构
选择合适的迁移方法
严格按照迁移计划执行
进行全面的验证和故障切换演练
制定详细的回滚方案
迁移后持续监控和优化

通过遵循上述最佳实践和注意事项，可以最大限度地降低迁移风险，确保从单机到集群的平稳过渡，提高系统的可用性、可扩展性和容错能力。

MySQL 从单机到集群迁移 ​

迁移概述 ​

迁移前准备 ​

业务需求评估 ​

源数据库评估 ​

集群架构设计 ​

集群架构选择 ​

1. 主从复制架构 ​

2. MySQL Group Replication (MGR) ​

3. Galera Cluster ​

4. 主从复制+ProxySQL ​

架构选择建议 ​

迁移方法详解 ​

1. 基于复制的迁移 ​

2. 基于备份恢复的迁移 ​

3. 混合迁移方法 ​

操作步骤（以主从复制+ProxySQL为例） ​

1. 部署集群节点 ​

2. 配置主节点 ​

3. 配置从节点 ​

4. 部署和配置ProxySQL ​

5. 数据同步验证 ​

6. 应用切换 ​

应用改造 ​

1. 连接方式改造 ​

2. SQL语句优化 ​

3. 事务处理 ​

迁移验证 ​

1. 集群状态验证 ​

2. 数据一致性验证 ​

3. 性能验证 ​

4. 业务功能验证 ​

故障切换演练 ​

手动故障切换 ​

自动故障切换 ​

回滚方案 ​

回滚条件 ​

回滚步骤 ​

回滚注意事项 ​

最佳实践 ​

常见问题处理 ​

总结 ​

MySQL 从单机到集群迁移

迁移概述

迁移前准备

业务需求评估

源数据库评估

集群架构设计

集群架构选择

1. 主从复制架构

2. MySQL Group Replication (MGR)

3. Galera Cluster

4. 主从复制+ProxySQL

架构选择建议

迁移方法详解

1. 基于复制的迁移

2. 基于备份恢复的迁移

3. 混合迁移方法

操作步骤（以主从复制+ProxySQL为例）

1. 部署集群节点

2. 配置主节点

3. 配置从节点

4. 部署和配置ProxySQL

5. 数据同步验证

6. 应用切换

应用改造

1. 连接方式改造

2. SQL语句优化

3. 事务处理

迁移验证

1. 集群状态验证

2. 数据一致性验证

3. 性能验证

4. 业务功能验证

故障切换演练

手动故障切换

自动故障切换

回滚方案

回滚条件

回滚步骤

回滚注意事项

最佳实践

常见问题处理

总结