Hi,
we're using a MySQL 5.1 Multi-Master setup as our DBMail back-end. Since there is no native support for read/write splitting (and mysql replication is asynchronous) we're always using only one database node directly, while the other is intended for fail-over. The MySQL server configurations include: # PRIMARY server-id = 1 auto_increment_increment = 10 auto_increment_offset = 1 replicate-same-server-id = 0 # SECONDARY (fail-over node) server-id = 2 auto_increment_increment = 10 auto_increment_offset = 2 replicate-same-server-id = 0 This way we get rid of collisions on auto-incrementing columns. If I recall correctly DBMail uses some auto-incrementing columns to identify new messages and announce them to IMAP clients in IDLE (and probably more)? So, let's suppose we have a sequential auto-incrementing column: 1 11 21 31 41 51 Now we fail-over to the secondary node and the column ends up non-sequential: 1 2 11 12 21 22 31 32 41 42 51 52 62 72 82 What exacly happens now? Which parts of DBMail will be mislead by this? In addition, I found an interesting old mail (Jun 2004): http://www.mail-archive.com/[email protected]/msg01706.html > The main problem is the requirement of the IMAP protocol to have a unique, > persistent, incrementing, 32 bit number for each message in each mailbox. > AFAIK, there's no guaranteed way of doing this in multimaster :-[ After reading this I'm pretty sure something won't work as expected after fail-over. Is this still the case? How do you guys handle this problem? Thanks, John _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
