Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XlnHc-00035C-Ax for pgsql-docs@arkaria.postgresql.org; Tue, 04 Nov 2014 23:13:04 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XlnHb-0005m3-Ry for pgsql-docs@arkaria.postgresql.org; Tue, 04 Nov 2014 23:13:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XlnHb-0005lv-Ay for pgsql-docs@postgresql.org; Tue, 04 Nov 2014 23:13:03 +0000 Received: from 01.zmailcloud.com ([192.198.85.104] helo=mx-out-1.zmailcloud.com) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XlnHW-00025R-Hu for pgsql-docs@postgresql.org; Tue, 04 Nov 2014 23:13:02 +0000 Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 3BB9D564890 for ; Tue, 4 Nov 2014 17:12:57 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 31EAF602FA for ; Tue, 4 Nov 2014 17:12:57 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOjoVp5_4Ueg for ; Tue, 4 Nov 2014 17:12:57 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 1388C60205 for ; Tue, 4 Nov 2014 17:12:57 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id F186B602FA for ; Tue, 4 Nov 2014 17:12:56 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id L0R0iw7sMnzR for ; Tue, 4 Nov 2014 17:12:56 -0600 (CST) Received: from [172.47.23.103] (50-0-89-106.dsl.dynamic.fusionbroadband.com [50.0.89.106]) by smtp-out-2.01.com (Postfix) with ESMTPSA id A85ED60205 for ; Tue, 4 Nov 2014 17:12:56 -0600 (CST) Message-ID: <54595D77.6020707@agliodbs.com> Date: Tue, 04 Nov 2014 15:12:55 -0800 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: pgsql-docs@postgresql.org Subject: Re: 9.4 recommendations for archive_command vs. replication slots References: <54454EB7.9010601@gmx.net> <54516E69.2060007@agliodbs.com> <54591901.4080808@gmx.net> <54594742.7080707@agliodbs.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org 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 -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs