Furthermore, the thing that happened last afternoon was that reading from the master 1 was
becoming impossible - VERY slow - and both master 1 and master 2 has errors on the slave
status (duplicate)
Could this be the reason for all the failure in reading from the Master 1?
I stopped both slaves and a few minutes after it was allowing reada again.
Was this a coincidence? I mean, errors regarding replication stop the rep. but shouldn't
stop reada from altogether
Ricardo
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
> them.
>
>> 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
> halt.
>
> 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
>
