Hi Mike thanks for your interest in rubyrep. I developed rubyrep. Let me answer your questions. On Jun 23, 4:16 pm, m...@xxxxxxxxxxxxx (Mike Christensen) wrote: > There will be a set of triggers for each replication. Since MySql doesn't > support more than one trigger on a table, this approach won't work which I > guess is their way of saying "We're database independent, as long as you use > either Postgres or MySql oh and btw we have no replication story above 2 > nodes on MySQL" The first statement on the rubyrep project website says that rubyrep provides database independent - currently supporting PostgreSQL and MySQL - master-master replication [i. e. 2 databases]. That statement is 100% correct. Regarding multi-master replication (i. e. more than 2 databases) the according sub page says that it only works for PostgreSQL. I intended both statements to be very clear and *not* misleading. If you think they are not, I am interested in hearing your improvement suggestions. > > Also, if database C goes down, then everything goes kaboom, right? Even if > you did A replicates with B, B replicates with C, if one database goes down > your chain is broken. I'm worried about this scenario, Assuming that A replicates with C and C with B then once C goes down, indeed replication will stop. However nothing goes "kaboom". All changes in either A or B are still tracked in the according queue tables. As soon as C comes up again, all pending changes will be replicated. If let's say C goes down, then replication between A and B will not be affected. Same if A goes down: replication between B and C will continue. >and any perf > implications with having a whole bunch of triggers on a table. Maybe > someone can comment. The triggers are designed to be as "lean" as possible. Actually all they do is to add the primary key of a created / modified / deleted row into the queue table. I don't think that this will cause any performance impact. (The actual work is done by the rubyrep process which applies all changes. That process can be run on a totally different server to avoid impacting the database server performance.) Regards, Arndt -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
