Re: Synchronous replication patch v1 - Mailing list pgsql-hackers

Hi Simon,

On Wed, Nov 5, 2008 at 11:01 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> I would think we would want this integrated into the server as an
> additional special backend, similar to WALWriter. If it works for now,
> that's fine for other testing. This is not an especially difficult
> change, I can help with this.

I integrated walsender into the server as a special backend.
Please check "walsender process patch v1"

http://archives.postgresql.org/pgsql-hackers/2008-11/msg00294.php

> Again, I would expect this to be integrated with server. I would expect
> code to live in src/postmaster/walreceiver.c, with main logic in a file
> alongside xlog.c, perhaps xreceive.c. We would start WALReceiver when we
> enter archive recovery mode - I already have logic for this state
> change. After that you would be able to use the archive location
> specified via recovery.conf.

OK. I will try to integrate walreceiver into the server. But, I'm not
familiar with
Hot-Standby patch including the logic for such a state change. Which patch
do I need to check?

And, we have to decide where an user specifies host name and port number.
I think that recovery.conf is suitable for specifying them. And, If
they are not
specified in recovery.conf, walreceiver would not be invoked.

Is there any parameter required for walreceiver in addition to them?
(additional info for authentication?)

>> > synchronous_replication = on   # immediate replication at commit
>> > replication_timeout = 0ms      # 0 is disabled
>> > wal_sender_delay = 200ms       # 1-10000 milliseconds
>
> Could you write some docs for this? I just want to check how you think
> it will work.
>
> Does synchronous_replication = off mean
> a) asynchronous replication or
> b) no replication at all
>
> I want to be able to specify synch, asynch or no replication.

synchronous_replication is very similar to synchronous_commit.
Docs is as follow.

8<------------------------------
Specifies whether transaction commit will wait for WAL records to be
replicated to
the standby before the command returns a "success" indication to the
client. The
default, and safe, setting is on. When off, there can be a delay between when
success is reported to the client and when the transaction is really
guaranteed to
be safe in the standby against a server crash. (The maximum delay is the same as
wal_sender_delay.) Unlike synchronous_commit, setting this parameter
to off might
cause inconsistency between the database in the primary and the transaction logs
in the standby.

This parameter can be changed at any time; the behavior for any one transaction
is determined by the setting in effect when it writes transaction
logs. It is therefore
possible, and useful, to have some transactions replication
synchronously and others
asynchronously. For example, to make a single multi-statement
transaction replication
asynchronously when the default is the opposite, issue
SET LOCAL synchronous_replication TO OFF within the transaction.
8<------------------------------

I would write the doc also about the other parameters.

> We need an explanation and example of how to set this up when performing
> a large initial base backup. Earlier we discussed using archiver to
> transfer initial files and then switching to streaming mode later. How
> does all that work now?
> http://archives.postgresql.org/pgsql-hackers/2008-09/msg01208.php

I assume the following procedure:

1) Start postgres in the primary
2) Get an online-backup in the primary
3) Locate the online-backup in the standby
4) Start postgres (with walreceiver) in the standby   # Configure restore_command, host of the primary and port in
recovery.conf
5) Manual operation   # If there are missing files for PITR in the standby, copy them
from somewhere      (archive location of the primary, tape backup..etc).      The missing files might be xlog or
historyfile. Since xlog
 
file segment is      switched when replication starts, the missing xlog files would
basically exist      in the archive location of the primary.

I would detail this procedure and write it in doc.

In previous discussion, there was a difference of opinion about who
copies missing
files, postgres (walsender and walreceiver) or outside of postgres.
Since we cannot
expect accurately where missing files are, I think that it's
unsuitable that postgres
copies them.

> I'll be looking at this a lot more over next few weeks/months, so this
> is just a few short initial comments.

Thank you for taking time to review the design!!

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center