Re: Replication
От | Gavin Sherry |
---|---|
Тема | Re: Replication |
Дата | |
Msg-id | Pine.LNX.4.21.0202071751240.5160-100000@linuxworld.com.au обсуждение исходный текст |
Ответ на | Replication (mlw <markw@mohawksoft.com>) |
Ответы |
Re: Replication
|
Список | pgsql-hackers |
On Mon, 4 Feb 2002, mlw wrote: > I re-wrote RServ.pm to C, and wrote a replication daemon. It works, but it > works like the whole rserv project. I don't like it. > > OK, what the hell do we need to do to get PostgreSQL replicating? The trigger model is not a very sophisticated one. I think I have a better -- though more complicated -- one. This model would be able to handle multiple masters and master->slave. First of all, all machines in the cluster would have to be aware all the machines in the cluster. This would have to be stored in a new system table. The FE/BE protocol would need to be modified to accepted parsed node trees generated by pg_analyze_and_rewrite(). These could then be dispatched by the executing server, inside of pg_exec_query_string, to all other servers in the cluster (excluding itself). Naturally, this dispatch would need to be non-blocking. pg_exec_query_string() would need to check that nodetags to make sure selects and perhaps some commands are not dispatched. Before the executing server runs finish_xact_command(), it would check that the query was successfully executed on all machines otherwise abort. Such a system would need a few configuration options: whether or not you abort on failed replication to slaves, the ability to replicate only certain tables, etc. Naturally, this would slow down writes to the system (possibly a lot depending on the performance difference between the executing machine and the least powerful machine in the cluster), but most usages of postgresql are read intensive, not write. Any reason this model would not work? Gavin
В списке pgsql-hackers по дате отправления: