升级集群后，修改表的属性造成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”);有啥区别？我的意思是说重做了历史的没同步过去，新作的就同步了，这个机制的区别在哪，

重做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]