Debian MariaDB数据迁移方案

Debian MariaDB 数据迁移方案

一、方案总览与选择

逻辑迁移：使用 mysqldump 导出为 SQL 并在目标端导入，适用于跨版本、跨平台、选择性迁移，停机时间短（可在低峰窗口导入）。
物理迁移：直接拷贝数据目录 /var/lib/mysql 到目标端并调整配置，要求版本与配置高度一致，需停机，适合同版本整机迁移。
主从复制零停机：将目标端先设为源端从库，追平后切换应用连接，再断开复制，适合对业务连续性要求高的场景。
云上 DTS：若目标为云上数据库（如 RDS MySQL），可用 DTS 做结构+全量+增量迁移，支持会话级外键约束临时禁用、Rename 风险提醒等能力。

二、通用准备与风险控制

备份与版本核对：全量备份（如 –all-databases），核对源端版本（SELECT VERSION();）、字符集与排序规则（SHOW VARIABLES LIKE ‘character_set%’;），确保目标端字符集一致（推荐 utf8mb4）。
目标端准备：安装 mariadb-server，运行 mysql_secure_installation 初始化安全项。
权限与复制账号：准备用于迁移/复制的账号，按需授予 SELECT、REPLICATION SLAVE/CLIENT 等权限。
应用侧准备：梳理连接串、连接池、超时与重试策略，准备回滚预案与切换窗口。
大表策略：分批导出/导入、使用压缩传输、必要时增加 innodb_buffer_pool_size，导入后执行 ANALYZE/OPTIMIZE TABLE 提升统计与性能。

三、三种落地方案步骤

方案A 逻辑迁移（推荐，低停机）
1. 源端导出：
  mysqldump -uroot -p --single-transaction --routines --triggers --default-character-set=utf8mb4 --databases your_db > backup.sql
  如需跨版本或含 GTID 信息，可加 –set-gtid-purged=OFF。
2. 传输到目标端：
  scp backup.sql user@target:/tmp/
3. 目标端导入：
  mysql -uroot -p < /tmp/backup.sql
4. 验证：SHOW DATABASES; USE your_db; SHOW TABLES; SELECT COUNT(*) FROM critical_table;
5. 切换应用并更新配置，观察错误日志与连接状态。
方案B 物理迁移（同版本、停机窗口）
1. 停库：systemctl stop mariadb（源与目标）。
2. 拷贝数据目录：
  rsync -avz --info=progress2 /var/lib/mysql/ target:/var/lib/mysql_new
3. 调整目标配置（/etc/mysql/mariadb.conf.d/50-server.cnf）：
  [mysqld] datadir=/var/lib/mysql_new
  并确保目录属主：chown -R mysql:mysql /var/lib/mysql_new
4. 启动与验证：
  systemctl start mariadb
  mysql -uroot -p -e “SHOW GLOBAL VARIABLES LIKE ‘%datadir%’;”
5. 如启用 AppArmor/SELinux，需同步策略或临时调整。
方案C 主从复制零停机（不停写迁移）
1. 目标端设置唯一 server_id（避免与源端冲突）。
2. 源端备份（含主库位点/GTID）：
  mysqldump -h src_host -u repl -p --single-transaction --master-data=2 --set-gtid-purged=ON --databases your_db > master_dump.sql
3. 目标端恢复：mysql -uroot -p < master_dump.sql
4. 配置复制（示例，基于 GTID）：
  CHANGE MASTER TO MASTER_HOST=‘src_ip’, MASTER_USER=‘repl’, MASTER_PASSWORD=‘pwd’, MASTER_USE_GTID=slave_pos;
  START SLAVE;
  SHOW SLAVE STATUS\G（确保 Slave_IO_Running/Slave_SQL_Running=Yes，Seconds_Behind_Master=0）
5. 切换：短暂停写→应用切到目标（如通过 MaxScale 或 VIP）→确认无延迟→STOP SLAVE; RESET SLAVE ALL; 还原 server_id。

四、迁移后验证与优化

数据一致性：对关键表做行数与抽样校验（COUNT(*)、校验和/抽样对比），核对视图、存储过程、触发器、外键。
字符集与排序规则：确认库/表/列级为 utf8mb4，避免乱码。
索引与统计：执行 ANALYZE TABLE 更新统计信息；大批量导入后可 OPTIMIZE TABLE 回收碎片。
性能与健康：监控错误日志、连接数、慢查询；按需调整 innodb_buffer_pool_size、连接池与超时参数。

五、常见问题与排错要点

版本不兼容：跨小版本/大版本优先用逻辑迁移；如用物理迁移，导入后执行 mysql_upgrade（视版本与包而定）。
GTID 与位点：基于 GTID 复制更稳健；使用 mysqldump 时建议 –set-gtid-purged=ON，避免位点错配。
外键与 DDL：DTS 在迁移阶段会会话级禁用约束检查；自建迁移时，导入期间避免执行 DDL，或先导入数据再建外键。
大表超时/中断：分批导出/导入、提高 net_read/write_timeout、使用压缩与稳定网络；必要时增加 innodb_log_file_size 与缓冲池。
权限遗漏：迁移后复核应用账号权限（GRANT），确保主机、库、表级权限正确。

最新问答

相关标签