升级集群后,修改表的属性造成fe之间不同步

【详述】
集群从2.1.1升级到2.5.3,修改主键模型的表的属性:
ALTER TABLE XXX.XXX
SET (“enable_persistent_index”=“true”);
升级完成后,fe只有LEADER的alive是true,其他都是false,
三个节点的fe的日志中出现大量报错:
2023-04-09 23:47:55,030 ERROR (replayer|82) [BDBJournalCursor.deserializeData():241] fail to read journal entity key=21460997, data=
java.io.IOException: UNKNOWN Operation Type 10005
at com.starrocks.journal.JournalEntity.readFields(JournalEntity.java:766) ~[starrocks-fe.jar:?]
at com.starrocks.journal.bdbje.BDBJournalCursor.deserializeData(BDBJournalCursor.java:236) [starrocks-fe.jar:?]
at com.starrocks.journal.bdbje.BDBJournalCursor.next(BDBJournalCursor.java:280) [starrocks-fe.jar:?]
at com.starrocks.server.GlobalStateMgr.replayJournalInner(GlobalStateMgr.java:1894) [starrocks-fe.jar:?]
at com.starrocks.server.GlobalStateMgr$5.runOneCycle(GlobalStateMgr.java:1759) [starrocks-fe.jar:?]
at com.starrocks.common.util.Daemon.run(Daemon.java:115) [starrocks-fe.jar:?]
at com.starrocks.server.GlobalStateMgr$5.run(GlobalStateMgr.java:1824) [starrocks-fe.jar:?]
设置ignore_unknown_log_id = true参数后,fe节点顺利启动,但是查询:
SELECT * FROM information_schema.tables_config WHERE

– TABLE_SCHEMA = ‘MRTDB’;

TABLE_MODEL = ‘PRIMARY_KEYS’

and PROPERTIES like ‘%“enable_persistent_index”:“false”%’;

LEADER节点和Follow节点enable_persistent_index属性的值不一致。
【背景】ALTER TABLE XXX.XXX
SET (“enable_persistent_index”=“true”);
【业务影响】
【StarRocks版本】例如:2.5.3
【集群规模】例如:3fe(1 follower+2observer)+5be(fe与be混部)
【机器信息】CPU虚拟核/内存/网卡,例如:48C/64G/万兆
【联系方式】社区群1-数据小黑

3FE建议是3 follower,不是1 follower和2 observer,请问现在主键加SET (“enable_persistent_index”=“true”);还会报错吗?

我说的follower和leader,是指fe的角色,三个follower,其中一个角色是leader,另外两个的角色是follower

请问现在主键加SET (“enable_persistent_index”=“true”);还会报错吗?

不报错,元数据也不同步

show frontends 检查一下

检查哪一方面?都是alive的,我说的元数据同步,是指的enable_persistent_index属性的值不一致。

重做另外两个FE FOLLOWER,再测试一下 主键加SET (“enable_persistent_index”=“true”);

另外两个FE已经重做了,我晚上测试一下这个,虽然理论上可能没问题,现在也不敢动,FE挂一个对我们影响太大

另外我怀疑新建表是不是就是没问题的,建表的时候指定enable_persistent_index=true

建表也可以指定enable_persistent_index=true。
已有的表可以通过ALTER TABLE XXX.XXX SET (“enable_persistent_index”=“true”);

还有一个问题啊,现在唯一没有重做的这个fe,也在报错啊,这个怎么解决?我昨晚上重建了fe之后,enable_persistent_index=true也没同步过去,这个跟我重新执行SET (“enable_persistent_index”=“true”);有啥区别?我的意思是说重做了历史的没同步过去,新作的就同步了,这个机制的区别在哪, :smiley:

重做fe,ignore_unknown_log_id = true这个参数可以保留么?

FE leader启动成功后,ignore_unknown_log_id = true不能保留,然后重做其他两个FOLLOWER

我现在的状态:
1个fe的角色是leader,配置了ignore_unknown_log_id = true,没有重启
2个fe的角色是FOLLOWER,已重做,第一次重做没有加ignore_unknown_log_id = true,启动失败,第二次重做加ignore_unknown_log_id = true,启动成功
我现在这个状况应该怎么测试?

经过你建议的步骤测试,问题还是那样,执行了SET (“enable_persistent_index”=“true”),表的元数据只在leader上更改了,其他两个节点没变

show frontends看看

需要看啥?都是alive的,这个启动了之后,肯定需要检查的,而且都是单个ip:port连上去测试的,要不然怎么知道元数据没有变化?这个问题的原因是啥啊?你前面指导的说是重做就可以好,按照我的理解这是不可能的吧,一种操作类型不识别,不应该是代码层面的事么?即使是元数据升级过程中有问题,那不应该是报个什么结构找不到一类的错误吧?关键是错误依旧,然后让检查show frontends,这两者之间有啥关联?

幸亏群里有人回复,升级到2.5.4,要不我还在show frontends

this issue is fixed by pr link [https://github.com//pull/19504]
the problem is [java.io.IOException: UNKNOWN Operation Type 10005]