印刻数据库

外观

SQLServer 跨平台迁移 ​

SQLServer 跨平台迁移概述 ​

SQL Server 跨平台迁移是指将数据库从一个操作系统平台迁移到另一个不同的操作系统平台，如从 Windows 迁移到 Linux 或反之。随着 SQL Server 2017 及以上版本正式支持 Linux 和容器化部署，跨平台迁移已成为企业 IT 架构转型中的常见需求。

对于生产环境中的 DBA 来说，跨平台迁移需要考虑平台差异、功能兼容性、性能影响和业务连续性等多个方面。不同版本的 SQL Server 在跨平台迁移支持上存在差异，需要根据实际环境选择合适的迁移策略。

支持的平台与版本差异 ​

支持的平台 ​

SQL Server 版本支持的平台
SQL Server 2017Windows Server 2016+、Windows 10+、Linux（RHEL 7.3+、SLES 12 SP2+、Ubuntu 16.04 LTS+）、Docker 容器
SQL Server 2019Windows Server 2016+、Windows 10+、Linux（RHEL 7.7+、SLES 12 SP5+、Ubuntu 18.04 LTS+）、Docker 容器
SQL Server 2022Windows Server 2019+、Windows 10+、Linux（RHEL 8.0+、SLES 15+、Ubuntu 20.04 LTS+）、Docker 容器

版本差异要点 ​

  • SQL Server 2017：首个支持 Linux 的版本，跨平台功能相对基础，部分高级功能在 Linux 上不可用
  • SQL Server 2019：增强了 Linux 上的功能支持，包括 Always On 可用性组、SQL Server Agent 功能完善
  • SQL Server 2022：进一步优化了跨平台性能，增加了 Linux 上的安全功能和管理工具支持

跨平台迁移场景 ​

生产环境常见迁移场景 ​

  • Windows 到 Linux：降低硬件和软件成本，提高系统安全性和稳定性
  • Linux 到 Windows：利用 Windows 特有的功能（如 Active Directory 深度集成、某些第三方工具支持）
  • 本地到云容器：实现数据库的容器化部署，提高弹性和可移植性
  • 跨云平台迁移：从一个云平台的 Linux SQL Server 迁移到另一个云平台的 Windows SQL Server

跨平台迁移前准备 ​

生产环境评估 ​

在迁移前，必须对源数据库进行全面评估，这是确保迁移成功的关键步骤：

  1. 功能兼容性评估

    • 使用 Data Migration Assistant (DMA) 扫描源数据库，识别不支持的功能
    • 重点检查：SQL Server 代理作业、链接服务器、CLR 集成、分布式事务、全文搜索等
    • 示例：Linux 上不支持 FILESTREAM、FileTable、Change Data Capture (CDC) 等功能

  2. 性能评估

    • 收集源服务器的性能基线（CPU、内存、I/O、网络）
    • 根据数据量和查询模式，估算目标服务器的硬件需求
    • 考虑不同平台的 I/O 子系统差异，Linux 通常需要调整磁盘调度算法

  3. 数据量评估

    • 统计所有数据库的大小，包括数据文件和日志文件
    • 评估迁移时间窗口，选择合适的迁移方法
    • 准备足够的临时存储空间用于备份文件或数据传输

环境准备 ​

  • 目标服务器配置：

    bash
    # Linux 服务器准备示例（RHEL）
# 安装必要的依赖包
sudo yum install -y python2 curl krb5-workstation
# 关闭防火墙或配置必要的端口
sudo firewall-cmd --permanent --add-port=1433/tcp
sudo firewall-cmd --reload
# 配置 SELinux
sudo setsebool -P mssql_tcp_network_connect 1

  • 网络准备：

    • 确保源服务器和目标服务器之间的网络带宽充足
    • 配置防火墙规则，允许 SQL Server 端口（默认 1433）通信
    • 对于跨数据中心迁移，考虑使用 VPN 或专线连接

  • 权限准备：

    • 源服务器：需要 sysadmin 或 db_owner 权限
    • 目标服务器：需要 sysadmin 权限
    • 文件系统权限：确保 SQL Server 服务账号有足够的权限访问备份文件

跨平台迁移方法 ​

备份和恢复（生产环境首选） ​

备份和恢复是最可靠、最常用的跨平台迁移方法，适用于各种规模的数据库。

生产环境迁移步骤 ​

  1. 源服务器备份

    sql
    -- 生产环境建议使用压缩备份，减少存储和传输时间
BACKUP DATABASE SalesDB TO DISK = 'D:\Backups\SalesDB_Full.bak' 
WITH COMPRESSION, CHECKSUM, INIT;

-- 事务日志备份，用于最小化数据丢失
BACKUP LOG SalesDB TO DISK = 'D:\Backups\SalesDB_Log.trn' 
WITH COMPRESSION, CHECKSUM, INIT;

  2. 备份文件传输

    • Windows 到 Linux：使用 SCP 或 Rsync 传输文件
      bash
      # 从 Windows 复制到 Linux
scp Administrator@windows-server:D:\Backups\SalesDB*.bak linux-server:/var/opt/mssql/backup/
    • Linux 到 Windows：使用 PSCP 或共享文件夹
      powershell
      # 从 Linux 复制到 Windows
pscp -pw password sqlserver@linux-server:/var/opt/mssql/backup/SalesDB*.bak D:\Backups\
    • 传输后验证文件完整性：
      bash
      # Linux 上验证文件哈希
md5sum /var/opt/mssql/backup/SalesDB_Full.bak

  3. 目标服务器恢复

    sql
    -- Linux 上恢复数据库示例
RESTORE DATABASE SalesDB FROM DISK = '/var/opt/mssql/backup/SalesDB_Full.bak' 
WITH NORECOVERY,
     MOVE 'SalesDB' TO '/var/opt/mssql/data/SalesDB.mdf',
     MOVE 'SalesDB_log' TO '/var/opt/mssql/data/SalesDB_log.ldf';

-- 恢复事务日志，确保数据一致性
RESTORE LOG SalesDB FROM DISK = '/var/opt/mssql/backup/SalesDB_Log.trn' 
WITH RECOVERY;

优缺点分析 ​

优点：

  • 支持完整的事务一致性，数据丢失风险最低
  • 适用于各种规模的数据库，包括 TB 级数据库
  • 可以进行时间点恢复
  • 跨平台兼容性最好

缺点：

  • 迁移时间较长，特别是对于大型数据库
  • 需要足够的存储空间存储备份文件
  • 停机时间取决于备份和恢复速度

数据迁移助手 (DMA) ​

DMA 是 Microsoft 提供的官方迁移工具，适合中大型数据库的跨平台迁移。

生产环境使用要点 ​

  1. 评估阶段：

    • 运行 DMA 评估向导，选择 "SQL Server" 作为源和目标
    • 重点关注 "兼容性问题" 和 "功能建议" 部分
    • 生成详细的评估报告，用于修复不兼容问题

  2. 迁移阶段：

    • 创建迁移项目，选择源和目标服务器
    • 配置迁移选项：包括数据库对象、数据、登录名等
    • 监控迁移进度，处理可能出现的错误

  3. 注意事项：

    • DMA 只能在 Windows 上运行，但可以迁移到 Linux 服务器
    • 对于大型数据库，建议先迁移架构，再迁移数据
    • 迁移前关闭源数据库的应用程序访问，确保数据一致性

事务复制 ​

对于需要最小化停机时间的生产环境，可以考虑使用事务复制进行跨平台迁移。

生产环境配置步骤 ​

  1. 在源服务器上配置发布服务器
  2. 在目标服务器上配置订阅服务器
  3. 初始化复制并同步数据
  4. 在切换窗口期间，停止复制并将应用程序切换到目标服务器

跨平台迁移工具对比 ​

迁移工具适用场景优点缺点
备份和恢复各种规模数据库，要求数据一致性简单可靠，支持时间点恢复停机时间长
Data Migration Assistant中大型数据库，需要评估功能兼容性自动化评估和迁移，生成详细报告只能在 Windows 上运行
事务复制大型数据库，要求最小停机时间近实时同步，停机时间短配置复杂，维护成本高
BCP大型表的批量迁移迁移速度快，支持并行只迁移数据，不迁移架构
Azure DMS云迁移或需要托管服务自动化程度高，支持在线迁移需要 Azure 订阅，成本较高

跨平台迁移实施 ​

生产环境迁移流程 ​

  1. 预迁移阶段

    • 完成环境评估和准备工作
    • 修复 DMA 评估中发现的问题
    • 制定详细的迁移计划，包括时间窗口、回滚策略
    • 在测试环境中进行完整的迁移测试

  2. 迁移执行阶段

    • 执行最终的源数据库备份
    • 传输备份文件到目标服务器
    • 恢复数据库到目标服务器
    • 迁移登录名和权限
    • 迁移 SQL Server 代理作业和维护计划

  3. 迁移后配置

    • 登录名迁移：
      sql
      -- 从源服务器导出登录名脚本
-- 在目标服务器上执行脚本，注意密码哈希的兼容性
CREATE LOGIN app_user WITH PASSWORD = 'StrongPass123!' HASHED;
    • SQL Server 代理作业迁移：
      • Windows 到 Linux 迁移时，需要注意作业类型的兼容性
      • Linux 上不支持 CmdExec 作业步骤，需要转换为 PowerShell Core 或 Bash 脚本
    • 维护计划配置：
      • 重新配置备份计划，注意路径格式差异
      • 调整索引维护计划，考虑 Linux 上的 I/O 特性

跨平台迁移后验证 ​

生产环境验证清单 ​

  1. 系统验证

    sql
    -- 检查数据库状态
SELECT name, state_desc, recovery_model_desc FROM sys.databases;

-- 验证数据库完整性
DBCC CHECKDB('SalesDB') WITH NO_INFOMSGS, ALL_ERRORMSGS;

-- 检查文件位置和大小
SELECT name, physical_name, size/128.0 AS SizeMB FROM sys.database_files;

  2. 数据验证

    • 比较源数据库和目标数据库的表行数
    sql
    -- 创建行数比较脚本
SELECT t.name AS TableName, SUM(p.rows) AS RowCount
FROM sys.tables t
JOIN sys.partitions p ON t.object_id = p.object_id
WHERE t.type = 'U'
GROUP BY t.name
ORDER BY RowCount DESC;
    • 验证关键业务数据的准确性，如最近一周的交易数据

  3. 功能验证

    • 测试 SQL Server 代理作业是否正常执行
    • 验证链接服务器和分布式查询
    • 测试应用程序连接和核心功能
    • 验证备份和恢复功能是否正常

  4. 性能验证

    • 运行关键业务查询，比较执行时间
    • 监控系统资源使用率（CPU、内存、I/O）
    • 检查等待统计信息，识别性能瓶颈
    sql
    -- 查看前 10 个等待类型
SELECT TOP 10 wait_type, wait_time_ms/1000.0 AS WaitTimeSec
FROM sys.dm_os_wait_stats
ORDER BY WaitTimeSec DESC;

生产环境最佳实践 ​

1. 选择合适的迁移时间 ​

  • 选择业务低峰期，如周末凌晨 2-4 点
  • 提前通知业务部门，做好业务暂停准备
  • 预留足够的验证时间，建议至少 2-4 小时

2. 制定详细的回滚计划 ​

  • 保留源数据库的完整备份，确保可以随时恢复
  • 准备好回滚脚本，包括应用程序连接字符串切换
  • 明确回滚触发条件，如迁移失败超过预定时间、关键功能验证失败

3. 优化目标服务器配置 ​

  • Linux 服务器优化：
    • 调整磁盘调度算法为 deadline 或 noop
    • 配置合适的内存限制，避免 OOM 杀手
    • 优化网络设置，调整 TCP 参数
  • SQL Server 配置：
    sql
    -- 设置最大内存使用量
EXEC sp_configure 'max server memory (MB)', 32768;
RECONFIGURE;

-- 启用锁页内存（Linux 上自动启用）
EXEC sp_configure 'lock pages in memory', 1;
RECONFIGURE;

4. 监控迁移过程 ​

  • 使用 SSMS 或 Azure Data Studio 监控备份和恢复进度
  • 对于大型数据库，使用以下查询监控恢复进度：
    sql
    SELECT session_id, command, percent_complete,
       estimated_completion_time/1000 AS EstimatedSec,
       start_time, text
FROM sys.dm_exec_requests
CROSS APPLY sys.dm_exec_sql_text(sql_handle)
WHERE command IN ('RESTORE DATABASE', 'BACKUP DATABASE');

常见问题 ​

Q: 跨平台迁移后，应用程序无法连接到数据库怎么办？ ​

A：

  • 检查连接字符串中的服务器名称和端口号
  • 确认目标服务器的防火墙已开放 1433 端口
  • 验证登录名和密码是否正确迁移
  • 检查 SQL Server 配置管理器中的网络协议设置

Q: Linux 上的 SQL Server 性能比 Windows 差怎么办？ ​

A：

  • 调整 Linux 内核参数，优化 I/O 性能
  • 考虑使用 SSD 存储，提高 I/O 吞吐量
  • 优化数据库设计，包括索引和查询
  • 升级到 SQL Server 2019 或 2022，这些版本对 Linux 性能进行了优化

Q: 迁移后某些 SQL Server 代理作业失败怎么办？ ​

A：

  • 检查作业步骤类型，Linux 上不支持 CmdExec 作业步骤
  • 将 CmdExec 作业转换为 PowerShell Core 或 Bash 脚本
  • 验证作业使用的路径格式是否正确（Linux 使用 / 而不是 \）
  • 检查 SQL Server Agent 服务的权限

Q: 如何处理跨平台迁移中的字符集问题？ ​

A：

  • 确保源数据库和目标数据库使用相同的排序规则
  • 在恢复数据库时，可以指定排序规则：
    sql
    RESTORE DATABASE SalesDB FROM DISK = '/var/opt/mssql/backup/SalesDB.bak'
WITH RECOVERY, 
     MOVE 'SalesDB' TO '/var/opt/mssql/data/SalesDB.mdf',
     MOVE 'SalesDB_log' TO '/var/opt/mssql/data/SalesDB_log.ldf',
     COLLATE SQL_Latin1_General_CP1_CI_AS;

Q: 跨平台迁移中，备份文件太大怎么办？ ​

A：

  • 使用压缩备份选项，减少备份文件大小
  • 考虑使用备份拆分，将备份文件分割成多个较小的文件
  • 使用增量备份或差异备份，减少后续备份的大小
  • 对于超大型数据库，考虑使用事务复制或 Azure DMS 进行在线迁移

Q: Linux 上的 SQL Server 支持 Always On 可用性组吗？ ​

A：

  • SQL Server 2019 及以上版本支持 Linux 上的 Always On 可用性组
  • 需要使用 Pacemaker 进行集群管理
  • 配置过程比 Windows 上复杂，需要更多的 Linux 系统知识

Q: 如何迁移包含 CLR 集成的数据库？ ​

A：

  • 检查 CLR 程序集是否兼容 .NET Core（Linux 上的 SQL Server 使用 .NET Core）
  • 重新编译 CLR 程序集，确保兼容 .NET Core
  • 在目标服务器上启用 CLR 集成：
    sql
    EXEC sp_configure 'clr enabled', 1;
RECONFIGURE;

总结 ​

SQL Server 跨平台迁移是一个复杂的过程，需要 DBA 具备全面的技术知识和丰富的生产环境经验。通过充分的评估准备、选择合适的迁移方法、严格执行迁移流程和全面的验证测试，可以确保跨平台迁移的成功。

在实际生产环境中，建议优先考虑备份和恢复方法，因为它简单可靠，支持完整的数据一致性。对于需要最小化停机时间的场景，可以考虑事务复制或 Azure DMS。

随着 SQL Server 版本的不断更新，跨平台功能和性能也在不断优化。DBA 应该关注最新版本的特性，不断更新自己的知识，以应对日益复杂的跨平台迁移需求。