1. 概述编辑
当前为 4.1.5.5、4.1.6.1、4.1.6.2 版本且使用管道的用户若需升级，请联系技术支持排查管道遗留数据
原因：4.1.5.5新加类，升级后反序列化会失败，以下场景需要做额外处理。
2. 有脏数据编辑
进入运维中心>管道任务>任务管理处筛选有脏数据的任务，若存在脏数据，即要提前做好处理。
原因：29版本定时支持脏数据配置任务影响了管道的脏数据记录，30做的处理仅能兼容29之前的版本，29版本的脏数据反序列化失败，无法兼容。
现象：29版本管道产生的脏数据，升级到30版本后无法导出及重试。
处理步骤：
1）暂停管道任务
2）使用定时任务进行脏数据处理，任务主要流程及节点解释：
查询脏数据
脏数据存于finedb中的fine_dp_pipeline_dirty表中，根据task_table_id进行过滤选表。task_table_id可以于管道任务的运行监控处获取，F12，然后点击查看脏数据详情，此时请求中的sourceTableId即为对应task_table_id
：
解析出所有主键值
JSON路径填写[0]即为获取该数组的第一个值，如果有多个主键，则需要添加多个字段，取得所有主键字段
参数输出
该步骤需要输出所有的主键字段传给下游的循环容器
循环容器-数据同步
该节点作用为源表使用where语句过滤出主键为参数值的 源表值，同步至目标表中，进行更新/插入
-----
以上处理的是after不为空的时候，该场景可以覆盖插入和更新， 还需要覆盖源表删除的场景（before为空，after不为空，对应插入；before和after同时不为空，对应更新；before不为空，after为空，对应删除）
和上述步骤不同的是：
解析获取after主键数组
选择after节点和before，并且勾选「解析后保留上游输出节点」
过滤出after为空数据
获取after主键数组算子后接数据过滤，过滤出after的解析值为空的值
解析获取before主键数组
过滤算子后再接入解析算子，解析出before中的每个主键值，并输出为参数
循环容器内数据比对
因为有删除记录不一定最终结果就为删除，可能后续还有删除操作。因此为了数据的准确性，使用数据比对，过滤出来源和去向表中主键和before的主键值一致的值，进行数据比对，再写入目标表
----
处理完成后，管道脏数据点击忽略，然后启动任务即可。如果客户不需要重试脏数据，就不需要进行以上操作，直接忽略即可
3. 有待同步数编辑
查询任务是否存在待同步数：
暂停任务(任务运维处可以批量暂停/启动），查询finedb：SELECT task_id,table_full_name,to_sync_record_count FROM `finedb`.`fine_dp_pipeline_execute` WHERE task_id = '6f52de99-aa62-4c65-9d3a-0c4b5903d8d0'
替换库名和task_id(任务ID，可通过F12获得)，即可查看查找的任务是否存在待同步数，或者前端查看
若无待同步数，正常换jar升级即可，升级后手动起一下任务，不需要做下面的操作
若存在待同步数，有以下两个方案解决：
方案一：使用新任务(仅增量/全量+增量） //若使用全量+增量则不需要做下面的操作 ，换jar后新建任务即可
换jar前操作：
1.获取有待同步数任务的writerMessageTime以及源端断点位置
writerMessageTime获取方法：F12，进入对应任务管理活动页面，转换成时间为 「2024-3-22 14:33:41」
源端断点对应时间点获取方法：
select * FROM `8421_finedb`.`fine_dp_pipeline_savepoint` where task_id = '6f52de99-aa62-4c65-9d3a-0c4b5903d8d0'
获取到的type为对应源端(非TARGET_KAFKA记录）记录的value值，如下面是oracle对应type为SOURCE_LOGMINER的value值
拿到value值中的scn，去源库中通过scn去查对应时间戳：
SELECT SCN_TO_TIMESTAMP(319055004) AS timestamp FROM dual; 预览出来的值为「2024-03-22 14:33:41」
2、将writerMessageTime时间戳和scn找到的断点时间戳比对，选择较早的一个记住这个时间戳A
换jar升级...
换jar成功后：
1、复制原任务，修改同步类型为「仅增量」
2、选择仅增量同步起点为「自定义时间」，时间选择为「时间戳A-10s」，如上述例子，则选择「2024-03-22 14:33:31」
！！这个减去的时间是机动调整的，如果原任务待同步数量多，且writerMessageTime也没追上来，就多减去一些时间(如1小时)，可以结合前端查看有待同步的表的读取写入延时，也可以估算大约要提前多久
保存并启动任务
方案二：使用原任务(下下下选，需要修改finedb配置等，存在待同步消不掉的风险）
方案暂不公开，实在不愿意新建任务的客户可以和chloe沟通下这个方案