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
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 |
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 |