Bokhan Artem wrote: > It's possible to balance users between masters, so one user will always > connect to the same DB (including lmtpd), except when it's BD becomes > failed. > I don't see problems in such case.
Look harder. > > Btw, does this break POP3? No, for pop3 it ok to do multi-master. >> This has been discussed many times to great length on the list and the >> wiki: >> >> message ids in a mailbox *must* be strictly incremental or else imap >> clients >> will fail to retrieve messages. >> >> > But it's possible to have holes, right? like 1,2,5,6,10,11 That is not a problem. >> such strict incremental sequences are not guaranteed in a master-master >> replication setup: a message inserted on hostB can very well have a >> message id >> that is lower than the highest message id on hostA. >> > As I understand, client just will not see new messages, which ids are > lower than the highest message id, until it reconnects? > Any other problems may occur? They won't even see them after reconnects. Imap clients receive a UIDNEXT reply when opening a mailbox which is essentially the highest UID in the mailbox+1. This is used by clients to keep track of which messages they have or have not seen before. So clientA connecting on mysqlA gets a UIDNEXT of say 1001 because the overall highest message_idnr in the dbmail_messages table is 1000 (just inserted on mysqlB). But the next message received on mysqlA is inserted as 999. Thunderbird, Outlook, and Mail will never see this message since they will happily send a 'X FETCH <UIDNEXT>:* (UID FLAGS ENVELOPE)' to get an update of new messages received their last update. Webmail clients like roundcube don't keep track of UIDNEXT but issue a 'X FETCH 1:* (ENVELOPE)' or 'X UID SEARCH 1:*' or something like that. So if your client doesnt do client-side caching you're (probably) home safe. If it does you're up shit creek. The only way around this is: - a DB cluster which implements two-phase commits - a homebrew two-phase commit system like the token-ring proposal on the wiki. Both will require some *serious* redesign of the database layer in dbmail. > >> It very much depends on the imap client being used. For some webmail >> clients it >> won't be a problem, but for outlook/thunderbird/osx-mail etc you are >> in for a >> world of hurt. >> > I tried to emulate this situation only with TB yet, and I didn't run in > any problem except I described. I hear you. But problems will surface when you put some serious pressure on the system. To put things into a more practical perspective: what kind of client load are you planning that would require a multi-master setup? Or is this just a theoretical excercise? -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
