共计 11265 个字符，预计需要花费 29 分钟才能阅读完成。
随着互联网业务倒退和对容灾的需要，以及对拜访减速、多供应商老本管制等要求，互联网公司通过跨云部署和迁徙来更好的管制老本逐步成为刚需，跨云部署和迁徙也就成为运维圈子里的一个热门话题，而在此过程中，对运维和研发最头痛就是数据的迁徙和散布。
粤语中有一句谚语“上屋搬下屋，搬洒一箩谷”，意思是在各种各样的搬动过程中，或多或少都会随同一些资产的散失，这对于互联网业务来说是难以承受的。
通过对最近几次客户的多云部署进行总结，过程中存在的挑战有三点：
首先是数据完整性和一致性挑战。
其次是时效性，迁徙窗口期绝对无限。
再者是依赖性和各种拜访关系。
在大多数理论环境中都存在着利用依赖性，如何万千关系中理顺每条拜访关系也是让人望而生畏的事件。
跨云迁徙波及到的资源个别能够分成三大类：
第一类是 EIP、VPC、负载平衡和 NAT 网关这类网络服务，在跨云迁徙的过程中这些都会发生变化，而且是无状态服务，配置并不简单，对于这部分资源能够通过人工的办法对齐配置。
接下来是最为常见的云主机资源，这部分咱们能够通过 USMC 服务器迁徙工具来进行迁徙，对于一些例如 zookeeper 的服务，也能够通过人手同步配置的形式来迁徙。
而第三类就是包含数据库、文件存储和对象存储在内的一些存储服务，咱们能够通过 UDTS 等工具进行迁徙，而这正是本文所重点探讨的实际内容。
跨云迁徙
在这些客户的多云部署和迁徙过程中，如何在无限的业务暂停工夫里，将大量数据进行迁徙，并且保证数据统一，有了较多实际和积淀。为给大家提供无效的借鉴意义，花了一些工夫从实际总结了共性，将跨云迁徙划分为三个阶段：数据同步阶段、数据规整阶段（清理测试产生脏数据）和数据割接阶段 进行论述。
- 数据同步阶段
数据同步阶段次要是须要解决两个问题，其中最次要的还是跨云迁徙的外围，行将数据复制到新平台，并且让应用程序在新平台运行，其次就是利用实在数据对应用程序进行测试，确认应用程序在指标平台能够合乎预期地运行。咱们都晓得数据能够分为结构化数据和非结构化数据，用来存储数据的办法泛滥，无奈一一深入分析，所以笔者在这里只提供一些最常见的存储组件的迁徙实际，其它不同的存储组件各有不同，但也是能够参考这几个组件的迁徙逻辑来解决的。
上面将别离探讨 MySQL、文件存储和对象存储 的数据同步形式。
1.1 MySQL 同步
一般来说，咱们认为对于 MySQL 的同步，只有存量数据和增量数据都能做到统一，那么整个数据库的同步就是统一的。
而常见的 MySQL 数据迁徙形式有两种：一种是基于 MySQL 主从的形式，通过 mysqldump 记录下 binlog 地位，而后把这个 binlog 地位前的数据残缺导出，复原出一个备库，而后再从记录的 binlog 地位开始向主库追平增量数据。另一种就是 UDTS 工具，但总体上也是分为存量阶段和增量阶段，增量阶段的追及是将从存量同步发动的一瞬间开始往后的数据变动通过 binlog 的模式同步到指标库。
增量同步依附 binlog 实现，这是 MySQL 主从同步的根底，是咱们须要默认信赖的数据一致性机制，所以反过来说，如果咱们不信赖 MySQL 的 binlog 机制，那么其它 MySQL 的数据一致性机制也是须要狐疑的，包含数据落地的 fsycn()调用是否真正的把数据写入到磁盘和事务等等，这样就陷入了怀疑论了。当然咱们最终须要以数据校验后果来确认数据是否统一。
简而言之，跨云迁徙过程中 MySQL 的数据一致性次要就集中在存量数据的迁徙如何保障统一。
【案例】
以近期的 xx 公司迁徙到 UCloud 为例，其波及数据库实例有数十个，并且因为利用依赖的起因须要进行整体迁徙。在这案例中，如果采纳 mysqldump 的办法，那么这数十个数据库都须要通过导出、传输、导入和配置主从这样的操作，给整个迁徙工作减少了不少工作量。同时也正如很多商业智能利用须要将数据汇总用作剖析，他们业务零碎也有相似的汇总数据库，这种级联关系会让数据同步操作进一步复杂化。最终客户应用了 UDTS 作为跨云数据同步的解决办法，在保障数据统一的同时，DBA 只须要提供两边数据库的连贯和账号信息即可将数据同步工作托管，开释了精力去解决业务上的数据库工作需要。
1.1.1 数据同步
后面提到 MySQL 事务，在了解存量数据迁徙过程中的数据一致性时，须要先理解 InnoDB 为代表的事务引擎和 MyISAM 代表的非事务引擎。应用 MyISAM 引擎的数据表的确没有很好的数据一致性确保伎俩，存量数据只能对数据表加读锁并迁徙，在实现存量数据同步后，通过 binlog 追平，这样因为读锁会阻塞数据的写入，会导致业务的写入性能不可用，而且这一不可用的工夫视表中数据体量而定。
幸亏因为 MyISAM 的不灵便，理论互联网公司中曾经很少应用 MyISAM 引擎了。而 InnoDB 引擎因为它反对事务和行级锁的个性，在数据同步过程中对业务的影响小很多，但也因而对数据一致性的爱护办法也绝对简单，而这一套一致性爱护办法，外围就在于基于连贯 session 的事务隔离和基于 MVCC 的数据版本治理。
在存量数据同步启动的时候，数据迁徙工具会在本人对数据库的连贯 session 上设置事务隔离级别为 REPEATABLE READ，主动提交设置敞开，并且启动一个事务。这个时候，只有这个 session 上的这个事务最终没有隐式或显式的提交，这个 session 里看到的数据就不再发生变化，这样就能够保障存量阶段的数据都是同步工作启动那个霎时的数据，而不论其它 session 连贯会对数据库做怎么的批改。之所以能做到这样，是因为应用了 InnoDB 引擎的表有三个暗藏列，别离是行 ID DB_ROW_ID，行事务 ID DB_TRX_ID 和回滚指针 DB_ROLL_PTR，同时在雷同表空间内保护 undo log。
对于 insert 操作，会在表空间内写入一行数据，记录 DB_ROW_ID 和 DB_TRX_ID，但 DB_ROLL_PTR 为 null；对于 update 操作，则 undo log 是写入一行数据并且依据 update 语句更新字段数值，记录 DB_ROW_ID 和 DB_TRX_ID，同时 DB_ROLL_PTR 指向被批改前的数据行；至于 delete 操作，则复制数据到 undo log 中，记录数据删除位，并且将 DB_ROLL_PTR 指向原先数据。假如数据导出事务启动的同时，mysql 下面还有多个沉闷事务，这时候数据导出事务就是存量事务中 DB_TRX_ID 最新的一个，记为 Tmax，而这些事务中最老的事务 ID 为 Tmin，而从表空间中导出的每一行的数据为 T，通过这些事务 ID 和肯定的比拟办法，就能够判断读出的数据对于数据导出工作是否应该保留。
如果 T 比 Tmin 还小，或者 T 小于 Tmax 且不属于数据导出事务启动时的任何沉闷事务，阐明这一行数据在数据导出前曾经落地，如果还没有被删除则应该予以保留，而其余行则通过 DB_ROLL_PTR 从 undo log 中找到数据的上一版本，再通过上一版本的 DB_TRX_ID 再进行迭代判断。这一处理过程，就是 InnoDB 引擎的 MVCC 版本控制实现。
InnoDB 的 undo log 和 MVCC 实现
1.1.2 数据校验
数据一致性的要害，除了数据同步过程中的一致性保障，更加简略间接的伎俩是数据校验，只有比照过数据是统一的，那才是真正的统一。MySQL 数据校验的伎俩有很多，其中最经典的是 pt-table-checksum。
pt-table-checksum 会新建一个长期的 checksum 表，并且获取与主库有主从关系的所有从库信息。在校验工作时，工具会将该 session 的 binlog 格局设置为 statement，这样是为了利用 mysql 的 binlog 机制，将主库上执行的 sql 语句同步到从库去。接着工具会以 chunk 为单位从主库中读取数据和计算校验，将校验后果写入 checksum 表，这个过程会在一个语句中实现，随后这个语句因为对 checksum 表进行批改，会被同步到从库并且被从库执行。这样从库也会在本人的 checksum 表写入校验值。这个时候工具再从库中把 checksum 值读出，就能够与主库的计算值进行比照。
pt-table-checksum 的劣势在于使用方便，在经验了多年迭代也有十分好的可靠性保障。然而它的技术限度也是显著，那就是要求被校验的两个库须要是主从关系，同时也要求数据表有索引，因为 chunk 大小的计算是通过索引实现的。
【案例】
以近期的 xx 公司迁徙到 UCloud 为例，在数据同步的阶段因为数据库实例泛滥，须要缩小 DBA 的工作累赘而采纳了 UDTS 来进行数据库迁徙，然而这样就突破了源和指标库的主从关系，进而导致 pt-table-checksum 无奈应用。当然实际上数据导出 - 传输 - 导入 - 配置主从这样的机械化操作能够通过制作脚本来解决，然而为了迁徙而开发一套重用率不高的脚本代码并不明智。这时候 sync_diff_inspector 工具的劣势就体现进去了。
sync_diff_inspector 是 TiDB 团队为了不便用户在 MySQL 数据迁徙到 TiDB 后对数据一致性进行查看的开源工具，它不要求被校验的两个数据库存在主从关系，也没有对数据表索引的要求，甚至容许源库和指标库有不同的库名和表名，只有有明确的映射，就能够对数据自身进行校验。同时，在 sync_diff_inspector 发现某一块数据存在差别的时候，会通过二分比照的方法，最终找到理论不统一的行，放大了疑似不统一的数据范畴。
尽管这种绝对松耦合的环境下对数据进行校验，可能会呈现记录下一些数据不统一，例如主库的某个写入还没有齐全即时的同步到从库，这时候进行查看可能会存在数据差别，然而除非源库 insert/delete/update 操作十分频繁，否则个别冀望工具查看发现的差别不会太多。这时候只须要针对检查报告中的多数差别做第二次的手工或脚本校验，就能够确认数据一致性。当然如果一致性查看工具发现有较多数据不统一，咱们一是能够用查看工具生成的一致性修复脚本来修复一致性，也能够对通过对数据进行从新同步来实现。
须要注意的是，pt-table-checksum 和 sync_diff_inspector 都是对实体数据进行校验的工具，在数据量较大的状况下校验操作会绝对迟缓，不适宜在割接工夫窗口中操作。在理论我的项目中笔者测得一个 500G 的数据库的残缺校验耗时大概 28 小时。在割接工夫窗口中，个别通过 select max(id)或者 select count(id)对数据进行简略比照。
1.2 文件存储同步
1.2.1 文件同步
相比于 MySQL，文件作为一种非结构化的存储形式，迁徙办法绝对较少，也没有太多的数据一致性保障办法。与此同时，海量小文件的解决效率无限始终都是技术难题。
一般来说，文件存储的形式个别是硬盘本地存储或者基于 NFS 协定的存储服务，这两种存储服务中 NFS 存储的同步会更艰难一些。单个文件的同步是简略的，将文件复制到指标空间而后再对文件计算 md5 校验和，只有两边的数据是统一的就行。难点在于获知文件是否有发生变化。在 linux kernel 中能够利用 inotify 机制理解到本机对文件的批改动作。
inotify 利用在启动的时候除了初始化监听和创立事件队列以外，还会在文件系统操作的函数中退出 inotify hook 函数以将文件系统事件告诉到 inotify 零碎中，这些都是操作系统内核中的零碎调用。所以对于 NFS 而言 inotify 就生效了，因为相干调用都是本机环境中的零碎调用而没有通过网络，挂载了同一个 NFS 的多台主机没有机制理解对方在什么时候对文件进行了操作。
当然也有一些实现了分布式锁的文件系统，例如 vmware 的 vmfs 和 oracle 的 ocfs，能够共享文件系统数据的同时，通过锁机制来实现操作系统对文件变动的感知，但这是另一个故事了。
所以这时候，从业务中对呈现变动的文件进行记录就很有必要，因为实际上所有对文件的增、删、改都是业务所需的操作行为。所以在数据同步阶段，咱们仍然通过 rsync 或相似办法来同步数据，并且通过业务日志记录产生了变动的文件，最初在割接阶段解析业务日志，将呈现过变动的文件做最初的增量同步，从而实现数据追平。典型的组件能够参考 FastDFS。FastDFS 实现了相似 binlog 的形式，来记录每个 storaged 承受到哪些文件的更新，是哪种更新操作。在启动 storaged 之后，就能够实现主动读取其它同正本关系的 storaged 的数据来复原。例如大 C 示意源创立，小 c 示意创立正本，大 A 示意源追加，小 a 标识正本追加，大 D 示意源删除，小 d 示意正本删除等等。
理论生产环境中的 fastdfs binlog
1.2.2 文件校验
文件的校验，这里会波及到存储静默谬误的问题。咱们回顾硬盘坏道这个概念，就会发现硬盘本人也不晓得某个扇区目前状态是否良好，须要专门进行扫描能力确认。一个扇区写了数据，在短暂的运行中这一扇区成为了坏道导致不能读出数据，这时候利用不读取就不晓得底层数据呈现问题，这就是静默谬误。
要解决静默谬误的惟一方法是全链路数据校验：
在数据上传前，确认数据失常，生成校验和；
上传到某个存储服务之后，存储服务存储文件并且记录这个文件的校验和；
定期对数据进行巡检，从新计算文件校验和并且和记录值比拟；
取出数据时，也对数据进行校验和比拟，这样能力保障文件数据统一。
因而从技术层面来说倡议从一开始就应用带有全链路数据校验性能的服务，自建存储服务的全链路一致性也须要自行建设，否则在迁徙后只能通过 md5sum 这类工具对全副数据进行校验，确保迁徙前后数据没有差别，而不保障迁徙后的文件仍然是访客当初上传的文件。只管须要做这样的斗争，海量小文件的迁徙和校验仍然会造成迁徙工期的压力。
利用 md5sum 递归遍历整个目录，生成所有文件的 md5 后果，能够通过以下命令实现：
find ./ -type f -print0 | xargs -0 md5sum > ./my.md5相应的，能够通过以下命令对迁徙后的整个目录进行递归遍历校验。
md5sum -c my.md51.3 对象存储同步
1.3.1 数据同步
对象存储的数据同步和校验的复杂度介于数据库和文件存储之间，因为它基本上是基于 HTTP 协定的，镜像回源的性能就能派上用场了，即如果一个文件在咱们平台上不存在，那对象存储会尝试到源站去获取并保留下来。而绝对于 InnoDB 数据表这中结构化数据，对象存储的数据一致性保障还是绝对较弱。
目前市面上各种平台的对象存储服务对 S3 协定都有较好反对，而通过 ufile-import 工具就能够将其余反对 S3 协定的对象存储数据迁徙到 US3 中。尽管 US3 也反对镜像回源，然而在数据同步的刚开始时，不倡议将原平台 bucket 配置为回源指标之后就将 US3 作为服务入口来应用起来，因为这个时候 US3 bucket 中还没有数据，间接应用 US3 会造成大量镜像回源，一是从而导致整体拜访提早变大，其次也容易呈现拜访失败的状况。
ufile-import 工具与 redis 协同工作。在数据同步开始前，ufile-import 工具会通过 S3 协定的列表接口，将肯定数量的源 bucket 对象 key 以及这些 key 的同步状态记录进 redis 中。每当一个文件实现从源 bucket 的下载、缓存和上传到 US3 后，导入工具就会在 redis 中将数据标记为已同步。这样在 ufile-import 工具因为一些可能的起因，例如网络环境不好等问题故障挂起之后，只须要重启 ufile-import，它都能够从断点开始续传。
当实现一轮数据导入之后，就能够开始配置镜像回源配置了，这时候间接拜访 US3 也能失去不错的命中率。当然也能够抉择再运行一次 ufile-import 工具，如果这样操作须要留神 ufile-import 工具本来的性能是断点续传的，所以咱们应该把 redis 的内容革除。
然而间接清理掉 redis 再从新跑，ufile-import 工具的行为是从新加载文件列表并且重写写入 US3，这样会导致所有数据都要从新写一次，效率很低。在这个时候，咱们能够配置 ufile-import 工具为文件比对模式，在获取文件列表后将文件都通过 HEAD 获取文件大小，这时候只有将源 bucket HEAD 胜利，然而 US3 为 not found 或者文件大小不同的数据同步到 US3 即可。在理论的数据迁徙实际中，咱们能够更加灵便的应用续传和比对模式来进步工作效率。
【案例】
以近期的 xx 公司迁徙到 UCloud 为例，该公司的 CDN 和对象存储从金山云迁徙到 UCloud 的过程外面，有一个 bucket 中存在文件数量达到了 12 亿，将所有 key 存储到 redis 中并不合理，会导致 redis 数据收缩，进而对迁徙直达主机提出十分高的内存需要。这时候应该从一开始就应用比对模式对数据进行迁徙，进而防止不合理的 redis 内存应用。
1.3.2 数据校验
对象存储的数据校验方面，大多数对象存储都反对给文件提供 ETag 的 Header，且 ETag 的生成都跟原始数据有肯定关系，所以能够依据源平台的 ETag 计算形式，在下载到文件后对文件进行一次计算，看看 ETag 是否相符。而 ufile-import 性能自身也会依照 US3 的 ETag 计算规定事后计算咱们的 ETag，在上传胜利后比照 US3 返回的 ETag 和导入工具自行计算的值，来实现对数据的校验。
- 数据规整阶段
2.1 脏数据处理
正如后面提到，为了理解新平台中利用是否能失常运行，一般来说迁徙过程中波及到的利用测试都会尽量应用实在数据，甚至采纳流量重放的办法对新零碎进行测试，以便通过原平台环境中实在行为的后果来校验新平台用利用是否失常工作。在测试之后，新平台就会呈现脏数据，须要对其进行解决。实际上脏数据的解决也有两种思路能够应用。其一是回滚，就是在开展业务测试前先对数据进行备份或者记录还原点。
对于 MySQL 数据库能够备份 binlog 而后基于 binlog 进行回滚，也能够通过云平台能力利用备份间接回滚数据库。对于文件存储和对象存储，文件变更日志的作用就很显著了，所有变更过的文件从日志中解析进去之后从源头从新同步，这样能够防止所有文件的从新同步。当然也能够丢掉全副脏数据，采取跟第一章雷同的数据迁徙伎俩对数据进行从新同步，这样尽管慢一些，然而整个数据同步过程就是幂等的，可重复性更强。两种脏数据的解决形式能够视乎数据量灵便采纳。
2.2 保障数据一致性
在割接筹备阶段时候进行的数据同步，这时候所失去的数据就是割接和割接后的生产数据了，所以须要通过肯定的伎俩，保障数据的继续同步，同时防止数据被意外批改。上面说说几种保障的方法。
2.2.1 基于用户的数据库只读
对于 MySQL 而言，通过对数据同步和业务设置不同的账户，并且对不同用户调配不同的权限，这简直是最简单易行的实际形式。设立数据同步账户，赋予增删查改权限和 DDL 语句的权限，这样能够满足存量和增量数据同步的须要，而后将数据同步账户严格控制只配置给 UDTS 数据同步工具和 sync_diff_inspector 数据校验工具。而对于业务利用的配置文件，或者记录到配置核心中的配置，下面所应用的数据库账户就只调配 select 语句权限，这样就能保障业务利用、脚本或者各种定时工作都无奈对数据进行更改。而且这样做还有一个益处，对于一些没有实现数据库重连逻辑的业务利用，这时候数据库是能够失常连贯的，这意味着在割接的时候不须要重启利用，而是只须要调整 MySQL 中业务账户的权限。
对于一些场景，不重启对于割接过程来说是十分重要的。例如因为分布式框架的引入，对象和办法能够轻松的通过 RPC 获取，这时候业务团队也专一于业务的实现，疏忽了底层重连机制的实现。后果就是利用零碎成为了一个分布式的紧耦合零碎，主机 A 上某个过程的失常运行须要依赖主机 B 上过程的失常运行，而且 B 还不能轻易重启，因为重启后 A 不会重连。这时候如果利用不必重启，那意味着清理脏数据后，利用放弃以后的运行状态即可，而不是考察所有利用的启动程序，在割接时确认数据同步后再按程序一一启动，这样对于割接后的业务稳定性和割接操作复杂度都是大有裨益的。
通过数据库只读来保障数据一致性的形式受限会比拟多。MySQL 有基于用户的只读办法，与此同时 redis，sql server，mongodb，Elastic Search，文件存储，对象存储等等组件又有各自不同的只读办法，在组件数量和品种减少当前，这种操作形式的劣势会逐步丢失。所以对于数据库数量在数十个，且只有多数几款数据库利用的时候，数据库只读会是一个很有劣势的数据一致性保障办法。
总结一下，数据库只读的形式实用于 MySQL 数据库且实例数量不多的状况，例如整体迁徙以模块化形式进行的状况。另外对于须要尽量减少利用重启操作的零碎能够优先思考。
2.2.2 完结利用过程
后面提到，在一些利用零碎里重启利用并不是易事；那天然就有一些利用零碎，重启造成的困扰并没有那么大，能够绝对自在的重启利用。实际上对于一个零碎而言，会有三类程序可能对数据存储进行批改，别离是应用程序和操作系统定时工作脚本，对于数据库而言还须要多加一个定时工作。只须要保障这三类程序都是进行的，那么就能够保障没有同步服务以外的程序对数据进行批改，从而保障数据一致性。
通过这种办法来保证数据不被意外批改的劣势在于他是广泛实用的，不论提供存储服务的是数据库或者目不暇接的各种存储服务，只有过程停了数据就不可能被批改。然而这种解决办法的限度也是很显著的。首先就是利用能够随便重启。更重要的是在分布式环境上面，须要具备批量的启动或者敞开应用程序，以及批改操作系统定时工作的能力，不论是基于 ansible 或者其余形式，除此以外也须要确保生产环境中应用程序和脚本的统计是正确的，也就是说所有应用程序和脚本都是运维和开发独特通晓的。例如运维为了短时间不便，编写脚本作用在生产环境的数据而不被其余共事所理解，那在进行利用的时候天然也不会被思考到。
总结来说，完结应用程序的形式适宜利用能够各自独立启停，且生产环境利用、脚本和数据库定时工作都齐全统计分明明确的状况下应用。
2.2.3 ACL 网络隔离
通过 ACL 对网络数据存储服务做隔离是一个操作上绝对比较简单的办法。简略来说，就是在网络环境上配置 ACL，容许数据同步服务连贯存储并且禁止其它利用主机连贯。这种办法的劣势在于规定的套用和解除都绝对简略，在数据同步是间接对一整个 VPC 子网失效，在割接时候又只须要在管制台上解除，对整个子网的存储服务做到批量管制。而且相比于数据库只读和完结利用过程，这两种办法都依赖于运维团队对全零碎所有细节的把握，通过网络 ACL 进行隔离则能够疏忽利用零碎细节，而且对所有基于网络的存储服务都能笼罩，能够说齐全具备了后面两种数据一致性保护方式的长处。
当然 ACL 网络隔离的办法也有它的实用场景限度。其中最次要的是这个办法的施行要求运维团队对各个子网的性能划分是清晰明确的，网络入口、业务利用和数据存储别离在不同的子网，所以如果利用习惯了大二层的部署形式，那么网络 ACL 的批量治理劣势就会大打折扣。其次，因为对于利用的网络中断，所以对于没有重连机制的利用，也网络从新开明后仍然须要重启利用。最初就是这一办法对于不走网络的利用是无奈限度的，例如云硬盘本地存储，这种状况须要以挂载云硬盘的主机为单位去思考网络隔离。
通过对下面几种保障数据一致性办法的理解，其实咱们能够发现这几种办法其实并没有互相抵触的点，能够灵便组合来匹配更多理论环境的要求，例如同时应用完结利用过程和 ACL 网络隔离。
【案例】
在 XX 公司的跨云迁徙工作中，有几个条件是在后期调研中发现的。首先是数据库实例数量泛滥，源库和指标库既有自建的也有云平台产品，具体操作形式各有差别；其次是数据存储服务品种泛滥，除了 MySQL 以外，还有 MongoDB、SQL Server、NFS 存储、Elastic Search 等，一一组件去设计读写 - 只读切换的逻辑须要运维人员很大的精力投入；再次，指标系统对存储和利用有比拟好的网段划分，尽管组件泛滥，然而至多都在雷同子网内，适宜应用 ACL 来隔离；最初就是，利用方面也的确没有读写 - 只读的切换开关，而且也没有实现重连机制。所以，在实际操作过程中，笔者应用了完结利用过程和 ACL 网络隔离的双重保险，因为利用不具备重连实现的状况下，割接测试前利用至多须要重启一次的，ACL 和完结利用的限度都会被承受，与此同时 ACL 隔离也补充了完结利用的覆盖面，从网络层面保障不会有数据同步组件以外的零碎连贯到数据存储层面来进行操作。
- 数据割接阶段
3.1 数据校验机会
不论是整体割接，还是以业务模块为单位的割接，工夫窗口大小总是无限的，而且从业务角度也心愿割接窗口越小越好。
数据校验最早应该在实现数据规整后才启动，这一点应该是能够简略了解的，因为数据规整前的数据不用作割接后投产，没有校验价值。而在后面数据校验章节中提到，数据校验分为两种，一种是 sync_diff_inspector 这类实体数据校验，另一种是 select max(id)这类元数据校验，两种办法并不抵触，在理论工作中能够灵便安顿来缩小对割接工夫窗口的压力。
【案例】
以近期 XX 公司迁徙到 UCloud 我的项目为例，割接工夫只有凌晨 12 点到早上 6 点的 6 个小时，两头须要进行利用配置和业务测试，留给数据校验的工夫不多，所以早在数据割接之前就启动了 sync_diff_inspector 对实体数据进行校验。后果数据校验工夫和成果都如前意料，最大一个 500G 数据库的实体数据校验破费了 1 天多的工夫，同时多个数据库的校验也发现了大量的不统一，这一部分不统一通过人工比照后发现发现也理论统一。随后在割接过程中进行元数据校验，后果随着音讯队列实现生产和定时工作完结，两边的 select max(id)或者 select count(id)后果最终统一了。
3.2 割接与回滚
在割接阶段，不得不思考的一个问题就是回滚，在割接过程中发现数据的确呈现了不统一，这时候须要对不统一的范畴做正当的评估。如果在割接工夫窗口中的元数据校验如果发现不统一，这时候最理智的解决伎俩就是回滚，而保障原平台没有脏数据则是回滚的根底。
【案例】
以 xx 公司迁徙到 UCloud 为例，在托管 IDC 迁徙到 UCloud 混合云的过程中，因为业务依赖较少，所以采纳了能够麻利割接和回滚的业务模块迁徙形式。在这一案例的割接实际中，运维团队不仅在为数据库设置了只读，而且也在业务利用中嵌入了只读开关，只有通过配置核心公布开启只读开关即可失效。在数据库只读后就参考数据同步阶段的数据校验形式，对数据或者元数据进行校验，最初在确认利用的读取性能都失常当前再解除指标库的只读，凋谢业务。在这样的案例中回滚也是绝对简略的，如果发现利用的读取性能异样，这时候只需将利用重新部署回原平台，启动和解除数据库只读即可。
而对于须要进行整体割接的工作，割接过程相比于模块化的割接会简单一些，然而与模块化割接的机理大同小异。在割接过程中先通过停用负载平衡、设置 ACL 的形式进行业务入口，期待音讯队列实现生产数据落地以及定时工作运行实现，而后参考割接筹备阶段的办法对原平台数据进行爱护。在实现原平台的数据封存后，须要期待同步工作最终实现同步以及对数据进行校验，具体的数据校验办法是参考后面数据校验章节实现的。在确认两边平台数据统一后，就能够进行同步，在新平台启动利用和进行内部测试。
至于回滚操作，自身也是有工夫边界的，当新平台业务入口做了灰度凋谢后就不能进行回滚操作了，因为这时候有很大机率真正的客户数据曾经写入到新平台，然而这部分新数据又没有同步回原平台，这样两边数据就是不统一的。
然而一般而言，只有保障迁徙两边平台数据是统一的，应用程序大多是利用状态或者代码逻辑问题，绝对可控。
本文由 UCloud 华南架构部团队成员创作
如有疑难或征询，欢送留言探讨！
