Maintain a per-originating-node-id partition within the transaction log, so replicated writes from node A and writes originating on the local node are tracked in separate sequences.
Why
- Per-node transaction logs enable efficient selective catch-up: a new or restarting node can request only the transactions it missed from a specific origin, rather than scanning a global log.
- Conflict detection and resolution can be scoped to per-node streams.
- Per-node audit trails are cleaner for debugging replication issues.
Design note (from Jira)
"This may only be feasible in our new transaction log system with rocksdb-js."
This is gated on the new transaction log format being built in CORE-2992 ("Create new transaction entry format"). File this to be scheduled once that lands.
Acceptance criteria (once gate is met)
- Each replication transaction carries its originating node ID.
- The transaction log can be queried/iterated per-origin node.
cluster_status / replication sync check can use per-node log position.
Status
Not Ready — dependent on CORE-2992 completing.
Jira fields: Feature Type: Tech Debt · Business Impact: Operational efficiency (both suggested)
🤖 Filed by Claude on behalf of Kris.
Maintain a per-originating-node-id partition within the transaction log, so replicated writes from node A and writes originating on the local node are tracked in separate sequences.
Why
Design note (from Jira)
This is gated on the new transaction log format being built in CORE-2992 ("Create new transaction entry format"). File this to be scheduled once that lands.
Acceptance criteria (once gate is met)
cluster_status/ replication sync check can use per-node log position.Status
Not Ready — dependent on CORE-2992 completing.
Jira fields: Feature Type: Tech Debt · Business Impact: Operational efficiency (both suggested)
🤖 Filed by Claude on behalf of Kris.