Thanks.
Meanwhile i've setup a master-master replication but i'm currently using
only one really as master.
That means i'm having the same databases on both servers, but i'm
sending statements only to server A, which then replicates them to server B.
I'm considering testing the mysql proxy which can do read/write splitting.
Mit freundlichen Grüßen / Kind regards
Christian Schramm
<http://www.cplinux.de>
FMGreen schrieb:
> Does 'run away' count as a recommendation? ;o)
>
> I have master<->master replication set up (it's for a load-balanced helpdesk
> system) and am currently trying to change back to master<->slave. When it
> worked it was fine, but when it broke it caused chaos. The reason is that
> when replication broke (due to a duplicate db entry) it took us two days to
> realise what was going on. Both dbs were acting as 'masters' and processing
> data individually so it wasn't immediately obvious there was a problem. We
> ended up with helpdesk tickets that had the same ticket number but different
> contents on each server. So when we decided to restore we had to pick one
> db and lose the data from the other. We're still having lots of problems.
> Unless you have a way of monitoring when replication goes down then
> master<->master has the potential a create a real mess. I'm very new to
> mysql but that's been my experience.
>
>
> Christian Schramm-5 wrote:
>
>> Hi @all,
>>
>> I've created a simple setup with 2 servers, each acting as master and as
>> slave.
>> So it does not matter on which server you will write.
>>
>> Of course you may get problems with duplicate entries and depending on
>> the server performance also a synchronisation lag.
>>
>> Does anyone in the list have experience with multi master setups like
>> this?
>> Any recommendations?
>>
>> I want to realize the current project i'm working on with replication
>> because the database is not optimized to run e.g. on a ndbcluster.
>> --
>> Mit freundlichen Grüßen / Kind regards
>> Christian Schramm
>> <http://www.cplinux.de>
>>
>>
>>
>
>

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.