On Mon, Sep 5, 2011 at 9:54 PM, Reindl Harald <h.rei...@thelounge.net> wrote:
> this is very bad, you should really take more care of what your setups > are looking like before going in production! Tell me about it. I ran our migration from mysql4 to mysql 5 (where we are now) 3 times with absolutely no fault what so ever. Our testing dbmail servers worked bang on with our testing mysql5 server. So for some dumb/stupid reason i never checked if the tables were in innodb format on the production run. My own stupid fault. :( > current dbmail-versions are relying heavy on innodb and > key-constraints for removing depending records in other tables. i wonder > that this works with MyISAM in any way Funny enough except for the issue with the dbmail-util cleanup command the whole thing works very well. Go figure. :) > as said in the previous reply you can try to dump/import without > the structures but personally i do not like really hughe sql-dumps > > personally i would setup a dbmail-instance in any virtalizing solution I have this all in a virtual environment with a drbd copy of the mysql data that i can snapshot, create new VM, test etc. So at least ive got that.... > * import the user/alias-tables Just checking here.. so that would be dbmail_aliases and dbmail_users right? > * change them to innodb Then get all the other tables setup correctly, but empty, then... > * transfer the messages via imapsync Is there any switches to note when using imapsync between two dbmail servers? > * stop live/vm server > * rsync of new mysql-datadir to the live-server > * start services/mysql on the liveserver All good with the last 3... BTW: Thank you for your replies. Simon _______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
