众所周知，很多公司的数据仓库是构建在MPP架构（大规模并行计算，Massive Parallel Processing）的数据库之上。MPP架构特征：数据以分布键分布式存储（本地化）；分布式计算；横向扩展，支持集群节点的扩容；Shared Nothing（完全无共享）架构。扩（缩）容和数据重分布是MPP数据库普遍存在的运维管理操作。弹性伸缩本身也是云原生数仓的重要功能之一，阿里云的ADB PG实现了弹性伸缩，但大型数据仓库的扩容往往不能完全交给自动化任务，为什么呢？本文就一个客户的扩容方案进行说明。引子：我们时常讲”我们要把阿里巴巴最佳实践和行业业务结合为客户做数字化转型“，本文涉及的案例就是这个方向的实践。1. 背景介绍1.1 产品扩缩容功能众所周知，很多公司的数据仓库是构建在MPP架构（大规模并行计算，Massive Parallel Processing）的数据库之上。MPP架构特征：任务并行执行；数据以分布键分布式存储（本地化）；分布式计算；横向扩展，支持集群节点的扩容；Shared Nothing（完全无共享）架构。大致架构图如下图1：ADB PG的MPP架构示意图从以上特征可以看出，MPP架构的数据库如果遇到容量不足，通常是走Scale Out的扩容，即在计算节点层面增加服务器并部署Segment。由于数据是本地化存储在各个Segment上，新增加的Segment如果要均衡承载数据和计算，势必涉及已经在原集群“均衡分布”的数据，需要resharding，即数据重分布。因此，扩（缩）容和数据重分布是MPP数据库普遍存在的运维管理操作。弹性伸缩本身也是云原生数仓的卖点之一，我们的ADB PG也实现了弹性伸缩，但大型数据仓库的扩容往往不能完全交给自动化任务，为什么呢？本文就一个SKA客户的扩容方案进行说明。1.2 案例场景本文的案例介绍缩容、扩容、数据重分布的方案，是3个大步骤的方案组合。客户的DBstack集群上有5个实例，扩容的原因是实例5的空间不足。实例5承载最大的数据仓库，扩容前数据360T，上线前还有40T的额外空间需求，如果空间不能扩大，业务无法上线！由于是新业务带来的空间需求，那只有扩容这条路了。扩容前需要缩容的原因是客户已经没有空闲服务器了（即便客户有空闲服务器，也会有license限制，这是商务问题，也比较难解），只能释放部分实例的服务器资源给实例5；经过评估，实例5需要扩容N台服务器，实例1-4的资源消耗不高，可以合并这4个实例，实现服务器缩容，释放服务器资源给实例5。缩容也有两种方式：一是每个实例缩容部分机器，达到实例5的N台机器扩容需求；二是直接释放某个完整实例的机器资源。经过评估，我们认为方式一太复杂、可行性较低，选择了方式二：把实例1按databse级别拆分后合并到实例2-4，所以实例1在整个DBstack集群中相当于做一次缩容，把机器资源释放出来再扩容到实例5。所以整个案例是先缩容再扩容。2. 整体实施方案2.1 方案概览如上所述，该案例的方案分3个大阶段：缩容（实例1拆分和迁移、释放服务器资源），扩容服务器，数据重分布。大致的示意图如下：图2：整体方案示意图2.2 方案执行计划由于ADB PG承载了生产数据集市和数仓业务，而整个实施方案比较复杂，涉及的库较多，有大有小，为了保证不影响业务，我们大致按照“灰度发布”的策略步步为营。每个大的方案先试点小库或小表的实施，通过实施把该踩的坑填平，业务稳定后，再扩大到其他库表。整体方案实施历时2个月，计划执行情况如下图：图3：整体实施计划执行图下面我们按照前后逻辑关系，详细讲述下方案。3. 缩容方案缩容的第一步是做实例合并，实例合并就必须要做数据库的迁移。大型数据仓库，每个库基本都10T起；数据集市也在1T以上，因此，数据迁移方案选型非常重要！3.1 数据库迁移方案选型跨ADBPG实例的数据库迁移的方式，有如下几种常见的数方案: pg_dump + pg_restore, GPTransfer, GPcopy，数据导出OSS再导入、DTS等方案，详细对比如下：表1：数据库迁移方案选型编号
方式
优势
劣势
最佳实践
1
pg_dump + pg_restore
①原生的备份恢复方式，最稳定；②操作简单，不需要过多集群间配置③表结构迁移非常方便
① 导出和导入都需要过adb的master，master会成为性能瓶颈；② 速度慢，导出大概200MB/s, 导入大概50MB/s左右；
<300G的库，也可以采用此方法；表结构迁移利器。
2
GPtransfer
① 支持segment之间直接迁移数据；② 数据最终写入是segment层面gpfdist并行外表装载，速度快，大概600MB/s；③ 经过集团内大数据量的迁移检验。
① 集群配置相对复杂（调整实例间通信机制、集群内租户资源、并发度等）；② 每张表都要启动gpfdist，不适合迁移含大量小表或空表的数据库
小表或空表最好不要超过2000个；超过2000个小表，要考虑采用方式1迁移小表。
3
GPcopy
① 支持segment之间直接迁移数据，并且不写FIFO管道文件（相对gptransfer）；② segment之间直接执行copy命令进行拷贝，速度更快；
① GP5.9新增特性，稍微欠成熟；② 没有大量迁移实践背书。
配合数据校验工具使用，防止新工具带来数据一致性问题
4
数据并行导出OSS再导入
① 并行导出，速度快；② 配置简单，数据落地OSS，操作过程可控
① 需要客户也购买和部署了OSS；② 导出和导入的调度，得开发脚本
客户有OSS存储，且希望表级别精细化迁移和调度的场景
5
DTS
① 进度、状态可视化，更直观、更安心
① 不支持ADB PG之间的迁移，需要产品做开发
不适用
该案例中，客户没有OSS，因此排除了方案4（方案4在政务客户也应用过，速度大概200MB/S）；方案5的DTS支持迁移ADB PG的研发投入大，后续使用场景不多（有gptransfer和gpcopy），产品ROI不高。由于gpcopy工具较新，交付与产研沟通后决定用gptransfer； 由于该客户很多分区表，决定以pg_dump(restore)迁移表结构+gptransfer迁移数据方式实施。另外，gptransfer迁移方案，在阿里内部的聚石塔一路向北项目时也实施过，属于阿里巴巴集团内部最佳实践。因此，这也是阿里把内部最佳实践和行业龙头业务数字化转型的一次有机结合。3.2 迁移方案介绍整体采用pg_dump迁移表结构，gptransfer迁移数据。gptransfer原理简介图4： gptransfer的工作原理图gptransfer底层使用的是gpfdist方式装载数据，gpfdist是GreenPlum生态一款高效的数据装载工具；gptransfer与传统gpfdist装载文件的方案有一个不同点，是gptransfer会把数据写入到FIFO管道（而不是文件），gpfdist server允许管道中的数据被gpfdist client（这个场景中就是dest 实例的segment）远程读取。3.2.1 两个ADB实例的通信互信源ADB实例和目标ADB实例要进行数据传输，网络必须通；数据库层面用户必须有登录、创建gpfdist外表的权限。● 要点1. source的segment和dest 实例的segment之间网络要打通。如上图4所示，source segmentgpfdist 启动HTTP服务，dest实例需要去主动访问HTTP服务拉取数据，所以两个集群的segment网络要通，且gpfdist server的端口（一般9000）能访问。DBStack集群内不同实例的各个segment的网络一般都是通的。● 要点2. source master 和 dest master之间要求hostname互相可访问，且ssh互信#登录source master
~ ssh-copy-id dest_master_hostname● 要点3. gptransfer用户在dest 实例上有创建gpfdist 外表的权限gptransfer会自动先创建外表然后执行插入数据到目标实例的操作（ 上图右侧所示：INSERT INTO SELECT * FROM GPFDIST），因此要给gptransfer用户放通白名单，以及开通创建gpfdist外表权限。为了简单，建议直接使用adbpg的管理员用户执行迁移，放通管理员远程登录的权限。#先增加管理员远程登录dest master的白名单（迁移结束后恢复配置）
host
all
adbpgadmin
10.110.0.0/16
trust
# 重新加载配置生效
~ gpstop -u3.2.2 调整租户资源因为迁移数据本身也需消耗大量资源，而平时CPU、内存等资源都是给生产租户（pro_group）在使用，因此迁移数据库时，需要把资源向迁移用户倾斜。该案例租户的资源是通过资源组resource group来管理，迁移用户是管理员，属于admin_group。因此，就是调整资源组的资源分配。● 要点一：CPU、内存使用调整○ step1. 调低生产租户的CPU、内存alter resource group pro_group set CPU_RATE_LIMIT 5;-- 原值15
alter resource group pro_group set memory_limit 5;-- 原值15○ step2. 调大管理租户的CPU、内存alter resource group admin_group set CPU_RATE_LIMIT 50;-- 原值5
alter resource group admin_group set memory_limit 50;-- 原值5● 要点二：调大管理租户的并发限制并发控制要单独提一下，容易忽略。实际上gptransfer是并发迁移数据的，如果限制了迁移用户的并发，gptransfer的连接会触发ADB并发控制的阈值而中断。alter resource group admin_group set concurrency 80; -- 原值10● 要点三：调整rds_max_super_conns 超级用户连接数限制该参数rds_max_super_conns 默认=10，限制超级用户的总连接数，除了迁移用户adbpgadmin，云平台的监控用户aurora也属于超级用户，如果adbpgadmin的并发连接太大，会导致aurora无法连接数据库，导致HA模块认为数据库无法连接而触发HA切换。#修改 postgres.conf (迁移完成后恢复)
rds_max_super_conns=5003.2.3 迁移租户与用户如图2所示，db1是租户1的database，租户1除了存储空间外，也有用户及相关资源分配。租户1迁移到实例2后，相关用户也需要迁移，数仓有个特点，用户特别多，一个个创建不如迁移便捷。另外，实例2的租户的资源要重新分配。● (1). 在目标实例2中，重新规划各个租户的资源分配这里比较重要，一般一个实例中，生产租户都把资源“瓜分”完了，有外来租户迁移进来，资源得给他腾挪出来。资源组的资源分配调整方法如下，可以调高调低。psql> alter resource group user_group_1 set CPU_RATE_LIMIT 15;
psql> alter resource group user_group_1 set memory_limit 15;● (2). 在目标实例2创建租户new_pro_group1-- 这里只给基本的资源保障，迁移完成后按照最终的生产规划再做一次调整
CREATE RESOURCE GROUP new_pro_group1 WITH (CPU_RATE_LIMIT=5,memory_limit=5, concurrent=20,MEMORY_SHARED_QUOTA=40);● (3). 从实例1迁移用户到目标实例2pg_dumpall --roles-only -f role.sql
#生成后筛选role.sql中对应租户去实例2执行创建用户3.2.4 迁移表结构首先建表就需要先建database；由于数仓或数据集市，肯定有分区表。而gptransfer迁移分区表时，需要提前建好子分区，因此建议整个库（比如图1的db1）的所有表结构，都通过pg_dump先导出，再导入目标实例。● 1. 在目标实例2创建数据库db1● 2. 迁移表结构#源端导出
~ pg_dump -Uadbpgadmin -w -p3013 -d db1 -s -Fp -f db1.sql
#目标端导入
~ psql -Uadbpgadmin -w -p3013 -d db1 -f db1.sql3.2.5 GPtransfer迁移数据迁移注意点● gptransfer不擅长迁移大量的小表和空表。空表太多，要采取业务上删除空表再到目标库创建的方式；小表太多，就用pg_dump单独迁移小表的方式。● gptransfer发现目标库有表，有几种模式：skip （直接跳过迁移数据）或 truncate（先截断表清理数据）由于我们的方案是先建表，因此肯定不能跳过迁移，选择truncate(命令选项--truncate）● 外键存在导致表同步时truncate 失败1. 迁移前drop外键ALTER TABLE ONLY schema1.special_table_name drop CONSTRAINT fk_xxxxx;外键可以通过视图查询，或者直接从dump出的表结构sql文件中根据“FOREIGN ”筛选出来。2. 正式迁移数据gptransfer
-a --base-port=9000 --source-host=source_hostname --source-user=adbpgadmin --source-port=3013 -d db1 --dest-host=dest_hostname --dest-port=3011 --dest-user=adbpgadmin --truncate --batch-size=5 --sub-batch-size=25 --max-gpfdist-instances=4 --work-base-dir=/home/adbpgadmin/db1 --source-map-file=/home/adbpgadmin/db1/gptransfer.conf --validate=count --no-final-count --timeout=600 --max-line-length=268435456 -l /home/adbpgadmin/db1/trans_log注意：-a选项是关闭交互；-d 指定数据库；gptransfer.conf配置所有目标实例的segment的IP映射关系，配置形式IP,IP10.xx.xx.1,10.xx.xx.1 #文中所有IP都是虚构的
这里和开源GreenPlum有区别，开源GP是配置IP,hostname3.查看迁移进度#执行gptransfer时-l选项指定了日志目录，可以进去查看即可
~ tail -f /home/adbpgadmin/db1/trans_log/gptransfer_{date}.log整体迁移速度大概是600MB/s。3.2.6 数据稽核数据迁移后，源库和目标库一定要做数据稽核。对于数仓的校验，我们一般使用全量count+指标校验的方法结合。使用工具可以大大提效。我们建议使用KOC-数据稽核工具(名字：青天鉴)，它是一个支持多源异构数据源的数据校验工具组件，适用于解决数据迁移前后数据一致性校验的问题。目前已经支持MySQL、Oracle、DB2、SQL_SERVER、ODPS、OB(MySQL), ADB(PG)之间的互相校验。图5：KOC稽核结果示意图3.2.7 恢复配置配置恢复千万别忘，涉及pg_hba白名单、租户资源、超级用户连接数，上文已提及，这方法就不赘述了。3.2.8 业务验证数据库迁移和稽核完成后，业务割接到新库，并进行验证。3.3 集群缩容-实例释放实例释放，通过DBStack控制台上的实例释放功能即可。实例释放后，宿主机会重新回到DBStack集群的服务器资源池。通过控制台的“主机列表”查看主机资源使用情况，可以确认实例释放是否成功。如下图，只要实例1所在的服务器，显示实例数=0，且状态=开启分配，则表示实例释放成功。图6：DBStack的机器资源列表以上，对于实例1-4的缩容实施就完成了。后续的扩容是针对另一个实例进行。4. 扩容方案DBStack有服务器资源，就可以通过控制台对实例5进行扩容了。4.1 精确指定服务器在DBStack控制台的主机列表中，可以把不希望调度的服务器，修改状态为禁止分配，只保留期望的服务器列表。4.2 扩容segment在实例详情页点击新增计算节点，页面上的计算组一般就是服务器数量，每个计算组包含多个segment节点（kubernetes的Pod）；如果扩容8台机器，选择扩容后的计算组数量（假如目前52，最终计算组加到60）为60，提交确认，便自动开始扩容。数据重分布时间选择“立即执行”即可。图7：扩容功能界面产品扩容实现的逻辑● 准备新节点 i. lock catalog ii. pg_basebackup准备模板 ===> 具备相同元数据 iii. 从master节点复制文件（configureation files）到新主机 iv. 在新主机使用模板与配置文件启动新节点 v. 清理模板文件● 新节点加入集群 i. 更新gp_segment_configuration, 此时新节点对集群可见 ii. unlock catalog ● 准备扩容元数据 i. create gpexpand schema ii. create status/status_detail/expansion_progress4.3 扩容进度监控登录杜康系统，根据目标实例ID，进入任务监控页面，大致分为如下步骤图8：扩容的任务流程工作流是全流程自动化，包括segment扩容，集群信息刷新，数据重分布等。如上图，do_expand_init就是生成表的重分布计划，假如1万张表，这一步是产生重分布优先级，即并不会所有表同时处理；这一步的时间会跟数据仓库中表的数量强相关。上图中，do_expand_redistribute就是执行数据重分布，扩容默认是按照从小表到大表进行数据重分布。由于数仓数据一般都是TB数量级，不可能瞬间完成，直接自动重分布影响业务（可读不可写）。这里就是前文提到的，并不是一股脑自动化完成即可。这一步通常需要结合业务运行时间进行精细化控制，就是以下介绍的重分布方案。5.重分布方案重分布方案最大的挑战就是不能影响业务，有点“开着飞机换螺旋桨”的意思。最重要的是与客户调研澄清表的重分布优先级，可以参考几个点进行评估：1. 近期归档到外部存储（比如HDFS、OSS）上的数据表清单；不需要执行重分布2. 按天、按周滚动删除再新建表、重新加载数据的表清单；不需要执行重分布3. 业务同时强依赖的N个表；同一时段执行重分布原因是如果1个SQL join了多个表，这些表分布的节点不一样，会发生数据在不同节点之间shuffle，造成额外开销。4. 某个时段（09:00~24:00或00:00~09:00)一定有业务写入的表清单。错开该时段执行重分布5.1 重分布的原理介绍MPP节点增加后，表的分布规则按照新的节点数计算，因此数据也要重分布。重分布实际上类似按照新的分布规则建立一个新表，然后把旧表数据全量插入新表（再删除旧表），以达到数据按照新的节点数分布的目的。上文提到的do_expand_init步骤，会生成一个扩容详情表gpexpand.status_detail，表包含了有关系统扩容操作所涉及的表的状态的信息。该表的定义参考：https://gp-docs-cn.github.io/docs/ref_guide/system_catalogs/gp_expansion_tables.html最关键的status_detail.status的数据字典，ADB PG有修改， 表示扩容完成的状态值FINISHED==>COMPLETED-- 查看扩容已完成的表
psql> select * from gpexpand.status_detail where status = 'COMPLETED';其中，status_detail.rank 为int数值 ，值越小，优先级越高； 默认值为1。设置为0 后会优先对设置的表进行重分布。 因此，我们可以通过更新rank的值来制定重分布的优先级和顺序，int范围内的值都支持。另外，重分布启动后，可以通过视图gpexpand.expansion_progress查询整体实例扩容进度（数据量维度）。psql> select * from gpexpand.expansion_progress;
主要field解释如下：
-- Bytes Done：已完成的字节数
-- Bytes Left：剩余未扩容的字节数
-- Tables Expanded：扩容完成的表数量
-- Tables In Progress：正在扩容中的表（为1表示扩容正常进行）
-- Tables Left：剩余未扩容的表数量
-- Estimated Expansion Rate：预估扩容速度
-- Estimated Time to Completion：预估剩余时间图9：整体扩容进度和速度示意图5.2 制定精细方案5.2.1 不需要重分布的表更新为重分布已完成目的是为了精确控制重分布优先级。psql> update gpexpand.status_detail
set
status = ‘COMPLETED’
where dbname = ‘db14’ and fq_name like ‘hist%’;
-- dbname 数据库名
-- fq_name 表的名字
-- status
状态, update 为COMPLETED 就不会再进行重分布5.2.2 提高下一批重分布的表优先级做完一批表之后，下一批要做的表，更新一下状态和优先级=0，表示下一批优先处理。psql> update gpexpand.status_detail
set
status = ‘NOT STARTED’,rand = 0
where dbname = ‘db14’ and fq_name in (tab1,tab2,table3);5.2.3 重启扩容进程以adbpgadmin用户登录adb的master；# 先kill ${gpexpand pid}
ps aux
grep gpexpand|awk '{print $2}'|xargs kill# 然后后台启动。之后观察gpexpand日志确认Expanding的表是刚才设置的表。
# 强烈推荐使用此方法，-R 参数表可读不可写。
~ nohup gpexpand -R &
#nohup gpexpand &
--注意此方法重新开始重分布会锁表，不可读不可写，不推荐。5.2.4 观察扩容日志~ tail -f /home/adbpgadmin/gpexpand_{date}.log若日志输出某张表正在扩容：“Expanding {database.schema.table}”，表示已开始重分布。图10：重分布完成示意图上图表示扩容重分布完成。5.2.5 删除增加节点生成的schema不删除以后则无法扩容。~ gpexpand -c后记以上方案的落地和总结，结合了产品功能和实际业务场景，不一定尽善尽美，如果读者有更好的方案，欢迎一起讨论。

从开源到商业的变化，再到云化趋势明显、国产化发展趋势加剧；这些变化都将面临一个诉求，那就是数据库迁移。那应该如何完成不同数据库间的迁移？如何完成线下到云上的迁移？第9期对话ACE，邀请了 OceanBase 技术专家纪勇、Oracle ACE李广才一起探讨“数据库迁移如何优化方案和避坑？”以下内容根据对话实录整理而成，欢迎大家阅读、收藏！Q1您觉得什么条件下，数据库才需要必要的迁移工作？李广才：数据库迁移的原因是多样的，包括服务器或存储设备更换、维护或升级，应用程序迁移，网站集成，灾难恢复和数据中心迁移。数据库迁移通常来说有这几个场景需要迁移，从需求角度来讲：1.应用软件需求侧：兼容性，如SAP软件、ORACLE EBS软件对数据库的版本、组件的要求。2.合规需求：法务合规等，对软件正版化的需求。3.安全需求：新的版本，解决安全或BUG漏洞。定期的补丁更新、BUG漏洞修复、安全修复等。4.成本考虑，如迁移到云环境、从云环境迁移到本地自建机房等。从AIX迁移到LINUX等。5.性能需求，从差的设备迁移到更好的设备；从一种数据库迁移到具有更好性能、特性的数据库等。6.高可用等需求：迁移到具备高可用、集群的环境。从运维管理角度：1.存储硬件更换：需要将数据迁移到新存储。2.服务器硬件更换：新的硬件平台，使用新的架构、新的操作系统版本等，需要配套新的数据库版本，需要进行升级迁移。3.机房搬迁等。Q2 OceanBase 现在可以实现哪些主流数据库的迁移？迁移前后需要做哪些操作？纪勇: 首先 OceanBase 有一个比较大的特性，就是它是分布式的，它的一个租户是可以分布在多台机器上的，给我们做业务合并，提供很大的便利性。另外 OceanBase 的存储压缩，也是能较大的节省存储成本。我们有很多客户是从其他数据库迁移到 OceanBase 上面来，确实也看重这方面的能力。OceanBase 现在迁移的工具的话，主要是支持了像主流的MySQL、Oracle、DB2、PG，也包括一些新兴的数据库，像TIDB，我们也会支持往 OceanBase 上来迁。此外像SQL Server和MongoDB，我们也正在做。这是当前 OceanBase 的迁移服务所支持的这种数据库的迁移。刚才李老师也提到，除了迁移，我们可能还有一些数据同步的场景，我们可能需要将数据库里的数据同步到一些消息队列或搜索引擎。当前 OceanBase 的迁移服务就是OMS（OceanBase Migration Service），它也支持从数据库到Kafka、到ES、到一些消息队列，以及阿里云ADB的同步，这是当前OMS所具备的能力。刚才李老师提到的第二个问题，就是迁移前后需要做哪些操作，数据库迁移确实是一个比较复杂，风险比较大的一个活动，在迁移前后确实需要做很多工作去保障整个迁移流程是顺畅的，尤其是在异构数据库的迁移里面。迁移前，我们需要做的准备操作，一个比较重要的就是要去保障迁移的源端数据库和目标端数据库的功能和性能是对等的。迁移上来后，我以前的应用的SQL跑上来后不会出问题，在功能性上面不会报错。第二个是性能，在之前的数据库上面，我们能跑1万的TPS，到了新的数据库上只能支撑比如5000，那么迁上来可能就会产生一些问题。所以在迁移前的一个重要的准备工作，就是功能和性能的兼容性保障。我们也是有评估工具来做保障的。第二个点，就是在做数据迁移之前，我们还需要做结构的转换。异构的数据库，可能有一些数据类型或者对象，不是完全对等的。就是说原端的一个create table语句拿出来到目标端，它不一定是能执行的。所以在做数据迁移之前，我们需要去做这种数据库对象的一个转换。并且在目标端把对应的对象创建出来，为数据的迁移做一些准备。此外，在真正的数据迁移之前，我们还需要做一些必要性的检查，比如说我们的库表在目标端对是不是存在？因为只有库表存在了，才能保障数据是可以写入到目标端的。另外还包括类似于数据库账号的权限，我需要能够从源端读取到数据，才能迁到目标端。然后我需要源端，具备一些，比如说像MySQL，具备这种能够去 dump binlog的权限。另外如果我们需要做增量迁移的话，源端的日志是不是打开了？比如说MySQL上面它的这种binlog模式是不是开启了行级的模式。像Oracle是不是开启了补充日志？这些都要去做必要的检查，只有检查充分了，整体的迁移过程才会顺畅，这是迁移前的一些动作。数据迁移完了，有一个重要的点，就是怎样去保障数据的一致性，我们需要做必要的数据校验。另外还包括整体割接流程，需要配合应用。因为数据库迁移最终的目的是为了把应用的流量迁到新的数据库上来，所以一个重要的点就是要配合应用做整体的应用端的割接。因为刚才提的是一些异构数据库的迁移，异构数据库的迁移有一个点，当我的应用流量切到新的数据库上面之后，要保障万一可能新的数据库上面有一些问题，比如功能性能没满足要求，那我可能还要切回到原来的数据库上去。如果已经在新的数据库上有一些写入操作了，那么还需要有一个反向同步的过程，把在新数据库上写入的数据，实时同步回源端。这样的话，当需要做回退的时候，可以保障回退之后，整体的业务没有受损。Q3 数据库迁移前应该做哪些方面的评估工作？李广才：参照我过去十来年多个项目的经验，整个迁移最核心的工作就是在评估。迁移的支持角色评估 - 多方协调工作一个核心的数据库迁移是涉及到多方协调工作，根据以往的工作经验主要涉及到就是使用方的It维护人员，应用系统管理人员，应用系统的供应商，硬件基础平台的集成供应商（包括存储，网络，服务器，操作系统），业务依赖的中间件厂商（类似像weblogic，webshpere，tomcat，或者是网络安全、数据安全设备厂商，或者是类似Goldengate、Dsg等之类的数据抽取复制供应商），迁移厂商。这些都是在迁移初期对潜在需要的协调工作角色进行充分的调研，所有的一切都是对这个数据库基础架构的摸底以及跟用户的沟通中来判断。硬件资源评估 - 应用系统以及数据库生命周期基本围绕五个维度：网络带宽，内存，CPU，数据容及IO吞吐量，备份。硬件资源的评估也是个比较精细的工作，依赖对迁移的数据库历史运行数据的分析，通常如果有日常监控的数据留存，我们去做会根据近五年的运行情况来先做一个预评估基础数据，再根据未来五年的业务运行增量去做一个加法。往细里探讨，这就涉及到对数据库的内部数据增量、CPU使用以及内存使用增长率、IO平均最高开销、带宽的最高开销相关的数据统计，我个人习惯以年为单位进行估算，参考历年数据库运行情况。而在这之前还需要考虑到业务系统的变化，比如业务模块的增加或者淘汰都直接影响到对资源的使用。迁移方式与时间的评估 - 合理的迁移技术选择数据迁移有多种技术手段，首先还是要考虑场景。1.是否不同数据库之间的迁移；2.还是同数据库之间的迁移；3.又或是同数据库不同版本之间的迁移，是升版本还是降版本；4.是否需要升级。其次才是考虑选择迁移技术。用冷拷贝、自带的备份恢复工具、数据逻辑复制、数据物理复制甚至像低代码平台的数据抽取功能等等有非常多的选择，场景不同可以选择的方式也不同，找到适合当前场景的就需要作出合适的判断，而判断的指标我总结为几个方面如下：1.是否有停机时间，就是指的停机时间窗口，在线迁移以及离线迁移是两回事，这个分水岭直接关系到迁移的技术选择；2.停机时间窗口多久，不同的迁移技术选择所花费的时间也是不一样的；3.首要考虑熟悉的技术，工程师技术掌握个与所长，扬长避短，不做没把握的事情；4.数据校验时间；5.对性能影响的考虑，比如Oracle的expdp方式，其实迁移后你不做统计信息收集，对性能影像还是很大，或者涉及到大升级，就需要把调优的工作在迁移完成之前就需要尽可能的测试完成。迁移性能评估 - 评估高地对数据库性能的了解是非常有必要的一个工作，迁移之后的性能也是关系着数据迁移成败，主要难点一，是在于不同数据库之间的迁移后，性能波动情况的了解。同数据库之间相比而言比较容易判断。难点二，是对数据库未来运行的性能趋势评估，这个会比较紧密结合前面提到的硬件资源评估，数据增量，CPU开销增长，带宽增长。所以一般可以看到很多厂商在做硬件资源评估时候喜欢往顶里报，但客户往往会从成本考虑，我也建议我的同事在做迁移工作时候，利用已有的运维平台数据，结合硬件需求，对未来的性能做一个规划。白鳝之前分享过容量规划的概念，其实跟我表达的意思基本一致。在该部分有一个好的工具会节约大量的时间。迁移的兼容性评估 - 目标版本，补丁，系统，配置兼容性方面，无论迁移过程是跨类型，跨平台，升级，降级主要涉及到几个方面：一. 数据库本身的附带功能（监听，Dlink）、函数、数据类型、非标SQL的支持等；二. 应用程序的兼容，是否适配过相关数据库的版本获得过厂家的认证支持；三. 中间件的兼容，我碰到过主要的中间件兼容问题就是在金融领域texudo的兼容问题，现在数据库版本迭代快，而texudo或者像weblogic这类中间件老版本上经常会出现不兼容的情况，这一类需要在准备工作中做足测试；四. 操作系统的兼容，比如主流的操作系统版本选择，相关补丁。目前信创如火如荼，国产的操作系统方面对相关数据库版本的支持需要做充足的准备工作；五. 硬件兼容性，主要体现在驱动层面。迁移的回退工作评估 - 能进能退方成大全这是个有意思的地方，回退往往意味着迁移失败，原因也是多方面的，可能是数据出问题、性能出问题、超出停机允许时间、兼容问题等等，好在大部分的迁移都是离线迁移，所以回退其实是个简单的工作，只需要将业务恢复原状即可。在一些项目中特别是在线热迁移的情况下，甚至其实客户本身意识到没有回退可能了，但我们还是习惯会去考虑，真的没有办法回退了么？比如Oracle在线跨版本热迁移，主要面临的问题就是迁移后数据变动了，但是发现需要回退，这个时候怎么办？有没有办法规避这类问题。Q4 OceanBase 数据迁移工具OMS在设计和实践上，主要考虑哪些迁移工作？纪勇：要回答这个问题，首先要去看一下OMS（OceanBase Migration Service）设计的初衷是什么？OMS在设计的时候，一个比较大的点，就是期望用户在用OMS做数据迁移同步的时候，可以在一个平台上，解决刚才说的所有问题，这是一个预期。我们整个OMS迁移流程，其实牵涉到迁移前、过程中到迁移后整个方方面面，包括迁移前的功能和性能评估、数据库对象的迁移，包括库、表、视图，包括全量数据以及增量数据的迁移。可能有些用户给的割接时间是非常短的，我们要在非常短的时间内完成整个割接操作，采用离线的方式肯定是不行的，所以必须要有这种增量数据的迁移。数据迁移完了，在割接之前肯定是要做数据校验的，数据校验也是整个迁移过程中非常重要的一步。另外也包括反向同步，刚才提到的，万一新的数据库上出现问题，一定要把在新的数据库上新写入的数据，实时的同步回源端的数据库。OMS在设计上，跟现有的迁移工具对比的话，它其实有很多地方是多出来的，比如数据校验，割接的反向同步。其他的一些工具，可能也有这些，但没有集成到整体的割接流程里。这就跟OMS之前在蚂蚁站内的一个实践有关系，因为蚂蚁站内已经把Mysql、Oracle这些数据库全部迁移到 OceanBase 上了，之前我们的DBA用这个数据迁移工具的时候，对整个割接流程的标准化，流程化要求较高，只有把整个过程标准化、流程化掉，才能让整个割接过程中的风险降到最低，这是我们的一个设计理念，同时希望OMS服务用户的过程中，能够给用户提供更好的服务。这个过程中，有很多的细节，我就不一一介绍，就列出一个点，我们在增量数据迁移的过程中，有一个比较重要的点，源端、目标端不仅是数据在变化，结构也在变化，在做增量迁移的时候，这个过程可能会迁移一周，多的可能会有个把月。这个过程中，源端的业务在变化，源端的Schema也在做变更，那怎样同步到目标端？这是一个较大的挑战，源端跟目标端本身不是同一种数据库，比如源端是Oracle，目标端是 OceanBase 的Mysql模式，源端的语法在目标端需要做对应的转换才能执行。OMS在这个过程中，为了能够让用户更平滑，不需要去管过程中的很多这种事儿。OMS提供了增量DDL迁移的能力，自动化的把事情做掉，这是OMS整体设计上的考虑，让用户用起来比较简单，考虑的比较少，能够在一个平台上完成整体的数据迁移。Q5 面临国产数据库技术的发展，您觉得当下在迁移方面还需要做哪些改进？李广才：1.迁移方案的多样性不同的数据库、不同的迁移需求、不同的数据量级、不同的软件产品、不同的系统架构、不同的停机时间窗口等，对应会有不同的最适合特定场景的迁移方案。例如从SQLSERVER迁移ORACLE，从ORACLE迁移到国产数据库等，在不同的数据库架构迁移，给出参考方案。根据不同数据量级、不同停机时间窗口，给出不同的迁移方案。2.迁移方式标准化传统的数据库迁移，从前期环境调研、方案确定、测试、方案修订（可能需要多次迁移测试）、迁移、保障等，有一系列流程、步骤，需要经验丰富的工程师、项目经理把控项目进度、完善各个细节，才可以完美的实现一次迁移。在向国产化数据库迁移时，需要结合迁移方案，输出一些标准化、可操作性强的文档方案，能够让经验一般的人员也可以在方案文档的帮助下完成向国产化数据库迁移。3.迁移工程工具化传统的数据迁移时，主要依赖于经验丰富的工程师、项目经理，依赖于多年来不断摸索的出的迁移经验及其标准化的产物-迁移方案文档；在未来国产化数据库迁移时，由于没有很多很久的历史沉淀及这方面经验丰富的工程师；更多的需要厂家给出一下迁移方案。在这方面如果可以结合迁移步骤来标准化来开发对应的迁移组件，实现迁移的工具化、工具使用的简单使用，也有利于向国产化数据库迁移。Q6 当扩容或者缩容的时候，分布式数据库数据迁移具体实现方式有哪些？纪勇：这个问题，结合OMS来看，OMS本身作为一个产品，它具备多机或者多地域的部署能力，也就是说可以分布式化部署，它可以部署在多台机器上，可以部署在多个地域内，比如当某一个地域里面的某一台机器，发生故障的时候，可以让当前这台机器上任务迁到其他机器上去。OMS 在用户侧也会碰到一些情况，包括不只是数据库，我们在数据迁移过程中，也要去关注资源的使用，现在大家都在讲降本提效。有些场景，整个企业的数据迁移，其实是一个渐进的过程，可能先迁一个业务试试水，每隔一段时间迁一部分业务，我们没法去要求用户把要迁移的使用资源全部固定下来，不确定后面会迁多少。所以OMS其实提供了一种能力，就你最开始的时候可以一台机器，先迁移一部分业务，当需要迁的业务越来越多时，可以把新的资源扩充到集群里来，支撑更多业务的迁移，这是扩容的场景。缩容场景包括两方面，一方面我业务迁完了，迁移高峰期过了，需要把资源拿过来给其他的应用或服务去用。另外一种是被动的，因为我们机器会产生故障，可能在某个时间点，当前的3台机器1台挂掉了，我要怎样保证整体的迁移服务是正常的？有两种解决方案，一种通过监控告警，把问题报出来，让人接入去解决。另外一种方式就是整个系统具备自愈能力，当迁移正在进行中时，可能某个迁移任务挂掉了，但当前的机器资源还是充分的。比如说原来3台机器，挂了1台，剩下2台还能撑，虽然利用率比较高，还是能够支撑现有的数据迁移，就可以自动把当前的迁移任务挪到其他机器上去，让它继续运行。在宕机任务恢复的过程中，需要保证不丢数据，OMS也是选择的第二种方式，会去自动的去帮用户做这种恢复。这样的话，当有部分缩容，还是预期外的宕机，不需要人介入就可以恢复，用户用起来比较舒服。任务万一半夜挂掉了，还要去半夜起来去处理，是比较痛苦的。Q7 数据库迁移后，关于数据比对和运维方面，应该如何优化方案？李广才：数据同步并比对，这里比对可以理解为数据校验，在我们传统的迁移里其实是包含了数据效验的步骤，提高数据效验的效率对缩短停机时间有着显益的帮助。一般需要做数据比对场景主要是在迁移涉及升级，不同类型数据库之间迁移，跨平台迁移，不同字符集等。第一种方式：通过一些成熟的工具可以提升数据效验的数据，比如oracle dg自带的逻辑坏块效验功能，或者ogg veridata，sync-diff-inspector等。第二种方式：选取关键核心表进行数据对比，缩小比对范围，提高整体比对效率，像oracle就可以对表进行哈希比对，通过脚本集成的方式，对关键表进行核对。运维方面，这是一个比较受关注的问题，十年前我们可以看到很多用户的多个业务系统使用的数据库类型是不会超过2种，而现在国内数据库厂家百花齐放，用户面临的选择非常多，受到多方面的原因影响，在客户端可以有多种数据库类型的业务在跑，这对数据库的运维以及开发人员提出了更高的要求，全靠人工要提高运维效率是有限的，更多还是要借助平台工具，把一些固化的工作工具化，一些固化的分析诊断智能化，这样能减少运维人员的大量精力，特别是在数据库繁多的时候，但现在对数据库这块的监测多样化支持的产品并不多，好用的更少。建议可以试用下在智能自动巡检，自动优化，诊断，故障预警，性能预警方面全面智能化的产品。Q8 是否有一些简化快速迁移的方法？如何保障迁移过程顺利保障数据不丢失？纪勇：首先说一下快速迁移的方法。在做迁移准备的时候，要根据各种系统去选择迁移方案。刚才李老师提到了一部分，我再说一下我的看法，怎么做简化迁移，这确实要有很多条件，不是所有的场景或业务都能够做简化迁移。我理解可以做简化迁移的，首先得是同构的，源端和目标端差不多，都是一样的，比如都是Mysql相近的版本，都是Oracle相近的版本。另外一点就是数据量比较少，在迁移的过程中，可以比如说写个小工具，或者利用数据库原有的一些工具，比如说dump，再load进来，它就可以完成一个数据迁移。然后还要可以停机，不能说你只给我五分钟停机时间，我连数据都导不完，肯定是不能做简单迁移的。所以我觉得如果你是同构的，数据量较少，且允许停机，是可以把迁移方案做的相对简单一点的。也不需要什么产品，就是利用数据库原有的一些能力，写一些脚本，把这些脚本串起来，可能就能完成迁移工作了。但如果咱们不具备这样的前提条件，稳妥的办法，还是用比较成熟的产品去做。第二个问题，保障数据不丢失。我相信李老师也用过很多种迁移工具，可能多多少少碰到过丢数据的问题。没有哪个工具敢保障没有数据丢失，不需要做校验，什么都不用做，迁完就完了。因为数据一致性本身，在数据迁移或同步的过程中是用户最关心的事情，但数据一致性是没法证实的。尽管有校验程序在，你也很难说校验程序没问题。虽然没有办法从理论上证实两边的数据一定是一致的。但我们还是有一些方法让这个问题更大概率的暴露出来，或更早暴露出来。我们的用户和客户也比较关注这个问题，我们在工程层面上主要做的是提高代码质量，会通过各种单测、集群测试、破坏性测试从各个方面去测这个东西。另外一点，我们会做增量和全量的校验。全量校验大家都比较清楚，就是我从两边不停的去拿数据做比对，还要考虑，怎样把增量同步的异步的时间差给消化掉，这样的话能够减少一些误报。另外一个点就是增量校验，增量校验是比较重要的。尤其割接时间比较短，全量数据比较大，比如十分钟的割接时间，可能全量数据量有上T，那不可能在十分钟内校验完这么大量的数据。所以这个点上，OMS是有增量数据校验的能力,也就是说我会从两边去消费这个日志。比如说源端是Mysql，目标端是OceanBase。源端我可能会去读它的binlog，然后目标端 OceanBase 读它的clog，然后把流式的数据拿过来做比对，尝试去发现这里面的不一致。即使这样，我还是没办法保障说，校验完了是一致的，这个数据就就是一致。我只能说我们通过代码质量的保障，以及各种严格的手段，把概率降到很低，只能说暂时还没被证实会丢数据。我们在做数据同步的时候，非常坚持的一个点，就是对数据质量的保障，作为我们最重要的一个任务去看，任何性能或其他的点都要给它让路。从方法上说，大家也都知道一些常见的方法，比如说全量数据迁移，迁移的过程中，比如说做数据切片，切片不能漏，读完数据后，一定要写到目标端，回来之后我才认为这个数据成功。包括增量数据迁移，在源端可能串行的数据，在提高性能，并行写到目标端的时候，也需要做一些非常精细的处理。才能保障在做增量数据迁移过程中也不会丢数据。因为迁移过程肯定有可能会断的，尤其是异构数的迁移，很难保证这个过程中都是一切顺利的，这个程序永远都正常运行。甚至有可能出现宕机之后需要迁移，当出现这些场景的时候，我们需要做非常精细的处理，才能够保证碰到这些异常情况时，数据也能保障一致。Q9 迁移数据库的成本和风险在哪里？应该如何有效的控制？李广才：迁移的风险，其实我们前面在做迁移评估的时候已经说明了，尽可能提前考虑，所以需要提前评估，这里就补充一个合规使用，尽量使用正版，毕竟是软件就会有bug，特别是现在数据库产品百花齐放的时候，场景的使用需要得到验证是有一个过程的。至于用户的迁移成本，也在前面迁移评估中提到了，可见的主要就是多方协作成本以及设备投入，还有尽可能准确的性能预测，在这基础上合理设计硬件平台节约成本。还有停机产生的业务损失成本，这个就需要跟用户商讨一个合适的停机时间范围，而不是为了本身迁移而报一个对乙方有利的停机时间。控制这些风险以及成本个人认为有效的方式是引入专业的三方公司进行评估，在三方公司的评估基础上，用户再根据真实情况进行调整。Q10数据上云是一个趋势，关于云上数据库迁移这方面工作应该注意哪些？纪勇：简单说一下我的理解，现在云是趋势是没有争议的。因为安全、合规之类的要求，自建机房还是会存在的，但比例会逐步的降低。引出一个问题，就是线下的数据如何搬迁到云上，这是由于我们逐渐的云化引发的一个问题，云的终点也不是在一朵云上，有价格的因素，包括企业和云厂商的关系，容灾等各种考虑，我觉得大一些的企业未来应该会把自己的站点构建在多朵云上，是一个多云或者混合云的模式。可能云上会用两朵云，云下也有自己的自建机房，可能数据库在一朵云上，数仓放在另外一朵云上。在一朵云上，提供数据写入服务，另外一朵云上，提高数据读取服务。基于这个假设，我觉得上云之后，对企业的挑战主要是多云场景或混合云场景下，怎样去构建数据传输的网络。今天虽然说是数据迁移，但其实范围不只是数据迁移，还包括日常的数据传输，构建两地三中心，做读写分离，做业务上的处理，做数据库到数仓，或者说数据库之间的同步都牵扯到长期的同步。所以我说的是在多云场景上，怎么样去构建数据传输的网络。怎么样应对这个挑战，我觉得如果是机房上云，普通的数据迁移，倒是相对来说没那么复杂。因为我们现在云厂商的数据库还是和正常线下用的数据库有一定兼容性的，尤其是Mysql，比如阿里云上提供的RDS，腾讯云或华为云都有这些，跟我们自己构建的Mysql其实没有太大的区别。所以整个迁移过程来说，主要还是在网络上面，比如搭一条自建机房到云厂商之间的网络做数据传输，这个相对还好。但是如果是跨云的话，我其实还没看到特别好的数据传输方案。现在一般跨云是走公网，假设腾讯云上的一个数据库需要存到阿里云上，现在的方式是在腾讯云上把公网出口打开，把RDS给公网出口打开，然后作为公网的数据源再迁到阿里云上来。尽管开了公网后，可以用用户密码、加密传输，保障数据传输的过程中，数据是加密的，但是走公网毕竟还是没有那么安全，一些重要的数据，是不敢往上面放的。我觉得后面有可能出现云厂商中立的比较好的数据传输软件，能帮助用户在保护数据安全、数据合规的情况下，高效地帮助用户在多个云之间做实时数据传输，帮助用户构建多云下的数据传输的网络。这个时间点什么时候到来？可能跟整个上云的趋势，以及大家对跨云的需求趋势，是有关系的。看国外的趋势的话，我觉得可能在五年之内需要有这么些产品出来的。一旦有这些产品之后，大家后续再去做数据上云时，就会比较放心了。一方面，能够在多个云厂商之间取得平衡，同时不被某个云厂商给lock in，想要出来的时候，可以很方便的出来。