Nice example Johan
I try to avoid that inconsistency by always perform operations on Master 1.
I use master 2 only when 1, for some reason, stops.
By the time this happens master 1 just stops working but the application still runs
through Master 2, with all data from Master 1.
Sent from my iPhone
On 27 Oct 2011, at 08:51, Johan De Meersman <vegivamp@stripped> wrote:
> ----- Original Message -----
>> From: "Marcus Bointon" <marcus@stripped>
>> Writing to both masters is not improving your redundancy - it's
>> reducing it! If your replication fails then you've got incomplete
>> data on BOTH servers, not just one.
> Say what? If that's the case, you haven't set up your replication correctly. There
> are quite a few reasons to not use both masters concurrently, but this is not one of
>> You really don't want to do it.
>> This is why MMM sets the passive master to read-only. The increment
> No, it does that because it sets up an active/passive master pair and wants to
> prevent accidental writes on the passive master.
> You can perfectly use an active-active dual-master setup, but your application must
> be built around it. Most applications aren't.
>> As has been said many times, master-master replication is not a
>> scaling solution.
> Depends. It can be a very useful scaling solution if it fits your environment.
> A very summary view of dual active master:
> * it is NOT a WRITE-scaling solution (both masters still must write all data), but it
> *is* a valid option in a read-heavy, low-write environment.
> * a minor problem for dual-active is clashing autoincrements on inserts - this is
> easily solved using offsetting.
> * the MAJOR problem, however, is that due to the asynchronous nature of replication,
> it is possible to have conflicting updates. There is no solution for this in the standard
> version of MySQL, although a number of vendors do have solutions.
> Imagine a dual-active scenario, with a client connected to each host. Client a
> updates record 123 on host A. At approximately the same moment, client b deletes that same
> record 123 on host B. Both statements succeed (asynchronous, remember) and then get sent
> to the other side. Host A receives a delete statement for record 123 and executes it
> normally. Host B, however, receives an update statement for record 123 and fails with a
> "no such record" error. Your databases are now inconsistent, and replication grinds to a
> THAT is the problem with writing to both masters at once.
> Bier met grenadyn
> Is als mosterd by den wyn
> Sy die't drinkt, is eene kwezel
> Hy die't drinkt, is ras een ezel
> MySQL Replication Mailing List
> For list archives: http://lists.mysql.com/replication
> To unsubscribe: http://lists.mysql.com/replication?unsub=1