Re: 9.4 recommendations for archive_command vs. replication slots

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