On 01/10/2010 18:33, mailing@securitylabs.it wrote:
Il 01/10/2010 18:55, Ed W ha scritto:
On 01/10/2010 17:23, Timo Sirainen wrote:
I'm quite possibly missing the point, but you might restructure your application to have:
- one mysql db (replicated if necessary for robustness) with ALL customer data in it
- pool of postfix servers which auth to the remote db (they can be persuaded to cache auth results if you wish)
You are completely right, I simply don't like the idea to have one single big db with user data and all troubles that can happen (performance, replication configuration, data corruption...)
I think if you consider this for a bit longer you will see that you have near exactly the same issues in the way you have done things? eg if a node fails then you have lost a chunk of your data, hence backups need to be done for each machine (raising complexity), performance is limited per machine, you have no way to fail over to another db (say when doing upgrades)
If instead you start with a single aggregated DB then you have a single
master source to backup and protect. Then you can distribute that
master version as far and wide as you wish, eg if you want to you can
simply backup and restore it onto each server every hour if you want.
Or use one way replication to get it onto the slaves.. Or export it to
some flat file format and have postfix turn that into a map or whatever...
However, my personal favourite would just be a single master DB and appropriate secondary for resiliance. Lookups should likely be quite cheap compared with the load on your backend servers and a single DB server should likely handle a very large incoming mail load?
I think - for now - I will try authentication with multiple database with Dovecot, by now I only have 4 internal servers with MySQL, so performance I hope will not be a problem considering that Dovecot cache the results.
Whatever works, but it seems like you might want to take a step back and look at the complete system and check it's still sane? Seems like you are adding a chunk of complexity in order to have what you believe is a simpler system elsewhere? Why not draw out the complete system of interactions doing it with various permutations of master db, split master/slave, master with slave copy per server and master with exported maps, plus the current solution - see which one is really the simplest overall? My guess would be something like single master/slave turns out to be the winner?
Good luck!
Ed W