re20052 opened a new issue, #69251: URL: https://github.com/apache/doris/issues/69251
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/doris/issues?q=is%3Aissue) and found no similar issues. ### Version 4.0.3 ### What's Wrong? When Remote Doris Catalog refreshes table metadata with `use_arrow_flight=false`, the client may randomly access different remote FE nodes. The same partition can produce different metadata checksums on the Leader and Followers because `Replica.pathHash` is included in `Partition.getMetaChecksum()`. `pathHash` is updated by the Leader from tablet reports, while Followers may keep the default value `-1`. As a result, switching between Leader and Follower causes the cached checksum to alternate, even when partition versions, tablets, replicas, and other metadata are unchanged. The remote FE then treats all partitions as changed and returns complete partition metadata repeatedly. This causes unnecessary partition serialization, network transfer, deserialization, and metadata rebuilds. ### What You Expected? For logically equivalent partition metadata, Leader and Follower should return consistent checksums so that Remote Doris Catalog can reuse cached partitions. A change in `Replica.pathHash` should not cause repeated full partition refreshes when the client switches between remote FE nodes, unless the change is required for remote query correctness. ### How to Reproduce? 1. Deploy a remote Doris cluster with 3 FEs: 1 Leader and 2 Followers. 2. Create a partitioned OLAP table with a large number of partitions. In our test, the table had about 475 partitions. 3. Configure a Remote Doris Catalog with `use_arrow_flight=false`. 4. Warm up the local metadata cache by querying the remote table. 5. Send metadata refresh requests with the same cached partition metadata to different remote FE nodes. Observed behavior: - When the cached checksum matches the target FE, no partition metadata is returned. - When switching to an FE with a different `pathHash` value, all partitions are returned as updated. - Switching back to the previous FE triggers another full partition refresh. For the same partition, the only checksum input difference was `Replica.pathHash`: - Leader: actual pathHash value - Follower: `-1` Other fields, including partition version, tablets, replicas, and replica states, were unchanged. ### Anything Else? There appears to be a design trade-off: 1. Synchronize `pathHash` to Followers through EditLog/replay. - Keeps pathHash as a metadata invalidation signal. - Requires a new persistence and replay path. 2. Exclude `pathHash` from the checksum used by Remote Doris Catalog. - Avoids unnecessary metadata refreshes caused by Leader/Follower checksum inconsistency. - Remote cache refresh would no longer be triggered solely by pathHash changes. In addition, `pathHash` is not serialized in the partition payload returned to the remote client, so it currently causes cache invalidation but cannot be synchronized to the client through metadata refresh. Could the community help clarify the expected semantics of `pathHash` in Remote Doris Catalog metadata consistency and recommend an appropriate fix? ### Are you willing to submit PR? - [ ] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
