From: Simon J Mudd Date: August 29 2008 6:22am Subject: Re: Thoughts on MySQL replication List-Archive: http://lists.mysql.com/replication/1426 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 various cells. 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 slave. 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. Simon