MySQL Forums
Forum List  »  Replication

Posted by: rotis 23
Date: April 07, 2009 05:04AM

Hi All,

We have a Java web app on a collection of load balanced web servers with reasonably heavy writes that will talk to dedicated database servers using MySQL 5.1 and InnoDB engine. Each customer will have it's own logical database (I know this is not the best design decision but clients were unmovable on this for data protection/privacy reasons).

Our idea is to use the 2 database servers as failover to each other and to share the logical databases for load purposes. This introduces some interesting questions about how to configure the servers as master for some and slave for other logical databases.

We have a good quality fibre connected SAN (HP EVA series) already available. So, a couple questions:

1) What is the best method of using replication for failover in this instance? I'm assuming the SAN doesn't give us much here due to the risk of data corruptionpost failure. Does anyone have any idea/experience of the reliability of SANs and InnoDB engines after a failure? Can we just store the binary log on a different SAN partition/LUN without explicitly using a slave?

2) Does anyone have any experience of the snapshot functionality that this type of SAN provides? Can this be used for periodic (every hour?) backups? I understand it can lock the filesystem - is that safe/feasible for InnoDB? I think that we will replicate to an off-site backup server using master-slave replication anyway.

3) Should we just forget about the SAN and use MySQL Cluster or DRBD?

Thanks for any pointers on this - we going to do some testing on this but just wondered if anyone has any recommendations with this setup.


Options: ReplyQuote

Written By
April 07, 2009 05:04AM
April 08, 2009 06:17AM
April 08, 2009 09:04AM
April 08, 2009 11:11PM
April 09, 2009 02:28AM

Sorry, you can't reply to this topic. It has been closed.

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.