Add a backup page, due to problems with parallelized restore #17
Conversation
opm-core/Backups.rst
Outdated
| Restoring logical backups | ||
| ------------------------- | ||
|
|
||
| In a general way, restoring a backup created with pg_dump should not be a problem as the backup contains the necessary `CREATE EXTENSION` orders. The extension binaries must be present. |
There was a problem hiding this comment.
OPM doesn't have any binaries. If you want to be stick to general recommendation that to apply to OPM, we should mention something like "All extension files (binaries, shared librraries, SQL files...)".
There was a problem hiding this comment.
Oops, sorry I totally forgot about that PR. I will come back to it very soon!
|
Sorry, I had totally forgotten this PR. I've pushed the modifications. |
|
|
||
| In a general way, restoring a backup created with pg_dump should not be a problem, as the backup contains the necessary `CREATE EXTENSION` orders. The extensions must be installed for the target PostgreSQL version (see `Installation <Installation>`). | ||
|
|
||
| You may wish to parallelize the restoration to spare time. In this case, it may fail with a foreign key error, as the extensions install tables with foreign keys at the very beginning of the restore, and pg_restore does not try to respect this order. The trick is to parallelize only the restoration of the biggest tables. |
There was a problem hiding this comment.
I think it would be better to say "to save time".
Also, you mention the target PostgreSQL version. It kind of imply that this is a procedure generally used for major upgrade more than a general backup solution. It would be better to be more precise here that as we don't want to recommend pg_dump style backup as the best backup approach. So I would recommend to mention that PITR style backup don't have specific gotchas with OPM, and that's a form of backup that should generally be preferred.
I'm also not a fan of simply saying "The trick is...". Maybe "the best way to work around that problem is..."?
It also wouldn't hurt to explicitly mention here that the service_counters_* tables are the biggest table for OPM.
|
|
||
| You may wish to parallelize the restoration to spare time. In this case, it may fail with a foreign key error, as the extensions install tables with foreign keys at the very beginning of the restore, and pg_restore does not try to respect this order. The trick is to parallelize only the restoration of the biggest tables. | ||
|
|
||
| The following commands assume that the database and the roles were already created, |
There was a problem hiding this comment.
maybe "The following commands are an example of such a workaround, and assume that..."?
| .. code-block:: bash | ||
|
|
||
| pg_restore -e --section=pre-data -d opm opm.dump | ||
| pg_restore -e --section=data -l opm.dump|grep -v 'service_counters_' > restore.1.list |
There was a problem hiding this comment.
Maybe some better names? Like opm_small_tables.list and opm_big_tables? Feel free to suggest better names.
A parallelized logical restore may fail, as seen in #16. Add the procedure. Add a Backups page and some generalities as there was none.