Mark Mackay - Orcon wrote on 2004-11-29 03:05:
So, instead of 2 DBMail boxes, I will have one Cyrus box (which the users
will connect to), and a DBMail box which will only be used for statistical
analysis and archive purposes. DBMail is perfectly
suited for that purpose; it saves me a lot of coding.
Unless you've got a particular need to run Cyrus, why not try the following:
I think I do, some are:
-- Server-side searches. Our people just love to do searches. Without
Cyrus (it was Courier before) life becomes miserable for them.
-- Single copy. Again, our people simply thrive on sending CC/BCC stuff
to 10 dozen people for every single mail. Again, without Cyrus,
we'd all be working for disk manufacturers.
1) use DBMail for your primary server which your users log into
I am not sure I can. We use SSO (single-sign-on) from Samba PDC so that
our gentile users will not need to remember lord knows how many pwds they'd
have to keep track of.. From the little documentation on Cyrus I have spent
a lot of time to get it going; I am not brave enough to venture into
a similar thing with DBMail as yet.
2) set up one-way replication from that database server to another box
Actually, Cyrus people have something called Cyrus Murder which does
(or is supposed to) do IMAP replication; if all else fails I might
have to plunge into using that with DBMail.
3) Direct all search queries/etc to your slave database, which means no load
is incurred on your primary box
This is the beauty of DBMail that has attracted me to it --an the reason
why I am pestering you guys in this list for a solution.
Until after Reiser4 becomes stable and the necessary plugins get written
for it, DBMail is the best toolI can dream of for the purpose I have in
mind.
We're just in the process of setting up something similar, where we scan
through customer mailboxes for say people over quota limit, or inactive
mailboxes, etc - and can't afford to have the load on the primary server.
Then when we find a message, mailbox, user, etc or whatever we want to
delete, we can direct the update query to the primary box. This moves all
the searching load to the slave, and only puts minor update queries to the
primary server.
The bummer at the moment, (according to list popular consensus a few months
back) is that you can't use either MySQL server as your 'primary' database,
as the replication is not real-time enough, so you may end up with
out-of-sync views of data. But treating the slave as read-only, should
negate/solve this.
Just as you suggested me to consider not using Cyrus, i will now
turn the table and suggest that you consider Cyrus for those purposes
(which do not strike me particularly in need of SQL backend).
As an example of how scalable and flexible Cyrus is I could point you
to fastmail.fm which offers IMAP as well as POP3.
[I use those guys for my own use --in order not to have a bus drivers
holiday in my own spare times :-) ]
Cheers,
Ray
