Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[DocDB] Lazy superblock flush: flush metadata update in background even without a new segment allocation #16778

Closed
1 task done
arpang opened this issue Apr 10, 2023 · 0 comments
Closed
1 task done

[DocDB] Lazy superblock flush: flush metadata update in background even without a new segment allocation #16778

arpang opened this issue Apr 10, 2023 · 0 comments
Assignees
@arpang
Labels
area/docdb YugabyteDB core features kind/bug This issue is a bug priority/medium Medium priority issue

Comments

@arpang
Copy link
Contributor

arpang commented Apr 10, 2023 •
edited by jira bot

Jira Link: DB-6132

Description

As a usability enhancement suggested by Mikail, we schedule a superblock flush on every metadata update operation with a delay of a few seconds. This ensures that the superblock is flushed to disk with some delay even when there is no new segment allocation.

Warning: Please confirm that this issue does not contain any sensitive information

  • I confirm this issue does not contain any sensitive information.
@arpang arpang added the area/docdb YugabyteDB core features label Apr 10, 2023
@arpang arpang self-assigned this Apr 10, 2023
@yugabyte-ci yugabyte-ci added kind/bug This issue is a bug priority/medium Medium priority issue labels Apr 10, 2023
arpang added a commit to arpang/yugabyte-db that referenced this issue Apr 26, 2023
@arpang
[yugabyte#16778]: DocDB: Background flush task when lazy superblock f…
f55bbfa 
…lush is enabled

Summary:
As a usability enhancement with lazy superblock flush feature, this diff introduces a background task per tserver that periodically flushes the dirty superblocks in the tserver
flush. This ensures that the superblock is flushed to disk with some delay even when there is no new segment allocation.

Test Plan: TODO

Subscribers: bogdan

Differential Revision: https://phabricator.dev.yugabyte.com/D24673
arpang added a commit that referenced this issue Apr 27, 2023
@arpang
[#16778] DocDB: Background flush task when lazy superblock flush is e…
3d75fd5 
…nabled

Summary: This diff introduces a background task per tserver that periodically flushes the dirty superblocks on the tserver. This is done as a usability enhancement for lazy superblock flush feature to ensure that a dirty superblock is flushed (with some delay) even without a new segment allocation.

Test Plan: Manually verified that the dirty superblocks are flushed by the BG task.

Reviewers: bogdan, timur, slingam

Reviewed By: slingam

Subscribers: ybase, bogdan

Differential Revision: https://phabricator.dev.yugabyte.com/D24673
@arpang arpang closed this as completed Apr 27, 2023
arpang added a commit that referenced this issue Jul 4, 2023
@arpang
[BACKPORT 2.18][#16778] DocDB: Background flush task when lazy superb…
5adaaea 
…lock flush is enabled

Summary:
This diff introduces a background task per tserver that periodically flushes the dirty superblocks on the tserver. This is done as a usability enhancement for lazy superblock flush feature to ensure that a dirty superblock is flushed (with some delay) even without a new segment allocation.
Original commit: 3d75fd5 / D24673
Jira: DB-6132

Test Plan: Manually verified that the dirty superblocks are flushed by the BG task.

Reviewers: bogdan, slingam, timur, abharadwaj

Reviewed By: abharadwaj

Subscribers: bogdan, ybase

Differential Revision: https://phorge.dev.yugabyte.com/D26616
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@arpang arpang

Labels
area/docdb YugabyteDB core features kind/bug This issue is a bug priority/medium Medium priority issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@arpang @yugabyte-ci