From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Streaming Replication docs |
Date: | 2010-02-12 09:14:18 |
Message-ID: | 4B751BEA.7000202@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
One glaring issue with the current documentation layout is that the
documentation for the various options in recovery.conf is split in two
places. The old options, restore_command, recovery_target_* and so forth
are in section "24.3.3.1 Recovery Settings", while the new streaming
replication related options are in "25.3.1 Setup [of streaming
replication]".
It's pretty clear that we should have a single place that documents all
the recovery.conf options. I suggest that we move the "24.3.3.1 Recovery
Settings" section after "High Availability, Load Balancing, and
Replication", and add the new streaming replication related options
there. The previous sections would still briefly describe the most
important settings and give examples, but the new section would be the
authoritative reference page for recovery.conf.
So the new layout would be:
III. Server Administration
...
21. Managing Databases
22. Localization
23. Routine Database Maintenance Tasks
24. Backup and Restore
25. High Availability, Load Balancing, and Replication
* 26. Recovery Configuration *
27. Monitoring Database Activity
28. Monitoring Disk Usage
29. Reliability and the Write-Ahead Log
30. Regression Tests
Thoughts, better ideas?
Another change I'd like to make is to document the new built-in way (ie.
standby_mode='on', restore_command='cp ...', primary_conninfo not set)
as the primary way of implementing file-based log shipping. Using
pg_standby or similar scripts that do the waiting would still be
documented, but I'd like to de-emphasize it, moving it into an
"Alternative way to implement File-based log shipping" section. The
description would go along the lines of "An alternative way to implement
File-based log shipping is to leave standby_mode='false', and use a
restore_command that waits until the next WAL file arrives. This offers
more flexibility and control over the process. ..."
The reason for that is that it would make the documentation flow better
with Streaming Replication. In a nutshell, there would be three steps to
set up a full streaming replication system:
1. Set up WAL archiving in master (section "24.3 Continuous Archiving
and Point-In-Time Recovery")
2. Use the WAL archive to implement file-based log shipping (Section
"25.2 File-based Log Shipping")
3. Add streaming replication to the file-based log shipping (Section
25.3 Streaming Replication") setup.
Each section could then simply refer to the previous step: "first set up
... as described in section ...". The new way of setting up file-based
log shipping is a little bit easier than pg_standby to set up anyway
(not that pg_standby is hard either), so it would be good to describe
the simpler method first anyway.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2010-02-12 10:09:40 | Re: Streaming Replication docs |
Previous Message | Heikki Linnakangas | 2010-02-12 07:37:40 | Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-02-12 09:17:59 | Re: Parameter name standby_mode |
Previous Message | Joachim Wieland | 2010-02-12 09:11:36 | Re: Parameter name standby_mode |