Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
73487: kvserver: emit `AddSSTable` events via rangefeeds r=miretskiy a=erikgrinaker **testutils: add sstutil package** This patch adds a `testutils/sstutil` package with SST-related test utilities. Release note: None **kvserver: disconnect rangefeeds on MVCC history mutations** This patch adds a field `MVCCHistoryMutation` to `ReplicatedEvalResult`, which disconnects any rangefeeds that overlap with the command span. Callers are expected to ensure there are no rangefeeds over such spans, but if they fail to do so it is better to error out rather than silently pretend like nothing happened. The field is set for `AddSSTable`, `ClearRange`, and `RevertRange` requests. This error is exposed via the `OnInternalError` callback for `rangefeed.Factory`-based rangefeed clients. However, if this callback is not set, these clients will silently stop processing events. This is unfortunate, but follows from the API design. Most callers do not appear to set such a callback, and it is left for the owning teams to update the usage of the library with appropriate error handling. Furthermore, this error detection requires knowledge about the new `MVCCHistoryMutationError` error type, so older nodes in mixed-version clusters will simply treat this as a retryable error. Touches cockroachdb#70434. Release note: None **kvserver: emit AddSSTable events via rangefeeds** This patch emits `AddSSTable` events across rangefeeds when the ingestion was done with `WriteAtRequestTimestamp` enabled (since this ensures they respect the closed timestamp). This setting is introduced with 22.1, and callers must check the `MVCCAddSStable` version gate before using it, so by extension this event is only emitted once the entire cluster runs 22.1. Clients built via `rangefeed.Factory` have a new `WithOnSSTable` option that can be used to register a callback for these events. If such a callback is not set, the rangefeed will run a catchup scan that includes the values written by the `AddSSTable` request. The entire SST is emitted in binary form, regardless of how the registration span overlaps it -- it is up to callers to prune the SST contents as appropriate. Previous values are not included for keys replaced by the SST. Resolves cockroachdb#70434. Release note: None --- Initial draft. A few outstanding questions: 1. ~~Changefeeds will error on these SST events. We currently do not expect to ingest SSTs into online tables, and thus we do not expect changefeeds to see these events. Now that we have MVCC-compliant `AddSSTable` we _could_ begin to use `AddSSTable` into online tables, and thus the changefeeds would need to handle this (note here that the SST events do not contain previous value diffs), but I figure we can cross that bridge when we get there. Does this make sense?~~ 2. ~~Internal consumers that subscribe via `rangefeed.Factory` must register an `OnSSTable` handler, otherwise they will not be notified about such events. I'm not sure if we ever expect to ingest SSTs into e.g. online system spans and such, but we may want to consider sending such subscribers an error if they haven't registered `OnSSTable` rather than silently ignoring them.~~ 3. These events are likely to be much larger than regular key/value events, and thus there is a greater risk of excessive memory usage since the buffer size per replica is 4096 events. The SSTs are already in memory due to Raft application, but buffering them here can cause them to stick around and pile up. We should consider adding memory accounting here, and use a store-wide memory limit rather than a per-replica fixed-size queue. See: cockroachdb#73616. Co-authored-by: Erik Grinaker <[email protected]>
- Loading branch information