数据库不是孤立地运行的，而是与周边有着千丝万缕的联系。前阵子参加一个活动的时候，一位大咖提出“我开发一个数据库为什么要考虑兼容性，兼容性本身就不一定是合理的，我需要为客户提供一个完美的数据库，根本不需要考虑兼容性”。这是十分典型的互联网企业的思维，一切都可以完全扬弃，砸烂旧世界，才能创造更美好的新世界。而对于企业级市场而言，这种观点不一定适用，数企业级用户都有自己的历史，也都无法回避从Oracle将应用迁移过来的问题，避迁移后国产数据库依然要和Oracle之类的国外数据源交换数据，因为一个小而美的RDBMS并不能解决所有的问题，围绕着数据库核心有大量的工作要做，这也是前几天我的文章中表达的观点。在信创数据库替代工作中，一个绕不过去的问题就是系统切换。而数据库迁移切换中不可避免要考虑到停机窗口的问题，最短的停机窗口是最佳选择。要实现最短停机窗口，逻辑复制是最佳的选择，但是如何保证逻辑复制数据的一致性，需要有高效快速的校验工具。
系统切换后如果真的出现了一些意想不到的问题，能不能通过一些技术手段快速做出决策，在无损或者可控的数据损失的情况下立即回退也是用户十分关注的问题。因此在数据库切换时需要具有双向复制甚至并行运行的能力，这其实对复制工具与数据校验工具提出了很高的要求。今天在我推荐的稿件是来自于人大金仓在数据库迁移切换方面的解决方案分享，希望这篇文章对大家有所启示。以下是稿件的正文。面对日益剧增的数据库迁移的需求，用户希望在有效保证数据完整性及业务连续性的情况下，解决平滑迁移和应急回退的难题。
作为数据库领域的国家队，人大金仓围绕用户需求，打造不停机迁移+双轨并行等一系列解决方案（点击此处了解更多），低难度、低成本、低风险，平滑地实现了国产数据库的迁移。
目前，针对业务“0”停机，需要以更短的时间同时校验存量与增量数据这一新难题，人大金仓以领先技术护航全周期数据一致性，决定将“数据一致性”保卫到底。
人大金仓分以下三个阶段，保障从数据迁移到数据库切换的全过程，使增量数据校验与数据实时同步开展，在数据库切换前即可在线完成数据一致性确认和修复，大幅缩短数据库切换的耗时。
应用从Oracle切换到KES数据库前，Oracle为业务主库，采用存量+增量校验，确认生产割接前Oracle->KES的数据一致性。
应用切换到KES为业务主库后，在KFS实时同步增量数据到Oracle的基础上，并行运行增量校验确认KES->Oracle的数据一致性。
试运行过程中，可能会有应急演练、应用业务异常的情况，需要应急回切为Oracle为业务主库，切换完成后，采用增量校验保障Oracle->KES数据一致性。
项目背景：存量数据40G，增量数据每分钟约5.12 M。
1.使用金仓全周期数据一致性保证方案前，校验方式和步骤为：
数据库切换全程总计耗时30分钟。
2.使用金仓全周期数据一致性保证方案后，校验方式和步骤为：
数据库切换全程总计耗时2分钟，极大缩短因切换数据库导致的应用停机时间。
人大金仓为护航全周期数据一致性使用了两种“黑科技”：KFS不停业务存量数据校验技术和KFS基于KUFL的增量校验技术。在不停机迁移完成后，Oracle及KES端业务正常运行，KFS基于快照查询Oracle及KES的数据，校验数据的一致性。 启动KFS增量数据实时同步后，并行运行增量校验，获取增量数据。通过增量数据中的关键信息查询备份库的数据，校验增量数据的一致性。增量校验相较于全量校验的优势是，支持在有业务的情况下校验，且仅需要校验部分数据。
KFS拥有对存量和增量数据校验、修复方面的行业领先技术。让我们来看看KFS与国外同款工具在数据校验修复能力方面的对比：从对比结果可以看出，金仓KFS在支持的数据源丰富度，数据校验模块经济性和成本，不停机存量数据校验和增量数据校验方面以压倒性优势全面胜出。在数据库升级过程中，在保证系统”0停机”平滑切换的同时，金仓KFS的一系列迁移方案尽可能减小了对上层业务的影响，充分满足迁移过程中用户对业务连续性、数据全周期一致性、可随时应急回退的高需求，解除用户对新系统稳定性的担忧，确保用户数据安全无忧。
供稿：产品研发中心
