Peer to peer replication of Postgresql databases
От | Anuradha Ratnaweera |
---|---|
Тема | Peer to peer replication of Postgresql databases |
Дата | |
Msg-id | 20021011101657.GA6745@lklug.pdn.ac.lk обсуждение исходный текст |
Ответы |
Re: Peer to peer replication of Postgresql databases
Re: Peer to peer replication of Postgresql databases |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: