RHEL5.5, MySQL GA 5.0.77, MySQL Cluster 7.1.4b, 64bit, SpamAssassin 3.2.5 (but hoping to go to 3.3.1 soon.)
In short, I stumbled across: http://www.clusterdb.com/mysql-cluster/how-can-a-database-be-in-memory-and-durable-at-the-same-time/ which essentially shows how to create a MySQL Cluster, but of only one node. This gets me an all-in-memory database *and* row-level locking. Sorta the best of both worlds, compared to using Heap/Memory vs InnoDB engine. Has anyone tried this, and did it work for you? There've been threads against using master/master replication or cluster, and a couple bugzilla entries specifically state cluster/replication is "unsafe". I think the main reason behind this is simply the duplication of data, and clear example was given in one bugzilla report. But if I do a single-node cluster (only one data/MySQL node), then there are no copies of data. Thus, it can't get out of sync, because there's nothing else to get out of sync with. Would this then be "safe"? Or is there something inherent in the clustering/replication that just doesn't work? Given this, I know there are folks using m/m-replication, and have seen reference to various threads. So far, I haven't see anyone post a glaring example about how it failed or anything, but I'm still a touch shy about going against the devs :) Thank you, PH PS I realize I can essentially get all in-memory for InnoDB w/a high-enough innodb_buffer_pool_size. But we keep hitting some wall after which performance just drops off a cliff. Haven't determined why yet, and while we investigate, was also thinking of other ways to implement the DB, rather than just constantly tweaking a couple variables and seeing what happens. It's not RAM (plenty) and it's not IO (which there shouldn't be much of anyway given the DB is all in RAM and there's nothing else running on this system.) It's just an odd mystery to me. == Paul Hirose pthir...@ucdavis.edu
