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  ("Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>)
Re: Peer to peer replication of Postgresql databases  (Neil Conway <neilc@samurai.com>)
Список 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 по дате отправления:

Предыдущее
От: Hans-Jürgen Schönig
Дата:
Сообщение: Suggestion: Helping the optimizer
Следующее
От: "Shridhar Daithankar"
Дата:
Сообщение: Re: Peer to peer replication of Postgresql databases