Re: Replication

Hi Mike

thanks for your interest in rubyrep. I developed rubyrep. Let me
answer your questions.

On Jun 23, 4:16 pm, m...@kitchenpc.com (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