【详述】由于业务需要,starrokcs需要从3.1.13平滑升级到3.2.x ，在升级到3.1.14的时候，升级过程较顺利，但出现了某一张表数据丢失.(注意，这张表是销售相关重要基础数据表，本人上周和Leader对过，是绝对不能错的，升级前对表数据进行了全表分区数据量检测和每日新增数据和业务库的数据量对比，此前都是正常。)
【背景】从3.1.13 —>升级到3.1.14 (修改3.1.13的be,fe的lib和bin文件，启停节点等常规操作.)
【业务影响】单张表关联的物化视图出现了强制刷新，几乎全表刷新（我们数仓数据最早分区在19年10月，出现几个物化视图从19年刷新到24年，刷新成功.目前看影响到DWD物化视图，ADS和DWS物化视图暂未刷新.）
【是否存算分离】存算一体
【StarRocks版本】例如：3.1.13
【集群规模】例如：3fe（2 follower+1Leader）+3be（fe与be混部）
【机器信息】CPU虚拟核/内存/网卡，例如：16Core/64G/万兆
【联系方式】yaoquanxin@xueji.com
【附件】
-
fe.log/beINFO/相应截图
出错表为：ods_xxxxs_gmv_order 源表为：xs_gmv_order
校验程序显示的丢失数据情况：
fe Lead.log
由这张ods基表导致的物化视图强制刷新，并且从2019年开始刷新。（本人使用python脚本刷3天物化视图分区的数据，结果全表刷新了。猜测是因为ODS基表数据丢失导致导致全表刷新了物化视图。
try:
# 计算最近三天的开始和结束日期
end_date = datetime.now().date()
start_date = end_date - timedelta(days=3)start_date_str = start_date.strftime('%Y-%m-%d') end_date_str = end_date.strftime('%Y-%m-%d') # 构建刷新物化视图的SQL语句 refresh_sql = f""" REFRESH MATERIALIZED VIEW {view_name} PARTITION START ('{start_date_str}') END ('{end_date_str}') WITH ASYNC MODE; """
）