nirdosh0110 commented on PR #8584: URL: https://github.com/apache/hbase/pull/8584#issuecomment-5680331910
Fair — for a pure server crash we'd have stale data anyway, bounded by `msginterval`. RS already sends `completedSequenceId` for every region on every heartbeat, so master's map is continuously refreshed on the happy path, and pure-crash isn't really the differentiator between CLOSE-time and OPEN-time. The scenario this PR is targeting is *graceful move + later crash of the source RS*: 1. `t=0` — source RS cleanly closes R (flush to close-marker). Target RS opens R with `openSeqNum` bumped past close-marker. But master's `flushedSequenceIdByRegion[R]` still reflects the last heartbeat from the source RS, which was written **before** the close-flush landed — so it's stale. 2. `t=25s` — source RS dies. SCP walks its WAL and filters using `flushedSequenceIdByRegion[R]` — still the stale pre-close value. Recovered.edits are written for edits that are already durable in HFiles. 3. Later split/merge on R fails `checkClosedRegion` on those stale recovered.edits. Both CLOSE-time and OPEN-time seeding would fix this. Reasons I kept OPEN-time: - `openSeqNum` ≥ close-marker, so it's an at-least-as-tight fence. - Fires on every OPEN (reassignment after SCP, master restart, RS restart), not only clean closes. - Reuses the existing `reportRegionOpen` payload that already carries `openSeqNum` — no new field on the close report. -- 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]
