Hi Jorg, I really appreciate your help sharing your experience/thoughts.
Yes, i fully concur with you, NFS is not designed for Databases. But you know there are Distributed SAN file systems (that use Direct IO to the SAN) are serving databases like DB2 in many installations for shared storage. NFS cannot match its performance...due to its added latency. But you know ORACLE has added a direct NFS support to its storage, that has no file system caching, and is far better than native NFS client driver. My goal here is to make NFS works much better, as a thin layer, optimized for Database IO by developing a new NFS stack in a clustered environment, as part of the clustering intelligence itself. If any one is aware of such efforts please share it with me ( That way we can avoid duplicate efforts and we can just complement what they are not doing ) Thanks On Fri, Aug 7, 2009 at 1:49 PM, Joerg Bruehe<joerg.bru...@sun.com> wrote: > 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 > > -- Best regards, Peter Chacko NetDiox computing systems, Network storage & OS training and research. Bangalore, India. www.netdiox.com 080 2664 0708 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
