>> 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? > > and if you have a 3.5GB bayes database, don't you need 3.5GB ram?
Yep, and we're running on 8GB systems, and have innodb_buffer_pool_size set upwards of 4GB (or max_heap_table_size the same, if we're trying this in Memory/Heap engine instead.) > where is that bugzilla report? I might have a solution for it. https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5998 > > 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 :) > > biggest issues seem to be, you need a 5.1.47 or newer mysql, and I think you > want to use the plugin (i think). > still get deadlocks while multi threads are trying to update the bayes DB. > but if you 'swatch' it, maybe you just retry? > or, heck, its just bayes, who care? the spammers will hit you again (and if > you got the deadlock, they did) Hmm, I'm still on 5.0.77 (the basic RHEL5 repository version.) Do you know which plugin? I'm just using BayesStore::MySQL if that's what you mean. If there's something else, I'd appreciate any tips. All in all, the anecdotal gist of random searches seems to be that m/m-replication basically works, and if it really does blow up, emptying and starting it clean is perfectly fine. There's a tangential bug #4508 which sends writes to one host and reads to another (presumably for master/slave setups) which I look forward to in a future version of SA as well. For us, this really all started because of some performance drop-off at crossing a certain load threshold. Don't know why yet :( and we're looking into that too. This alternative just kinda crossed our radar during our investigations into our InnoDB/Memory set up failing on us. PH == Paul Hirose pthir...@ucdavis.edu
