快速的未来正在你所在的城市举办活动。
加入我们参加 Redis 发布会
分享
遗留数据库迁移。这三个小字足以让 IT 专业人员胆战心惊，但其实不必如此！让我们来分解一下遗留数据迁移的过程，概述其优缺点，并重点介绍行业专业人员希望在将遗留数据迁移到高级系统之前就知道的一些注意事项。
对于负责将数据从遗留系统迁移到更高级环境（例如 云数据库）的 IT 团队而言，成功迁移会带来巨大的回报。然而，迁移失败的后果可能非常严重。虽然没有一种适用于所有情况的数据库迁移方法，但对于任何尝试迁移的人来说，有一些关键因素需要考虑，以便获得相对轻松的体验。让我们从概念和执行两个方面来探讨遗留数据库迁移。
数据库迁移是指将数据从一个数据库管理系统迁移到另一个数据库管理系统，或者从一个数据库管理系统的版本迁移到另一个更新的版本。此过程通常包含多个步骤，包括从源数据库提取数据，必要时对其进行转换以匹配目标数据库的模式，以及将其加载到目标数据库中。
数据库迁移跟踪 模式从其现有状态到新环境的受控传输。在任何数据库迁移中，历史数据都将从旧系统传输到新系统（通常是现代系统）。一些重要的目标包括保持现有功能的正常运行、优化性能以及提高可维护性。
对于 开源 和关系型系统（如 MySQL 和 Oracle 数据库）来说，在不影响数据完整性的情况下进行模式更改可能会很困难。众所周知，SQL 数据库会对数据进行压缩以使其符合其结构。迁移很常见，原因有很多——开发人员经常尝试使用新工具——但当应用程序及其数据存储都已过时，并且在整个组织中根深蒂固时，将数据从一个系统迁移到另一个系统会带来更多困难。通常，这些遗留数据库迁移伴随着从关系型系统（如 MySQL 数据库）到 NoSQL 或无服务器环境（包括 云）的转变。
旧应用程序依赖于旧的软件生态系统。即使遗留应用程序看起来可以正常工作——俗话说“如果没坏就别修”——生态系统也可能会失效。也许主机操作系统不再受支持。硬件跟不上。应用程序（及其数据）依赖于不再受支持的 API，并且无法有效地与更新的系统交互。或者你继承了一个代码和数据库设计非常复杂的应用程序……但了解该系统的程序员已经退休了。
有时，变更的原因是业务成功。随着用户群的扩展，数据量也在增长。必须为更多用户和更多数据做好准备，确保没有故障转移或 延迟，支持全球用户群，保持速度，并实时交付数据。
用例也会随着时间的推移而发生变化。请记住，Netflix 起初是销售 DVD 的。当一家企业开拓新的收入来源时，但遗留系统跟不上怎么办？旧数据库有时无法利用新架构的潜力。
此外，采用更新的技术还具有技术优势，例如利用遗留系统中不存在的功能。改进后的应用程序可以使用内存中多模型实时数据库实现更多功能。
每个数据库迁移都是独一无二的，但人们从第二个数据库发布以来就开始升级数据库系统了。明智的做法是吸取先行者的经验。
为了提供有关如何应对这一体验的可操作指南，我们征求了数十位执行过遗留数据库迁移的 IT 专业人员、开发人员和数据库管理员的建议。他们建议你在数据迁移清单中包含以下内容。（身份已模糊处理，因为个人的历史经验可能无法反映其当前雇主。）
在你开始之前，先了解新技术。你需要对使用新数据库充满信心。如果你遇到问题，你需要知道是遇到了技术问题，还是发现了自己的无知。
你需要了解在旧系统中是如何以及为什么以这种方式做事。你还需要了解新系统的功能和流程，然后才能开始迁移。只有这样，你才能将旧系统采用的方法与新系统中使用的功能和最佳实践相匹配。
这不仅仅是数据迁移。它也是一个解决问题型的迁移。
乐于尝试新方法。固守“老方法”会导致新系统设计不当。用户往往会将问题归咎于新系统，而不是迁移。
在你开始触碰任何数据之前，对每个查询进行建模，并比较它在旧数据库和新数据库中的使用方式。这可以帮助你在任何人在开始键入之前就发现白板上的问题。
有些数据不能很好地从一个应用程序映射到另一个应用程序。最好在整个团队都投入到项目之前，先找到解决这些问题的方法。
质量保证部门应尽早参与。他们需要解决数据完整性和访问数据库的新应用程序的挑战。他们习惯于思考所有可能出现错误的方式，并建议在出现故障时该怎么办。
你是否有一种方法可以确认数据在遗留数据库和新数据库中是否匹配？并且可以确保任何系统集成都能与旧的尚未迁移的应用程序和新应用程序正确地协同工作，而这些新应用程序启发了迁移项目。现在就考虑这些问题，而不是以后。
创建全栈集成测试，可以根据你的端点、API 等测试“之前”和“之后”的结果，以确保数据相同。这并不容易；针对 ID 和日期的细微更改可能具有挑战性。
对测试数据库运行测试，该数据库的配置与生产环境完全相同，或者尽可能接近。这意味着你需要创建这些测试。
如果系统不寻常，你可能需要安排时间来构建自定义测试框架。这可能很耗时，但经验丰富的数据库专业人员坚持认为，构建这些测试和工具有助于你在没有问题的情况下将表移动到不同的模式。
确保你的数据在当前系统中是最新的和准确的，然后才能将其迁移到新系统。数据审计有助于确保数据是最新的。软件分析师 Karen 说：“浪费资源迁移错误的数据会导致从一开始就将返工纳入流程。”
否则，你将以垃圾开始。此外，每个人都会责怪新技术，而不是数据质量。
在你清理数据之前，不要考虑迁移。“否则就是马虎，会导致从一开始就将返工纳入流程，”Karen 说。“这在将任何应用程序迁移到云时都是同样重要的第一步。”
“始终消除多余的数据，”Karen 说。“确认你只请求和发送运行流程所需的数据。”
找出你实际上需要迁移多少数据以及在什么时间范围内迁移。可以分阶段处理遗留数据库，或者使用临时工具——尽管这可能会带来其他问题。
此过程可能是一个独立的项目。你的组织可能需要确定数据保留合规性要求，特别是对于历史数据。在将数据从一个数据库迁移到另一个数据库之前，请务必处理这些问题。
数据是每个组织的生命线。不要忽视设计或保护：安全性、备份和验证。
确保你有迁移开始之前的备份。“我见过一些公司试图回滚到备用服务器，结果才意识到他们已经复制了错误数据，”一位饱经沧桑的数据库专家说道。
在出现问题时制定一个回滚计划。在开始进行数据库更改之前，请测试该计划。
你可以浪费时间。但你绝不能丢失任何数据。
数据迁移中遇到的挑战通常不是技术挑战。而是业务挑战。
遗留数据库迁移项目并非易事。一位经验丰富的开发人员建议，如果你发现自己没有足够的政治资本来改变流程，“现在就找其他项目，否则你会浪费 18 个月的时间，并患上压力引起的疾病！”
一位懂得识别危险信号的 IT 专业人士表示，如果你在任何迁移前的任务中遇到管理层的阻力，请注意。务必获得书面确认，在从备份恢复时，可以接受多少数据丢失。预计你会被告知，“任何数据丢失都是不可接受的！” 这位 IT 专业人员建议，你就告诉他们没问题，“但列出开发工具所需的 时间和成本，以确保 (并测试) 从新系统中将数据回放到备用系统是可靠的。通常，你会发现他们对数据丢失更加宽容，或者他们会识别出必须保留的一组数据。”
一切准备就绪后，就该进行实际迁移了。请务必注意以下建议。
建立一个表格，将每个插入行的遗留标识与新标识进行映射，以便所有操作都可审计。你必须能够将任何后续的子行映射到相应的父行。
不要一次性迁移到目标数据库，也就是所谓的“大爆炸迁移”。这是 DevOps 专家 Andy 的教训。他后悔在团队从 SQL Server 数据库迁移到云数据库时选择了这种方法。他说：“我们承担了太多，最终未能实现无缝迁移。”
Andy 希望他当时将旧数据库连接到新数据库，然后实时同步每个数据片段，一点一点地进行。这样他就可以尽可能地使用新数据库，并可以轻松地切换回旧数据库，并强制对数据进行优先级排序。他承认：“这里的风险是迁移速度太慢，最终数据库无法完成迁移。” 一个总体的攻击计划和一些截止日期非常重要。
Joseph 的团队负责将 Microsoft SQL Server 迁移到云，他也警告了同样的陷阱，但也强调了平衡的重要性。他说：“你需要分批进行迁移，但你不能迁移太慢，以至于遗留 SQL Server 和新的云数据库都没有获得更新的数据。”
数据已转移到新数据库，万岁！你完成了，对吧？错！
负责一家小型家族企业承包商的计算机系统的 Sue 表示，验证迁移前后数据是否匹配。她公司的计算机数据可以追溯到 1985 年，自那时以来至少进行了四次主要的数据库迁移。
根据遗留数据库迁移的紧迫程度，并行运行系统可能是有意义的。数据库管理员 Zack 建议：“在数据层中注入一个 shim，以便在遗留数据库上的任何活动也运行在新数据库上。该层可以在将结果返回给应用程序层之前比较结果。” 这种方法允许你将新旧数据库并行运行一段时间，并在你切换之前确认新数据库运行正常。
Guillermo 回忆道：“我们迁移后确实遇到了一些问题。有些问题需要我们更多地了解新系统，例如监控、跟踪和遥测。有些问题需要我们将软件升级到比我们选择的版本更新的版本，这意味着要阅读补丁说明。我们还需要创建一些自定义日志分析工具。”
一位数据库专家专门从事遗留数据库迁移工作。对 Elena 来说，一个关键因素是为新系统创建专门的测试环境（如果可能，包括前端和后端），以便利益相关者可以登录并查看测试环境中的结果。
确保利益相关者签署接受确认。Elena 建议：“永远不要运行没有在测试环境中测试和批准结果的生产代码。这可以让利益相关者对结果负责。”
Elena 说，如果你遇到无法翻译的数据，不要仅仅说不可能。“与利益相关者坐下来，询问他们为什么需要这些数据，并让他们向你介绍他们将如何使用这些数据。一旦你了解了实际的业务用例，你几乎总能找到解决方法来完成他们的需求。”
自定义系统并不总是必要的。至少，你可以基于现有的迁移部署策略、工具和产品进行构建。
从遗留系统迁移到目标数据库的任务类似于搬到新家的物理搬迁。在这个比喻中，数据摄取就像搬运工，他们包装好你所有的资产，安全地存放物品以便运输，交付你的货物，并装饰新地方（如果你进行了正确的数据审核，就是这样）。
使用 数据摄取 迁移到云时，了解 6 种加快应用程序速度的方法。
也许企业需要一些 A 列，也需要一些 B 列。将本地系统完全迁移到新系统并不适用于所有情况。在现有堆栈中引入 缓存 层，以创建 混合环境，从而降低将所有操作完全扩展到云的成本。
详细了解 企业缓存：大规模缓存策略。
值得吗？大多数情况下，是的。
一些遗留数据库依赖于第三方技术——这种技术可能随时变得过时，从而使数据的安全性处于危险之中。但除了过时系统和被供应商锁定带来的危险之外，还有更多问题。
阅读 采用云迁移防范数据层的五大优势，以了解云的全部价值。
遗留数据库迁移的第一步是试水。请记住，这不是非此即彼——使用 Redis Enterprise Cloud 免费在实时云环境中试用数据。
需要了解其他相关概念的定义？请查看我们的 术语表部分。
