rjames@stripped ("Rick James") writes:
> If such existed, there would be a big caveat... The various masters
> should not replicate to the same tables. If they do, there is a big
> risk of errors discovered on the Slave (duplicate key, etc). These
> freeze replication until a human takes some kind of action.
That's no different to now with a single master and multiple
slaves. If you want to do something like N -> 1 replication you need to
know what you are doing and how to avoid conflicts. One you think
about that there's no problem.
With the sybase setup we used we just had a column on each master
"cell number" which was constant, but different on each server. This
was part of the primary key. On the slave which collected data from
several machines the result was that the table contained data for
So that's something that's easy to resolve.
> Since replication is single threaded on the slave, it might be desirable
> to have both threads duplicated. Then, IF the user keeps his Masters
> from stepping into each other's turf, you could get parallelism that
> does not exist today! :)
Well the idea I had would have no replication thread on the slave: it
would simply be a "SQL client", connecting from the "replication
process" granted the appropriate permissions to do it's job. So if you
had a N -> 1 setup of course there would be "N" SQL clients running on
the slave each applying their replication process' relay logs to the
That would give you more paralellism but really that's irrelevant:
you're solving a different problem to the problem solved by the
current built-in replication functionality provided by mysqld.