[Bug] after restart partition g-32 not find

[CrazyBeeline]

Bug Type (问题类型)

server status (启动/运行异常)

Before submit

• 我已经确认现有的 Issues 与 FAQ 中没有相同 / 重复问题 (I have confirmed and searched that there are no similar problems in the historical issue and documents)

Environment (环境信息)

• Server Version: 1.5.0
• Backend: hstore

Expected & Actual behavior (期望与实际表现)

1.stop pd hstore
2. start pd ok
3. start store error

pd: error logs

store error logs

Vertex/Edge example (问题点 / 边数据举例)

Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)

[dosubot]

This "partition g-32 not find" error after restart is a known pattern with the hstore backend in distributed deployments. A few things to check:

Startup sequence matters — the correct order is: PD nodes first (wait for leader election) → Store nodes (wait for partition assignment) → Server nodes [1]. If the store starts before PD has fully initialized and assigned partitions, you'll get "partition not found" errors.

PD leader election issue — there's a bug (fixed in PR #2961) where after cluster restart, if PD Raft elects a different leader than before, the cluster can become non-functional due to a NullPointerException in the redirect mechanism [2]. If you're on 1.5.0, check whether this fix is included in your version.

Troubleshooting steps:

1. After starting PD, verify the leader is properly elected before starting stores
2. Check if the store is registered with PD via the /v1/stores endpoint
3. Check partition status via the /v1/partitions endpoint
4. Wait 1-3 minutes after all stores register for partition assignment to complete [3]

If the issue persists, can you share:

• How many PD/Store/Server nodes are in your cluster?
• Did the PD leader change after restart (different node became leader)?
• The full PD and store error logs (the images are hard to parse for specifics)?

This may also relate to a serialization compatibility issue documented in issue #3007 if your data was written by a different version [4].

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[bhavESH-CHAWLA]

understood please assign the issue

[bhavESH-CHAWLA]

I investigated the issue and traced the failure path to PartitionMeta.getPartitionById(), which returns null after PD restart. I'm continuing to check whether partition metadata is not reloaded correctly during startup or if the partition cache is not rebuilt.
Correct me if i am going wrong

[CrazyBeeline]

@bhavESH-CHAWLA The issue occurs intermittently, and recovers after multiple PD restarts.

[bhavESH-CHAWLA]

What i understand is if the partition were truly deleted from RocksDB, restarting PD multiple times would not magically bring it back.

mean it points more toward:

PD startup race condition
OR
cache initialization timing issue
OR
metadata loading not completed when Store requests partition info

[bhavESH-CHAWLA]

Do you think this issue is more likely related to PD startup/leader-election timing and metadata reload rather than missing partition data? i am really confused in tracing the issue.

[CrazyBeeline]

@bhavESH-CHAWLA Yes, it returns to normal after a restart; this happens occasionally.