Changes to tombstone GC (mode, gc period, etc) settings don't take full effect till restart (or all sstables are recompacted) #15643
Assignees
Labels
area/compaction
area/schema changes
Backport candidate
backport/5.2
Issues that should be backported to 5.2 branch once they'll be fixed
P1
Urgent
type/bug
Milestone
Comments
mykaul
added
P1
raphaelsc
added a commit
to raphaelsc/scylla
that referenced
this issue
Oct 17, 2023
After "repair: Get rid of the gc_grace_seconds", the sstable's schema (mode, gc period if applicable, etc) is used to estimate the amount of droppable data (or determine full expiration = max_deletion_time < gc_before). It could happen that the user switched from timeout to repair mode, but sstables will still use the old mode, despite the user asked for a new one. Another example is when you play with value of grace period, to prevent data resurrection if repair won't be able to run in a timely manner. The problem persists until all sstables using old GC mode are recompacted or node is restarted. To fix this, we have to feed latest schema into sstable procedures used for expiration purposes. Fixes scylladb#15643. Signed-off-by: Raphael S. Carvalho <raphaelsc@scylladb.com>
raphaelsc
added a commit
to raphaelsc/scylla
that referenced
this issue
Oct 17, 2023
After "repair: Get rid of the gc_grace_seconds", the sstable's schema (mode, gc period if applicable, etc) is used to estimate the amount of droppable data (or determine full expiration = max_deletion_time < gc_before). It could happen that the user switched from timeout to repair mode, but sstables will still use the old mode, despite the user asked for a new one. Another example is when you play with value of grace period, to prevent data resurrection if repair won't be able to run in a timely manner. The problem persists until all sstables using old GC settings are recompacted or node is restarted. To fix this, we have to feed latest schema into sstable procedures used for expiration purposes. Fixes scylladb#15643. Signed-off-by: Raphael S. Carvalho <raphaelsc@scylladb.com>
denesb
pushed a commit
that referenced
this issue
Dec 18, 2023
After "repair: Get rid of the gc_grace_seconds", the sstable's schema (mode, gc period if applicable, etc) is used to estimate the amount of droppable data (or determine full expiration = max_deletion_time < gc_before). It could happen that the user switched from timeout to repair mode, but sstables will still use the old mode, despite the user asked for a new one. Another example is when you play with value of grace period, to prevent data resurrection if repair won't be able to run in a timely manner. The problem persists until all sstables using old GC settings are recompacted or node is restarted. To fix this, we have to feed latest schema into sstable procedures used for expiration purposes. Fixes #15643. Signed-off-by: Raphael S. Carvalho <raphaelsc@scylladb.com> Closes #15746 (cherry picked from commit fded314)
denesb
pushed a commit
that referenced
this issue
Dec 18, 2023
After "repair: Get rid of the gc_grace_seconds", the sstable's schema (mode, gc period if applicable, etc) is used to estimate the amount of droppable data (or determine full expiration = max_deletion_time < gc_before). It could happen that the user switched from timeout to repair mode, but sstables will still use the old mode, despite the user asked for a new one. Another example is when you play with value of grace period, to prevent data resurrection if repair won't be able to run in a timely manner. The problem persists until all sstables using old GC settings are recompacted or node is restarted. To fix this, we have to feed latest schema into sstable procedures used for expiration purposes. Fixes #15643. Signed-off-by: Raphael S. Carvalho <raphaelsc@scylladb.com> Closes #15746 (cherry picked from commit fded314)
|
Backported to 5.4 and 5.2. |
denesb
removed
Backport candidate
backport/5.2
|
5.2 backport dequeued, it breaks the build. @raphaelsc please prepare a backport PR. |
denesb
added
Backport candidate
backport/5.2
|
ping @raphaelsc , @denesb for backport. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After "repair: Get rid of the gc_grace_seconds", the sstable's schema (mode, gc period if applicable, etc) is used to estimate the amount of droppable data (or determine full expiration, max_deletion_time < gc_before), but it could happen that the user switched from timeout to repair mode, but sstables will still use the old mode, despite the user asked for a new one. To fix this, we have to feed latest schema into procedures for estimation of droppable data, which in turn uses schema settings for calculation of gc before.
The text was updated successfully, but these errors were encountered: