Thread: 9.4 recommendations for archive_command vs. replication slots
The 9.4 documentation for streaming replication still starts out by making you set up archive_command and restore_command. Isn't that obsolete now with replication slots? Shouldn't the first step be to set up replication slots and then go from there? If so, I think replication slots should feature more prominently in the release notes.
On 10/20/2014 11:04 AM, Peter Eisentraut wrote: > The 9.4 documentation for streaming replication still starts out by > making you set up archive_command and restore_command. Isn't that > obsolete now with replication slots? Shouldn't the first step be to set > up replication slots and then go from there? Well, bluntly, our replication docs should be taken out behind the barn with an axe. They tell you more about the development history of PostgreSQL than they tell you about how to replicate. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 10/29/14 6:47 PM, Josh Berkus wrote: > On 10/20/2014 11:04 AM, Peter Eisentraut wrote: >> The 9.4 documentation for streaming replication still starts out by >> making you set up archive_command and restore_command. Isn't that >> obsolete now with replication slots? Shouldn't the first step be to set >> up replication slots and then go from there? > > Well, bluntly, our replication docs should be taken out behind the barn > with an axe. They tell you more about the development history of > PostgreSQL than they tell you about how to replicate. That's true, but can we come to a consensus of what the preferred advertised method should be?
On 11/04/2014 10:20 AM, Peter Eisentraut wrote:
> On 10/29/14 6:47 PM, Josh Berkus wrote:
>> On 10/20/2014 11:04 AM, Peter Eisentraut wrote:
>>> The 9.4 documentation for streaming replication still starts out by
>>> making you set up archive_command and restore_command. Isn't that
>>> obsolete now with replication slots? Shouldn't the first step be to set
>>> up replication slots and then go from there?
>>
>> Well, bluntly, our replication docs should be taken out behind the barn
>> with an axe. They tell you more about the development history of
>> PostgreSQL than they tell you about how to replicate.
>
> That's true, but can we come to a consensus of what the preferred
> advertised method should be?
We should do this tutorial-style, taking things through increasingly
complex replication setups:
1) simple two-server with pg_basebackup, no archiving, no slots
(i.e. "replication in 5 minutes")
2) replication with archiving
3) replication with replication slots
including "wal_keep_segments vs. replication slots"
4) synchronous replication
5) cascading replication
6) archiving-only replication
7) replication performance tuning
I could write this if I *don't* need to do it as a patch against the
existing docs.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
On 11/04/2014 01:38 PM, Josh Berkus wrote: > On 11/04/2014 10:20 AM, Peter Eisentraut wrote: >> On 10/29/14 6:47 PM, Josh Berkus wrote: >>> On 10/20/2014 11:04 AM, Peter Eisentraut wrote: >>>> The 9.4 documentation for streaming replication still starts out by >>>> making you set up archive_command and restore_command. Isn't that >>>> obsolete now with replication slots? Shouldn't the first step be to set >>>> up replication slots and then go from there? >>> >>> Well, bluntly, our replication docs should be taken out behind the barn >>> with an axe. They tell you more about the development history of >>> PostgreSQL than they tell you about how to replicate. >> >> That's true, but can we come to a consensus of what the preferred >> advertised method should be? > > We should do this tutorial-style, taking things through increasingly > complex replication setups: > > 1) simple two-server with pg_basebackup, no archiving, no slots > (i.e. "replication in 5 minutes") > 2) replication with archiving > 3) replication with replication slots > including "wal_keep_segments vs. replication slots" > 4) synchronous replication > 5) cascading replication > 6) archiving-only replication > 7) replication performance tuning > > I could write this if I *don't* need to do it as a patch against the > existing docs. Also, specifically, having replication slots doesn't make having a shared archive an obsolete approach. In many cases, if the replicas are offline for a while you don't want to burden the master with helping them catch up. So its an equal alternative to replication slots. What's significantly less useful now is wal_keep_segments. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com