Data changes too frequently to generate the file every x number of minutes across all smtp servers. The mysql db isn't a single server. It's a master (read/write) with multiple replicas for read access. Those replicas are load balanced with LVS (heartbeat/ldirectord/ipvsadm). The postfix(smtp) incoming and outgoing servers are also load balanced with LVS. So database read speed is not an issue. Believe me, we know how to build large high traffic sites, the only problem we're having is the exact syntax on using transport_maps or virtual_transport with multiple lmtp transports, and I think I got that figured out with the transport_maps. Will post more later. -matt On 10/23/07, mouss <mlist.only at free.fr> wrote: > Ross S. W. Walker wrote: > > mouss wrote: > >> mouss wrote: > >>> Matt Shields wrote: > >>>> I'm trying to set up a large scale email system that > >> supports 100,000+ > >>>> IMAP accounts. We have an existing frontend web interface > >> that does a > >>>> lookup on a mysql db to figure out which IMAP server to > >> connect to for > >>>> each user. For the email infrastructure we have decided on Postfix > >>>> and Cyrus. We have configured both to use mysql to get the virtual > >>>> user information. > >>>> > >>>> Because of the way that the infrastructure is (biz > >> reasons) we are not > >>>> doing shared storage, we have numerous IMAP servers that > >> we distribute > >>>> accounts across. As we add more users, we image up a new > >> IMAP server. > >>>> For our business's scaling purposes this was the best plan. > >>>> > >>>> What I am having a problem is how do I get postfix to transfer the > >>>> email to the particular IMAP server that the user account is on. I > >>>> know that I need to use lmtp and transport, but all the examples I > >>>> have seen show forwarding all email to 1 IMAP server. I would like > >>>> Postfix to do a lookup for each mailbox and determine which IMAP > >>>> server to deliver it to. > >>> There are primarily two ways: > >>> > >>> [virtual aliase] > >>> you can use virtual_alias_maps to redirect foo at example.com to > >>> foo at hostN.example.com, provided the final server accepts > >> such addresses. > >>> If the final server doesn't accept these, and you use smtp > >> to relay to, > >>> then you can write the addresses back, using smtp_generic_maps. > >>> > >>> [transport] > >>> an laternative is to use use (per-user) transport_maps. > >> something like > >>> foo at example.com relay:[hostN.example.com] > >>> > >>> > >>> In bothe approaches, the mappings can be generated using > >> sql statements > >>> (mostly CONCAT). something like > >>> ... > >>> query = SELECT concat('relay:[', host, '.example.com]') > >>> FROM User > >>> where '%u' = user and '%d' = domain > >>> > >>> you get the idea I hope. > > > > True, it may be better to just have a cron job dump out > > new static maps every 15 minutes or so then to have the > > MTA query on every delivery especially for 100K accounts. > > > > indeed. and if the table has a "status" field so that the script can > download only new or modified entries, then the dump can be made faster. > now, a trigger may even be better so that the dump script doesn't need > to query the full table, but only a small table of new/modified entries > generated by the trigger. > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >