Jira Data Center cluster: bounding stale search results from index replication without overloading nodes

Goal

I am planning the configuration of a Jira Data Center cluster (assume a recent 9.x LTS line) and want to bound how long a search on one node can return results that do not yet reflect an issue edit made on another node. Each node holds a local Lucene index copy, and changes propagate through the database-backed replication mechanism, so some staleness window appears inherent to the design.

Constraints and uncertainty

There seems to be no supported setting that guarantees zero staleness. The apparent trade-off is between tighter replication or cache-flush behavior (more load on the database and nodes) and accepting a bounded delay. A full lock-and-rebuild re-index corrects persistent staleness but takes Jira offline, so it is not a routine remediation. I am also unsure which delays come from index replication versus node-local caches invalidated by cluster events, since the remediation differs.

Questions

• Is there a documented, supported way to tune the index replication interval or trigger conditions in current Jira Data Center versions, or is the timing fixed?
• What is a reasonable operational approach to measure the actual staleness window on a two-node cluster before deciding whether it is acceptable?
• When staleness persists beyond the normal propagation delay, which signals distinguish an index replication backlog from a stale node-local cache?