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
backup / restore: add switch to process only METAdata of table(s) and skip it's DATA [CORE4343] #4665
Comments
Commented by: @pavel-zotov PS. Also it will be very useful to have such key that will INCLUDE (rahter than BYPASS) only selected table(s) data (and for any other tables engine will b/r only METAdata; e.g. all of them will be "skipped" from b/r their data). |
Modified by: @dyemanovComponent: GBAK [ 10006 ] summary: backup / restore speedup: add switch to process only METAdata of table(s) and skip it's DATA => backup / restore: add switch to process only METAdata of table(s) and skip it's DATA |
Commented by: Sean Leyne (seanleyne) FYI, the feature to exclude/skip restoring data for selected tables is already available with the RedSoft database fork -- the option/switch named "-skip_data". The feature supports wildcard and regex to define the tables to be processed.. An appropriate name for the opposite switch could be "restore_only" |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovstatus: Closed [ 6 ] => Closed [ 6 ] QA Status: Covered by another test(s) Test Details: See core_2208.fbt |
Submitted by: @pavel-zotov
Duplicates CORE2208
It will be useful to bypass handling DATA of some huge tables that are NOT parent to some other ones (e.g. have no link from some FKs).
For instance, in our production one of the tables consumes more than 60% of time to be restored (this is AUDIT table: it will never be *parent* for any kind of other tables).
I propose to add the switch like '-s table1[, -s table2[, -s .....]' that can occur many times in command that runs gbak and this switch will force engine to b/r only METADATA of corresponding table(s).
If any of such tables is PARENT for some other one(s), operation should be abandon.
====== Test Details ======
See core_2208.fbt
The text was updated successfully, but these errors were encountered: