From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Simplifying replication
Date: Wed, 20 Oct 2010 14:50:53 +0200
Message-ID: <m239s1f2oi.fsf@2ndQuadrant.fr> (raw)
In-Reply-To: <4CBDC461.3050401@agliodbs.com>
References: <4CBCE356.2080703@agliodbs.com>
<m28w1ushwz.fsf@2ndQuadrant.fr>
<4CBDC461.3050401@agliodbs.com>
Josh Berkus <josh@agliodbs.com> writes:
> Well, one thing to be addressed is separating the PITR functionality from
> replication. PITR needs a lot of features -- timelines, recovery stop
> points, etc. -- which replication doesn't need or want. I think that
> focussing on streaming replication functionality and ignoring the archive
> logs case is probably the best way to logically separate these two.
> Presumably anyone who needs archive logs as well will be a professional DBA.
So, I've been thinking some more about this.
We now have two modes of operation when starting up a PostgreSQL
cluster, either it's a primary/master or it's a standby (in recovery or
hot_standby). What I think would make sense here would be to add another
mode of operation, archiving.
A cluster that is archiving will accept replication connections and will
accept WAL files streamed there, that it will put on its archive
directory, defaults to $PGDATA/pg_xlog_archive. It should also be able
to take a base backup from its primary server, maybe with a new pg_ctl
command. The base backup location defaults to
$PGDATA/pg_basebackup/$label.
Then, it would also accept replication connection in the other way
around, starting a walsender to publish its archive or its base backup,
so that you could prepare a new standby against the archive server, then
switch the primary_conninfo to the master and that's it.
Now, the archive and restore commands in this setup would be internal
commands pg_walsender and pg_walreceiver. That would mean we need to
extend those spacial backends to be able to send and receive a full WAL
file but it sounds simple enough, right?
Then we could add support for those to compress the WAL files before
streaming, as we're talking "internal commands" here it sounds easy
enough (we're already linking against gzip I think).
The base backup streaming support would be there for the archiving mode
but also for the normal standby "empty $PGDATA" initial start up.
Comments?
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: dimitri@2ndQuadrant.fr, josh@agliodbs.com
Subject: Re: Simplifying replication
In-Reply-To: <m239s1f2oi.fsf@2ndQuadrant.fr>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox