aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDrew DeVault <sir@cmpwn.com>2020-06-30 12:01:38 -0400
committerDrew DeVault <sir@cmpwn.com>2020-06-30 12:01:38 -0400
commit3fa17ac835da9f7ed6d128f1ac7e6de2e2271140 (patch)
tree2ac98980ebf6018feee90a2311bb014da38072a0
parent134328b0ed45995ec33928d0f6738bcdd071fe0a (diff)
downloadsr.ht-docs-3fa17ac835da9f7ed6d128f1ac7e6de2e2271140.tar.gz
Update PSQL plans
-rw-r--r--ops/robust-psql.md23
1 files changed, 14 insertions, 9 deletions
diff --git a/ops/robust-psql.md b/ops/robust-psql.md
index bd24387..a3c8d7c 100644
--- a/ops/robust-psql.md
+++ b/ops/robust-psql.md
@@ -37,23 +37,28 @@ reconfigure it as a [hot standby][hot standby] (which will accept queries).
replication. It must have the REPLICATION and LOGIN privileges and
[pg_hba.conf][hba changes] must be updated.
1. Take a [base backup][base backup] of the primary and ship it to the
- secondary. Be advised: we have full_page_writes disabled as a ZFS
+ secondary. Be advised: we have `full_page_writes` disabled as a ZFS
optimization; this may cause performance degredation during the basebackup
- process.
+ process. `pg_basebackup -PzFt -D basebackup`. Place 'basedirectory' in
+ `/var/lib/postgresql`.
+1. Nuke the postgres data directory's contents on the secondary, su to postgres,
+ then run these commands: `tar -C ~/12/data -xf ~/basebackup/base.tar.gz`,
+ `tar -C ~/12/data/pg_wal -xf ~/basebackup/pg_wal.tar.gz`,
+ `touch ~/12/data/standby.signal`
1. Fill out `primary_conninfo` on the secondary with the connection details for
- the account created for replication.
+ the account created for replication. `host=... port=5432 user=... password=...`
1. Configure a replication slot on the primary for the secondary:
SELECT * FROM pg_create_physical_replication_slot('konpaku');
Then set `primary_slot_name` to `konpaku` on the secondary.
-1. Set `hot_standby` to true on the secondary.
-1. [Restore the base backup][restore base backup] on the secondary. It will
- automatically sync with the primary when complete; monitor the logs. TODO:
- What should our `restore_command` be? Want to figure it out in advance.
+1. Set `hot_standby` to "on" on the secondary.
+1. Start the database, monitor logs for restore completion.
1. Sanity check the secondary database.
-1. Roll back the `restore_command` change so that we aren't surprised by it
- later. Drop the base backup files as well.
+
+Note: some of this procedure is adapted from the
+[restore the base backup][restore base backup] docs, but modified cause those
+docs are shit.
[warm standby]: https://www.postgresql.org/docs/current/warm-standby.html
[hot standby]: https://www.postgresql.org/docs/current/hot-standby.html