Re: Postgres Replication
От | Darren Johnson |
---|---|
Тема | Re: Postgres Replication |
Дата | |
Msg-id | 3B257969.6050405@greatbridge.com обсуждение исходный текст |
Ответ на | Re: Postgres Replication (Alex Pilosov <alex@pilosoft.com>) |
Список | pgsql-hackers |
Thanks for the feedback. I'll try to address both your issues here. >> what does "manager controls all the transactions" mean? > The replication manager controls the transactions by serializing the write set messages. This ensures all transactions are committed in the same order on each server, so bugs here are not allowed ;-) >> I hope it does >> *not* mean that a bug in the manager would cause transactions not to >> commit... > > Well yeah it does. Bugs are a fact of life. : > >>> 4) Based on a two phase locking approach, all dead lock situations >>> are local and detectable by Postgres-R code base, and aborted. >> >> Does this imply locking over different servers? That would mean a >> grinding halt when a network outage occurs... > > Don't know, but see below. There is a branch of the Postgres-R code that has some failure detection implemented, so we will have to merge this functionality with the version of Postgres-R we have, and test this issue. I'll let you the results. >> >> - the replication server stores incoming data in a que ("stable >> device"), until it is sure it has reached its final destination > I like this idea for recovering servers that have been down a short period of time, using WAL to recover transactions missed during the outage. >> >> This kind of architecture has several advantages: >> - only committed transactions are replicated which saves overhead >> - it does not have very much impact on performance of the source >> server (apart from reading the WAL) >> - since every replication server has a stable device, data is stored >> when the network is down and nothing gets lost (nor stops performing) >> - because only the log reader and the connection from the final >> replication server are RDBMS specific, it is possible to replicate >> from MS to Oracle using a Sybase replication server (or different >> versions etc). > There are some issues with the "log reader" approach: 1) The databases are not synchronized until the log reader completes its processing. 2) I'm not sure about Sybase, but the log reader sends SQL statements to the other servers which are then parsed, planned and executed. This over head could be avoided if only the tuple changes are replicated. 3) Works fine for read only situations, but peer-to-peer applications using this approach must be designed with a conflict resolution scheme. Don't get me wrong, I believe we can learn from the replication techniques used by commercial databases like Sybase, and try to implement the good ones into PostgreSQL. Postgres-R is a synchronous approach which out performs the traditional approaches to synchronous replication. Being based on PostgreSQL-6.4.2, getting this approach in the 7.2 tree might be better than reinventing the wheel. Thanks again, Darren Thanks again, Darren
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Alex PilosovДата:
Сообщение: [PATCH] addition of text_inet, text_cidr and inet_set_masklen