将群集从 SQL Server 2005 迁移到 SQL Server 2016

Question

我正在迁移 SQL Server 群集。我想听听成功迁移的注意事项。

生产集群的规格是：

1. Windows Server 2003 SP2 32 位。
2. SQL Server 2005 企业版 - 9.00.3152.00（内部版本 3790：Service Pack 2）
3. 包括所有数据库在内的磁盘空间约为 1.5TB。(IBM v7000)

目标集群的规格是：

1. Windows Server 2016 标准版 64 位
2. SQL Server 2016 标准 64 位
3. 与旧集群相同的磁盘，但速度更快（IBM v9000 闪存系统）

特别注意事项：

• 群集名称必须相同以避免应用程序、链接服务器和其他连接发生变化。我的意思是，我们必须使用不同的集群名称进行迁移，然后关闭旧集群并使用旧名称重命名新集群（我希望这很清楚）

此时我所做和测试的内容如下：

1. 使用 Windows Server 2016（具有不同的名称）创建和配置 Windows 故障转移群集
2. 配置 Active Directory 以允许集群创建对象
3. 将数据库从 MSSQL 2005 恢复到 MSSQL 2016，运行一些查询并探索对象。

还：

• 我按照最佳实践拆分了驱动器。
• 我们正在清理“超级用户”并为用户提供正确的权限。
• 设置和测试兼容模式为 130
• 大约 1 周前定义了备份策略以确保数据可用性

要做或考虑的事情：

• 将所有 SSIS 包下载到新项目并针对新集群进行测试。集群名称更改后，将 SSIS 更改为原始名称
• 迁移所有作业并确保它们成功运行
• 使用迁移数据库的测试应用程序
• 为指向 SQL Server 2000 数据库的链接服务器创建 ODBC 连接（是的，我们仍然使用 MSSQL 2000）
• 备份 Active Directory 以提供回滚点，以防集群名称出现故障（我们必须删除旧对象并创建一个新对象）
• 配置 SQL 复制。

Answer 1

这是我喜欢看到的问题之一。要增加迁移和升级成功，还有很多事情要做，看到这个问题让听到的人感到温暖。

您已经涵盖了很多需要考虑的事情，我将添加一些想法，但我期待看到其他答案以及来自其他人的更多想法。

我不包括你已经包含在你已经开始的伟大列表中的东西，我知道我会在我走的时候编辑和添加这个答案。

**我可能对你的方法有一个分歧：关于集群网络名称，为什么不创建一个新的集群名称并只使用 CNAME 将旧名称的连接指向新实例？这让您可以使用新名称，避免混淆潜在的冲突，使夜间直播更顺畅，并为您提供更清晰、更轻松的回滚。一旦您确定旧的可以脱机，我会采用 CNAME 方法并更改 CNAME。我可能一个人在这里，所以我欢迎支持该想法或不同意的评论。

在迁移方面，我看到了一些重点领域。如果您对要重点关注的阶段和大纲进行“概述”，就会想到：规划、迁移前步骤、迁移日、迁移后。我将在这里介绍其中的一些部分，我希望其他人加入并提出想法。

规划思路

因为您是从新硬件开始的。这是确保您正在考虑以前可能被忽视的所有最佳实践的绝佳机会。像：

1. 拆分您的驱动器。至少我很想看到单独的驱动器（您的里程也可能在这里有所不同，实际上取决于您的设置的性能配置文件）：

   • 操作系统（C盘）
   • SQL Server 二进制文件和系统数据库，不包括 TempDB
   • 用户数据文件
   • 用户日志文件
   • TempDB 数据和日志文件
   • 用于文件导入、数据暂存等的本地备份和/或其他驱动器

2. 当专门为数据文件和 TempDB 格式化驱动器时，请考虑使用 64KB 分配单元大小。（来源）

3. 现在是您清理一些可能存在的安全漏洞和缺陷的机会。寻求使用最佳实践和最少访问进行构建。

迁移前

迁移前要做的事情很多。立即想到的一些是：

1. 运行升级顾问。SQL Server 2016 在那里做了一些改进，它是一个单独的下载。查看可能存在哪些问题。
2. 对您的数据库进行更彻底的测试，以查看哪些中断以及哪些有效。进行测试迁移并进入 2016 (130) 兼容模式。并进行彻底的测试。如果您没有测试方法，您可以查看诸如分析活动和重播之类的东西，看看有什么中断。测试。测试。测试。
3. 获取有关群集和故障转移群集的 SQL Server 和 Windows Server 2016 文档。仔细查看清单和先决条件。
4. 确保您有良好的事务日志管理 - 为什么由于管理不善而迁移过大的 LDF 文件。
5. 确保您对数据库进行了正确的维护 - 特别是确保您正在运行常规 DBCC CHECKDB - 这是在迁移之前或作为最终迁移的一部分进行的一件好事，但您不希望第一次这样做在迁徙之夜寻找惊喜。
6. 确定成功标准并制定回滚计划（迁移到新的很棒，您可以简单地回滚任何 CNAME 更改、连接字符串并指向旧的）以防出现问题。并了解哪些问题构成回滚以及哪些问题您将在迁移后“留下来并发挥作用”。购买此列表。
7. 有一个非常好的备份策略。知道你可以恢复。知道您的备份文件在哪里等。
8. 查看所有服务器对象。你涵盖了很多。但不要忘记凭据、代理帐户、警报、维护作业、SP_Configure 设置等。PowerShell DBATools 脚本是一个真正可以帮助您记住事情的好工具。这些脚本可以帮助您迁移所有这些项目 - 包括具有正确 SID 的 SQL 身份验证登录名，但它们还可以帮助您在浏览所有模块时记住要迁移的内容。您可以在此处查看脚本。

迁移后立即

这里还有很多。并且可以添加“在迁移周”类别，也许有人会或我会稍后编辑和添加。

这里有一些事情会立即浮现在脑海中：

1. 进行烟雾测试/检查以验证一切顺利。
2. 如果测试证明可行，请将所有数据库上的兼容模式更改为 SQL Server 2016。我看到这被错过了很多。
3. 确保维护和备份到位。在数据库上运行迁移后 DBCC CHECKDB。
4. 确保您的作业正在运行。
5. 配置监控和警报，这样您就不会错过有关此服务器的警报
6. 一旦您对有限的测试感到满意，请关闭旧的并进行 CNAME 更改。