Re: Synchronous Log Shipping Replication

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Synchronous Log Shipping Replication
Дата
Msg-id 3f0b79eb0809082244s76c9eb25j7bc4531aec36fef7@mail.gmail.com
обсуждение исходный текст
Ответ на Synchronous Log Shipping Replication  ("Fujii Masao" <masao.fujii@gmail.com>)
Ответы Re: Synchronous Log Shipping Replication
Список 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 по дате отправления:

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: [gsmith@gregsmith.com: Re: [patch] GUC source file and line number]
Следующее
От: Volkan YAZICI
Дата:
Сообщение: Re: Verbosity of Function Return Type Checks