-
Notifications
You must be signed in to change notification settings - Fork 10
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
Add a backup page, due to problems with parallelized restore #17
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,32 @@ | ||
Backups & Restore | ||
================= | ||
|
||
Backup | ||
------ | ||
|
||
To create logical backups of the OPM database, use pg_dump as usual. | ||
You can save much time with parallelization, eg: | ||
|
||
.. code-block:: bash | ||
|
||
pg_dump -Fd -j8 -d opm -f opm.dump | ||
|
||
|
||
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 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. | ||
|
||
The following commands assume that the database and the roles were already created, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. maybe "The following commands are an example of such a workaround, and assume that..."? |
||
and the backup was not done in a plain format: | ||
|
||
.. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe some better names? Like opm_small_tables.list and opm_big_tables? Feel free to suggest better names. |
||
pg_restore -e --section=data -l opm.dump|grep 'service_counters_' > restore.2.list | ||
pg_restore -e -d opm -L restore.1.list opm.dump | ||
pg_restore -e -d opm -L restore.2.list opm.dump --jobs=4 | ||
pg_restore -e --section=post-data -d opm opm.dump --jobs=4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.