-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
streamingccl: store replicated time in details #103835
streamingccl: store replicated time in details #103835
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for doing this! I think the only thing I'm unsure about is if we should even continue logging the hwm. I don't think we should as it opens the door to footguns, but curious why you think we should.
@@ -151,6 +151,11 @@ message StreamIngestionProgress { | |||
// consistent state as of the CutoverTime. | |||
util.hlc.Timestamp cutover_time = 1 [(gogoproto.nullable) = false]; | |||
|
|||
// ReplicatedTime is the ingestion frontier. This is the canonical | |||
// value of the frontier. The HighWater in the job progress is for | |||
// informational purposes only. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like we should never log the HighWater in the job progress?
pkg/ccl/streamingccl/streamingest/stream_ingestion_frontier_processor.go
Outdated
Show resolved
Hide resolved
// Keep the recorded replicatedTime empty until some advancement has been made | ||
if sf.replicatedTimeAtStart.Less(replicatedTime) { | ||
streamProgress.ReplicatedTime = replicatedTime | ||
// The HighWater is for informational purposes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we even want to record the hwm, as it opens the door to foot guns.
pkg/ccl/streamingccl/streamingest/stream_ingestion_frontier_processor_test.go
Show resolved
Hide resolved
pkg/ccl/streamingccl/streamingest/replication_stream_e2e_test.go
Outdated
Show resolved
Hide resolved
streamProgress := progress.Details.(*jobspb.Progress_StreamIngest).StreamIngest | ||
streamProgress.ReplicatedTime = hlcReplicatedTime | ||
progress.Progress = &jobspb.Progress_HighWater{ | ||
HighWater: &hlcReplicatedTime, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as I've said elsewhere, I wonder if we should not record the HighWater in Progress.
streamProgress := progress.Details.(*jobspb.Progress_StreamIngest).StreamIngest | ||
streamProgress.ReplicatedTime = cutover | ||
progress.Progress = &jobspb.Progress_HighWater{ | ||
HighWater: &cutover, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: highWater log alert.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for doing this! I think the only thing I'm unsure about is if we should even continue logging the hwm. I don't think we should as it opens the door to footguns, but curious why you think we should.
@msbutler My only hesitation about removing the high watermark completely is that it allows it to be visible in DBConsole, but I agree it is a bit of a footgun. |
Ah I see. FWIW, I hadn't even realized the dbconsole shows the hwm. I feel its fine to drop it from the the db console. It's a time series metric anyway, and I think the replication lag graph provides richer information. one other thing: I think there's some roachtest code you'll need to update as well. |
The cutover process uses the progress field to record how many ranges need to be reverted. This, however, wipes out the high watermark that was previously stored in that progress field. Here, we move the canonical copy of the high watermark to the progress details. For clarity, we rename "high watermark" as "replicated time". Further, we delete a long skipped test that isn't providing much value. Epic: none Release note: None
0b2499a
to
327947f
Compare
Updated the roachtests and addressed comments other than the high watermark issue. Going to spend a few minutes looking into the ux differences |
hrm, I don't see any updates to I defer to you on the dbconsole question. I'll approve whatever. |
one more nit: update the commit/PR message to Fix the original issue? #103534 |
Should be here: https://github.com/cockroachdb/cockroach/pull/103835/files#diff-b713f571096d10de2fe8f435442a825c8b41faaa685a6606a8432a61cf663f02 |
pkg/ccl/streamingccl/streamingest/stream_ingestion_frontier_processor.go
Show resolved
Hide resolved
func (c *streamIngesitonJobInfo) GetHighWater() time.Time { return c.highwaterTime } | ||
// GetHighWater returns the replicated time. The GetHighWater name is | ||
// retained here as this is implementing the jobInfo interface used by | ||
// the latency verifier. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alas.
bors r=msbutler |
Build failed: |
unrelated flake, logged issue here. |
bors retry |
Build succeeded: |
Encountered an error creating backports. Some common things that can go wrong:
You might need to create your backport manually using the backport tool. error creating merge commit from 327947f to blathers/backport-release-23.1-103835: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 23.1.x failed. See errors above. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
The cutover process uses the progress field to record how many ranges need to be reverted. This, however, wipes out the high watermark that was previously stored in that progress field.
Here, we move the canonical copy of the high watermark to the progress details.
For clarity, we rename "high watermark" as "replicated time".
Further, we delete a long skipped test that isn't providing much value.
Fixes #103534
Epic: none
Release note: None