Thanks everyone for your time and kind attention.
I've got to agree with Marcus here, two masters won't bring us that much benefit in fact,
they would problably cause us more harm than good.
Regarding the scaling situation, bear in mind that I don't need any more databases not now
and not on the future, this is trully a fail proof (or at best fail avoid) system I'm
trying to implement.
The master-slave system seemed right for the job hence my question regarding performance.
I know the slave is the one that really does all the work but at some point (namelly
every request) the master must write info into the binlog..but you guys already said
thats close to 0 cost performance wise so thanks for that!
I used to have the write on master - read from slave system before but for now I'm more
preocupied in having two databases with same information than anything else!
If one database crash, I need to quickly change the ip on the web server and things
continue to work as planned:)
Thanks a lot guys!!!
On 21 Sep 2011, at 19:57, Marcus Bointon <marcus@stripped> wrote:
> On 21 Sep 2011, at 20:39, Wagner Bianchi wrote:
>> A good solution could be to use a MASTER <=> MASTER topology, using MySQL
>> 5.1 or 5.5, in order to split writes between servers, operation will
>> decrease a little more your workload.
> I really wouldn't do that. Writing to both masters will not gain you any performance
> and asks for all kinds of split-brain trouble. I've been there, it's not pretty. If you
> manage your masters with MMM, you won't be able to do it anyway as it sets passive masters
> to read-only.
> It's been said many times - MySQL replication is NOT a scaling solution. MySQL
> Cluster and sharding are scaling solutions, but they are unrelated to replication.
> Marcus Bointon
> Synchromedia Limited: Creators of http://www.smartmessages.net/
> UK resellers of info@hand CRM solutions
> marcus@stripped | http://www.synchromedia.co.uk/