Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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.



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

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


pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group