Just a few thoughts and a somewhat different perspective.....
Running DBMail's RDBMS away from the DBMail daemons seems like the norm and
not an oddity doesn't it? I prefer to see some little 1Us handling service
delivery traffic with one or two CPUs and the big iron doing the RDBMS and
file storage behind some isolating appliances (what RDBMS is really
NFS-safe?). That means the RDBMS is "remote"--in the context of this
thread--from all the DBMail/MTA daemons.
In any case at least one of MX1, MX2, MX3... etc. would be off the RDBMS
host in terms of injecting into the RDBMS and when running large database
clusters you are going to connect via TCP in totality I would think. The
same is roughly true for fetching from the database with your POP and IMAP
depending on how you have your users split up.
Most email users will be connecting across the internet at around 1-5mbits
per second. Your local network must have data at the bridge to the WAN at a
speed equal to or greater than the user's upstream data flow rate. If the
LAN is running at 100mbs you have capability of 20 to 100 1-5mbit
connections per second per interface. In other words there is a very low
probability the latency in the system between the DBMail daemon 's WAN
facing interface and the LAN-side RDBMS will impact Internet mail users
significantly on the average system. At some point you may need to add many
more front-ends and split up the users the way ISPs do when user numbers get
into the hundreds of thousands. Trust me when I say the IMAP/POP daemons are
not running on the storage hosts and that all connections are TCP.
Gig LAN is a good upgrade and so too is 64-bit hardware for the RDBMS but
unless you are fully wired with Cat6 its a no-go. With good switches and Cat
6 (or at very least Cat5E) GIG LAN will give you a huge increase in
throughput for moving large files like db backups dumps and the like as well
as regular traffic. If you have some LAN fibre to light up then that's a
whole other thing.
regards,
Fred
----- Original Message -----
From: "Jorge Bastos" <[EMAIL PROTECTED]>
To: "DBMail mailinglist" <[email protected]>
Sent: Friday, June 16, 2006 3:55 AM
Subject: Re: [Dbmail] local v. remote
A remote MySQL server (on the same internal network) could be a problem
when the database became with 2/3 or more GB's (or maybe not) in a 100Mbps
wire, and worst, if users deal with large emails, like bit attach's etc
etc, all toghther at the same time may slow down the server response.
My Opinion of course :P
Jorge
----- Original Message -----
From: "DK" <[EMAIL PROTECTED]>
To: "DBMail mailinglist" <[email protected]>
Sent: Friday, June 16, 2006 4:57 AM
Subject: Re: [Dbmail] local v. remote
Why don't you run it local and install a remote copy of the db?
Consider this: I had run dbmail with only a few users and a few days,
the db size is already 75MB
Demi
On 6/15/06, jurgen <[EMAIL PROTECTED]> wrote:
>From what I understand, there's no problem with running a remote MySQL
server. You just need to be careful with permissions, make sure that
the dbmail user has the proper rights and privileges to access the
server. Also, there's *lots* of database activity involved, so make
sure the MySQL server isn't *that* remote.
....jurgen
On 16/06/06, Matthew Story <[EMAIL PROTECTED]> wrote:
> I"m trying to run with a remote MySQL server, does this require any
> different writing of transports and such in Exim4 in terms of local v.
> remote delivery? I only ask because all the howtos and install
> documentation assume that you're running the mysql server on the same
> box as the Exim4 server.
> --
> regards,
> matt
> _______________________________________________
> Dbmail mailing list
> [email protected]
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>
--
[EMAIL PROTECTED] is jurgen's gmail address.
Visit http://jurgen.ca/ for more yummy goodness.
_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
