Skip to content

Conversation

plaharanne
Copy link
Contributor

@plaharanne plaharanne commented Oct 16, 2025

Summary of changes

If the type of restore is all or tables with gc tables in the list, check if the snapshot contains grand central tables and temporary rename them before executing the RESTORE query.
When the snapshot is restored, either drop the old gc tables or rename them back if it failed.

Checklist

@plaharanne plaharanne force-pushed the p/restore-snapshot-with-gc branch 3 times, most recently from a09f628 to d259b58 Compare October 16, 2025 16:27
fix uppercase in test

add debug logs

change query to get gc tables

debug on dev

fix table name in query
@plaharanne plaharanne force-pushed the p/restore-snapshot-with-gc branch from e71ae16 to 35b7510 Compare October 16, 2025 16:32
@plaharanne plaharanne force-pushed the p/restore-snapshot-with-gc branch from b4dd6ae to a0eeecb Compare October 17, 2025 08:09
@plaharanne plaharanne marked this pull request as ready for review October 17, 2025 13:54
partitions,
sections,
)
except kopf.PermanentError as e:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really nice strategy to ensure a consistent state. But I guess any exception should call the restore_tables function, right? If any other error that you have not captured and dealt with raises an exception it should still restore.

@juanpardo
Copy link
Contributor

@plaharanne I am wondering if Grand Central is being turned off during this process. I hope so because I think it is necessary, otherwise it may crash or recreate the tables. I searched a bit but didn't find anywhere whether GC is shutdown during backup restoration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants