Re: Synchronous Log Shipping Replication - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Synchronous Log Shipping Replication
Date
Msg-id 3f0b79eb0809082244s76c9eb25j7bc4531aec36fef7@mail.gmail.com
Whole thread Raw
In response to Synchronous Log Shipping Replication  ("Fujii Masao" <masao.fujii@gmail.com>)
Responses Re: Synchronous Log Shipping Replication  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
List pgsql-hackers
Hi,

I looked some comment for the synchronous replication and understood
the consensus of the community was that the sync replication should be
added using not hooks and plug-ins but core-patches. If my understanding
is right, I will change my development plan so that the sync replication
may be put into core.

But, I don't think every features should be put into core. Of course, the
high-availability features (like clustering, automatic failover, ...etc) are
out of postgres. The user who wants whole HA solution using the sync
replication must integrate postgres and clustering software like heartbeat.

WAL sending should be put into core. But, I'd like to separate WAL
receiving from core and provide it as a new contrib tool. Because,
there are some users who use the sync replication as only WAL
streaming. They don't want to start postgres on the slave. Of course,
the slave can replay WAL by using pg_standby and WAL receiver tool
which I'd like to provide as a new contrib tool. I think the patch against
recovery code is not necessary.

I arrange the development items below :

1) Patch around XLogWrite.    It enables a backend to wake up the WAL sender process at the    timing of COMMIT.

2) Patch for the communication between a backend and WAL    sender process.    There were some discussions about this
topic.Now, I decided to    adopt imessages proposed by Markus.
 

3) Patch of introducing new background process which I've called    WALSender. It takes charge of sending WAL to the
slave.
    Now, I assume that WALSender also listens the connection from    the slave, i.e. only one sender process manages
multipleslaves.    The relation between WALSender and backend is 1:1. So,    the communication mechanism between them
canbe simple.    As other idea, I can introduce new listener process and fork new    WALSender for every slave. Which
architectureis better? Or,    should postmaster listen also the connection from the slave?
 

4) New contrib tool which I've called WALReceiver. It takes charge   of receiving WAL from the master and writing it to
diskon the slave.
 

I will submit these patches and tool by Nov Commit Fest at the latest.

Any comment welcome!

best regards

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


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: [gsmith@gregsmith.com: Re: [patch] GUC source file and line number]
Next
From: Volkan YAZICI
Date:
Subject: Re: Verbosity of Function Return Type Checks