Peer to peer replication of Postgresql databases

From: Anuradha Ratnaweera <anuradha(at)lklug(dot)pdn(dot)ac(dot)lk>
To: pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Peer to peer replication of Postgresql databases
Date: 2002-10-11 10:16:57
Message-ID: 20021011101657.GA6745@lklug.pdn.ac.lk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


Hi all,

I am trying to add some replication features to postgres (yes, I have
already looked at ongoing work), in a peer to peer manner. The goal
is to achive `nearly complete fault tolerence' by replicating data.

The basic framework I have in mind is somewhat like this.

- Postmasters are running on different computers on a networked cluster.
Their data areas are identical at the beginning and recide on local
storage devices.

- Each postmaster is aware that they are a part of a cluster and they
can communicate with each other, send multicast requests and look for
each other's presence (like heartbeat in linux-ha project).

- When a frontend process sends a read query, each backend process
does that from its own data area.

- There are two types of write queries. Postmasters use seperate
communication channels for each. One is the sequencial channel which
carries writes whose order is important, and the non-sequencial
channel carries write queries whose order is not important.

- When a frontend process sends non-sequencial write query to a backend,
it is directly written to the local data area and a multicast is
sent (preferably asynchronously) to the other postmasters who will
also update their respective local areas.

May be we can simply duplicate what goes to WAL into a TCP/IP socket
(with some header info, of course).

- When a sequencial-write query is requested, the corresponding
postmaster informs a main-postmaster (more about in the next point),
waits for his acknowledgement, and proceeds the same way as the
non-sequencial write.

- Each postmaster is assigned a priority. The one with the highest
priority is doing some bookkeeping to handle concurrency issues etc.
If he goes away, another one takes charge.

Or maybe we can completely ignore the main-postmaster concept and
let the clients broadcast a request to obtain locks etc.

- When a new postmaster, hence a computer, joins the cluster, he
will replicate the current database from one of the clients.

Suggessions and critisisms are welcome.

Anuradha

--

Debian GNU/Linux (kernel 2.4.18-xfs-1.1)

The best audience is intelligent, well-educated and a little drunk.
-- Maurice Baring

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shridhar Daithankar 2002-10-11 10:24:15 Re: Peer to peer replication of Postgresql databases
Previous Message Hans-Jürgen Schönig 2002-10-11 07:21:29 Suggestion: Helping the optimizer

Browse pgsql-patches by date

  From Date Subject
Next Message Shridhar Daithankar 2002-10-11 10:24:15 Re: Peer to peer replication of Postgresql databases
Previous Message Tom Lane 2002-10-11 04:22:03 Re: .cvsignore file