I'm interested in how this goes. Galera didn't seem very mature when I installed this cluster but it definitely looks like something I'd try now. MySQL cluster can be a pain to setup but I've had (touch wood!) zero issues since going live.
Cheers Sent from my iPhone On 12 Dec 2011, at 17:11, "[email protected]" <[email protected]> wrote: > Ian, > >> From the responses it appears that this is exactly how policyd works. As > for the database we are planning on using a mysql replication software > called Galera (http://codership.com), which provides synchronous > multimaster replication, and is vastly simpler to manage than MySQL > Cluster. It even allows you to separate your database servers across data > centers (ours are about 100 miles apart), which we have tested > successfully. > > Thanks. > > On Mon, 12 Dec 2011 16:45:49 +0000, Ian Mordey <[email protected]> > wrote: >> I'm running option 2). 2 active/active load balanced postfix servers > with >> a seperate policyd on each. The backend is a load balanced MySQL cluster >> with 2 active/passive mysql nodes and 2 active/active data nodes. I've > not >> seen any performance issues at all and we deliver approx. 150K messages > a >> day across the two servers. >> >> If you need any more info on our setup feel free to ask. >> >> Thanks >> Ian >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Simon Hobson >> Sent: 12 December 2011 16:14 >> To: [email protected] >> Subject: Re: [policyd-users] Multiple servers >> >> [email protected] wrote: >>> We are looking at setting up a cluster of outbound mail servers using >>> policyd, and I was wondering what the configuration of the mysql >>> database would look like. Is the database supposed to be independent >>> for each node that is serving mail, or is it possible to have all of >>> the mail servers pointed to the same database, sharing the cumulative >>> logging for policies? >>> The only policy we plan on implementing is a limit on how many messages >>> a SASL user can send per hour. >> >> You have a number of options. You don't really want a separate database >> per node as you'll just end up with out of sync data and a general >> nightmare. >> >> So your options are (AFAIK) : >> >> 1) Run one policy server (and backing database) and call if from each > mail >> server. This is what I've done for a small cluster - and the shared DB > is >> also used with Postfix Admin. This is what I'd suggest as the load is >> actually fairly low, even for a busy server. >> >> 2) Run a shared backend database, but a separate policy server on each >> mail server. >> >> 3) Run a separate policy server on each mail machine, AND a separate >> database (replicated) for each server. >> >> TBH, I can't see any point in 3 - just a complication too far. Option >> 2 may have some merit, but probably limited performance advantage. >> >> Of course, if you want resilience then you could run a replicated pair > of >> backend databases, with a policy server each, and split your mail > servers >> between the policy servers. Or various other permutations. >> >> >> FWIW, when I was having some performance issues (eventually tracked down >> to a bug in the version of <something> I was running, I found that my >> limiting factor was Postfix - it seems to be limited to about >> 2 queries/s to the policy server from each thread. I did some tests and >> found I could easily load up the single policy server with multiple > streams >> of queries and it would chew through them at something like (IIRC) 60/s >> even on my fairly low spec machine running multiple guests under Xen. >> >> -- >> Simon Hobson >> >> Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed >> author Gladys Hobson. Novels - poetry - short stories - ideal as > Christmas >> stocking fillers. Some available as e-books. >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.policyd.org/mailman/listinfo/users >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.policyd.org/mailman/listinfo/users > > _______________________________________________ > Users mailing list > [email protected] > http://lists.policyd.org/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users
