I always accepted that NFS was unacceptably slow for database access, until I actually tested it. Turns out that with lots of RAM and properly tuned caches, you're optimizing for minimal IO anyway. A good file server will have massive amounts of IO OPS. On top of that if you're using GigE over few hops, then it's really not slower than local disks.
Remember: benchmark and test your assumptions! Regards, Gavin Towey -----Original Message----- From: joerg.bru...@sun.com [mailto:joerg.bru...@sun.com] Sent: Friday, August 07, 2009 1:19 AM To: Peter Chacko Cc: mysql Subject: Re: Question about MySQL Hi Peter, all, let me just concentrate on the NFS aspect: Peter Chacko wrote: > [[...]] > > Another question is , whats the general experience of running MySQL > servers on NFS shares ? I would *never* use NFS storage for any DBMS (except for some testing): NFS access is slower than local disk access, and it adds more components to the critical path. So your operations get slower, reliability decreases, and (in case of any trouble) analysis becomes more difficult. I cannot imagine any setup where you have a machine strong enough to run your DBMS on it, but not capable of driving sufficient local disks. The typical argument for having centralized disks serving many machines is based on economies of scale (huge disks), flexibility (partitioning), and centralized management (RAID replacement, backup). There may be some merit to this in a specialized setup (NAS systems - I'm not convinced of them, but don't claim expert knowledge about them), but IMO not using general-purpose machines and NFS. Whatever the economical advantages during normal operation may be, you should not forget the huge costs you would incur if any in-between component breaks and your database stops operating. This may be tolerable for some applications, depending on the required availability, but simply intolerable for others. > We are working on developing a custom > protocol for MySQL clustering that takes care of all file management > as part of the database clustering protocol, rather than a storage > engine feature. Sorry, I don't get the meaning of this in sufficient detail to comment. > What are the likely setup of a database storage ? Is > it on RAW partition or on a File system ? That may depend on the storage engine used. MyISAM uses a file-per-table approach, so must be run on a file system; InnoDB may be able to use a raw partition (I'm not sure there); for others, I can't tell. > Will ocfs2 be better used > for mySQL as well, in a clustered environment ? I strongly doubt it. AIUI, the big advantage of cluster file systems is that they allow all machines to access and modify shared data. With a DBMS, you don't want to share data across machines, you want the database to be accessed only be the one machine (possibly multi-CPU, but shared memory) running the database processes, because on that machine you have the various database caches. Then, that machine makes the data available to all clients, so you get a logical sharing on a higher protocol level (SQL). To have multiple machines accessing the same database storage, you would first need some protocol to ensure cache coherency, and that is not contained in MySQL (in the general server). To use MySQL on multiple machines for the same data, you set up replication. The alternative approach would be to use MySQL Cluster, which is designed to hold the data in main memory (for extremely low latency) and to use the disk only for backup purposes. > > I would appreciate if any one share with me their thoughts on this. My comments above are based on my experience during DBMS development (including distributed DBMS), but not on any financial calculations or DBA work. Weigh them with other answers. Regards, Jörg -- Joerg Bruehe, MySQL Build Team, joerg.bru...@sun.com Sun Microsystems GmbH, Komturstraße 18a, D-12099 Berlin Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=gto...@ffn.com The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
