On 03/31/2014 10:47 PM, Simon Hobson wrote:
Nigel Kukard <[email protected]> wrote:

I'm just wondering if there's a race condition where multiple servers are 
updating the quota, and one update overrides another ?
I believe the updates are done  += and -= style with the delta, not updating 
the actual value with  value = x
ref: 
https://gitlab.devlabs.linuxassist.net/policyd/policyd/blob/master/cbp/modules/Quotas.pm#L269
Rules that one out then.

Hrmmm, were you using any sort of replication ... then again, even if you were the updates are still += , hrmm ... that and MySQL afaik uses statement replication, not row

What we'd need to do is do a query dump and see  whats going on.


I have a smaller 'cluster' of 3 machines which are all Xen PV guests, sharing a 
backend. I run one instance of PolicyD on the backend and originally had my 
Postfix instances accessing the single MySQL instance on the backend as well. 
it all worked perfectly under the loads I was able to impose as tests - then it 
all fell apart when I tried making it live.

Once under real tests, I found that MySQL lookups were failing and so there 
were random mail rejections - so I had to revert back to the old server. I've 
put slave MySQL instances on each host, but as yet haven't found the 
out-of-hours time (or TBH, inclination to do OOH work) to try making it live 
again.
Very odd indeed, I'm aware of some very large installations using combinations 
of mailservers with policyd on them and dedicated mysql servers. Do you perhaps 
have any logs with errors in them?
It was a while ago now, and other than Postfix logging whatever was appropriate 
(typically "user unknown" IIRC) there were no errors.


I think enabling the MySQL logging should help if the queries are failing ... also show full process list in MySQL may give some info how many connections you're dealing with, if there was very high concurrency you may of exceeded the number of allowed connections?

-N



_______________________________________________
Users mailing list
[email protected]
http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org

Reply via email to