印刻数据库

外观

MariaDB 同版本迁移 ​

迁移概述 ​

MariaDB 同版本迁移是指在相同 MariaDB 版本之间进行的数据迁移，通常用于以下场景：

  • 服务器硬件升级
  • 操作系统升级
  • 存储设备更换
  • 数据中心迁移
  • 数据库架构调整

同版本迁移相对简单，因为不需要考虑版本兼容性问题，但仍需要仔细规划和执行，以确保数据安全和业务连续性。

迁移方案选择 ​

1. 逻辑备份恢复（mysqldump） ​

原理：使用 mysqldump 导出数据，然后在目标服务器上导入。

适用场景：

  • 小型数据库（< 10GB）
  • 需要跨平台迁移
  • 需要重新组织表结构

优缺点：

  • 优点：操作简单，跨平台兼容，支持选择性迁移
  • 缺点：迁移速度慢，占用较多 CPU 和内存资源

2. 物理备份恢复（xtrabackup） ​

原理：使用 xtrabackup 进行物理备份，然后在目标服务器上恢复。

适用场景：

  • 大型数据库（> 10GB）
  • 要求快速迁移
  • 对业务中断时间敏感

优缺点：

  • 优点：迁移速度快，对服务器资源占用少，支持增量备份
  • 缺点：操作相对复杂，需要相同的操作系统和 MariaDB 版本

3. 主从复制迁移 ​

原理：利用主从复制机制，先搭建从库，然后切换为主库。

适用场景：

  • 要求零 downtime 迁移
  • 大型数据库
  • 高可用性要求

优缺点：

  • 优点：几乎零 downtime，迁移过程安全可靠
  • 缺点：配置相对复杂，需要额外的服务器资源

4. 文件拷贝迁移 ​

原理：直接拷贝数据文件到目标服务器。

适用场景：

  • 相同操作系统和硬件架构
  • 紧急情况下的快速迁移

优缺点：

  • 优点：迁移速度最快
  • 缺点：风险较高，需要确保文件一致性

迁移前准备 ​

1. 环境准备 ​

  • 目标服务器硬件配置不低于源服务器
  • 安装相同版本的 MariaDB
  • 配置相同或兼容的操作系统
  • 确保网络连接畅通

2. 备份策略 ​

  • 执行全量备份
  • 备份配置文件
  • 测试备份恢复过程

3. 性能基准测试 ​

  • 在目标服务器上执行性能基准测试
  • 确保目标服务器性能符合要求
  • 识别可能的性能瓶颈

4. 测试环境验证 ​

  • 在测试环境中模拟迁移过程
  • 验证迁移后系统稳定性
  • 测试应用兼容性

迁移步骤 ​

方法一：使用 xtrabackup 进行物理备份恢复 ​

1. 在源服务器上执行全量备份 ​

bash
# 创建备份目录
mkdir -p /backup/mariadb-full-$(date +%Y%m%d_%H%M%S)

# 执行全量备份
xtrabackup --backup --target-dir=/backup/mariadb-full-$(date +%Y%m%d_%H%M%S) --user=root --password=password

2. 将备份文件复制到目标服务器 ​

bash
# 使用 rsync 复制备份文件
rsync -avz /backup/mariadb-full-$(date +%Y%m%d_%H%M%S) root@target-server:/backup/

3. 在目标服务器上准备备份 ​

bash
# 准备备份
xtrabackup --prepare --target-dir=/backup/mariadb-full-$(date +%Y%m%d_%H%M%S)

4. 停止目标服务器的 MariaDB 服务 ​

bash
systemctl stop mariadb

5. 清理目标服务器的数据目录 ​

bash
rm -rf /var/lib/mysql/*

6. 恢复备份到目标服务器 ​

bash
# 恢复备份
xtrabackup --copy-back --target-dir=/backup/mariadb-full-$(date +%Y%m%d_%H%M%S)

# 恢复数据目录权限
chown -R mysql:mysql /var/lib/mysql

7. 启动目标服务器的 MariaDB 服务 ​

bash
systemctl start mariadb

8. 验证迁移结果 ​

sql
-- 检查数据库版本
SELECT VERSION();

-- 检查数据库列表
SHOW DATABASES;

-- 检查表结构和数据
USE db_name;
SHOW TABLES;
SELECT COUNT(*) FROM table_name;

方法二：使用主从复制进行迁移 ​

1. 在源服务器上创建复制用户 ​

sql
-- 创建复制用户
CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

2. 获取源服务器的二进制日志位置 ​

sql
-- 锁定数据库
FLUSH TABLES WITH READ LOCK;

-- 获取二进制日志位置
SHOW MASTER STATUS;

3. 在目标服务器上配置主从复制 ​

sql
-- 配置主从复制
CHANGE MASTER TO
  MASTER_HOST='source-server',
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=1234,
  MASTER_CONNECT_RETRY=10;

-- 启动从库
START SLAVE;

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

4. 解锁源服务器 ​

sql
-- 解锁数据库
UNLOCK TABLES;

5. 等待复制完成 ​

sql
-- 检查复制延迟
SHOW SLAVE STATUS\G;
-- 确保 Seconds_Behind_Master 为 0

6. 切换应用到目标服务器 ​

bash
# 停止应用服务
systemctl stop app-service

# 更新应用配置，指向目标服务器
# ...

# 启动应用服务
systemctl start app-service

7. 验证迁移结果 ​

sql
-- 检查应用连接
SHOW PROCESSLIST;

-- 检查业务数据
SELECT COUNT(*) FROM business_table;

迁移验证 ​

1. 基本验证 ​

sql
-- 检查数据库服务状态
SHOW STATUS LIKE 'Uptime';

-- 检查连接数
SHOW STATUS LIKE 'Threads_connected';

-- 检查错误日志
SHOW GLOBAL VARIABLES LIKE 'log_error';

2. 数据完整性验证 ​

bash
# 使用 mysqlcheck 检查表完整性
mysqlcheck --check --all-databases -u root -p

# 使用 pt-table-checksum 验证数据一致性
pt-table-checksum h=source-server,u=root,p=password --no-check-binlog-format
pt-table-checksum h=target-server,u=root,p=password --no-check-binlog-format

3. 应用兼容性验证 ​

  • 启动应用服务
  • 验证应用日志
  • 执行功能测试
  • 执行压力测试

4. 性能验证 ​

  • 执行性能基准测试
  • 比较迁移前后的性能差异
  • 优化目标服务器配置

迁移最佳实践 ​

1. 选择合适的迁移方案 ​

  • 根据数据库大小、业务需求和资源情况选择合适的迁移方案
  • 小型数据库推荐使用 mysqldump
  • 大型数据库推荐使用 xtrabackup 或主从复制
  • 高可用性要求推荐使用主从复制

2. 充分测试 ​

  • 在测试环境中完整测试迁移流程
  • 验证应用兼容性
  • 执行性能基准测试
  • 测试回滚流程

3. 监控系统 ​

  • 迁移过程中开启实时监控
  • 监控服务器资源使用情况
  • 监控数据库状态和性能指标
  • 设置合理的告警规则

4. 优化配置 ​

  • 根据目标服务器的硬件配置优化 MariaDB 参数
  • 调整缓存大小
  • 优化存储引擎设置
  • 调整线程池配置

5. 文档记录 ​

  • 详细记录迁移过程中的所有操作
  • 记录迁移前后的系统状态
  • 记录遇到的问题和解决方案
  • 总结经验教训

常见问题处理 ​

1. 备份恢复失败 ​

问题现象：

xtrabackup: Error: xtrabackup: failed to read header from '/backup/mariadb-full-20251227_140000/ibdata1' at offset 0.

解决方法：

  • 检查备份文件的完整性
  • 检查源服务器和目标服务器的 MariaDB 版本是否一致
  • 检查目标服务器的磁盘空间是否足够

2. 主从复制延迟 ​

问题现象：

Seconds_Behind_Master: 300

解决方法：

  • 检查网络连接
  • 优化从库配置：启用并行复制
  • 减少主库写入压力
  • 检查从库资源使用情况

3. 应用连接失败 ​

问题现象：

ERROR 1045 (28000): Access denied for user 'app_user'@'localhost' (using password: YES)

解决方法：

  • 检查用户名和密码
  • 检查用户权限
  • 检查网络连接
  • 检查防火墙规则

4. 性能下降 ​

问题现象：

  • 响应时间变长
  • CPU 使用率增加
  • 慢查询数量增加

解决方法：

  • 更新统计信息：ANALYZE TABLE table_name;
  • 优化索引：添加或修改索引
  • 调整配置参数：如 innodb_buffer_pool_size
  • 优化 SQL 语句

常见问题（FAQ） ​

问：同版本迁移需要多长时间？ ​

答：迁移时间取决于数据库大小、迁移方案和服务器性能：

  • 逻辑备份恢复：数小时到数天
  • 物理备份恢复：数十分钟到数小时
  • 主从复制：主要取决于网络带宽和数据量

问：迁移过程中会丢失数据吗？ ​

答：如果按照正确的迁移步骤执行，迁移过程中不应该丢失数据。但为了安全起见，建议执行完整备份，并测试恢复过程。

问：迁移后需要修改应用代码吗？ ​

答：同版本迁移不需要修改应用代码，因为数据库版本和功能保持不变。

问：如何确保迁移后的数据一致性？ ​

答：

  • 使用校验工具验证数据完整性
  • 比较迁移前后的表行数和索引数
  • 执行应用功能测试
  • 监控业务数据变化

问：迁移后可以回滚吗？ ​

答：是的，可以回滚。回滚步骤包括：

  1. 停止应用服务
  2. 切换应用配置回源服务器
  3. 启动应用服务
  4. 验证回滚结果

总结 ​

MariaDB 同版本迁移是一项常见的数据库运维任务，需要根据实际情况选择合适的迁移方案。通过充分的准备、仔细的执行和全面的验证，可以确保迁移过程顺利进行，减少业务中断时间，保证数据安全和一致性。

迁移过程包括：

  1. 迁移方案选择：根据数据库大小、业务需求和资源情况选择合适的迁移方案
  2. 迁移前准备：环境准备、备份策略、性能基准测试和测试环境验证
  3. 迁移执行：按照选定的迁移方案执行迁移操作
  4. 迁移验证：基本验证、数据完整性验证、应用兼容性验证和性能验证
  5. 迁移后优化：优化配置参数、调整系统设置和监控系统

通过遵循最佳实践，可以提高迁移的效率和准确性，确保迁移后的系统稳定运行，为业务提供可靠的数据库服务。