I am experimenting with mysql replication, and have done some research
on key collisions in the case of a 'load balancing' situation (live sql
servers running on each amavisd server), using either same mx weight, or
VRRP/CARP, heartbeat, virtual ip type setups. 'random' smtp connections
could hit
Michael Scheidell wrote:
> I am experimenting with mysql replication, and have done some research
> on key collisions in the case of a 'load balancing' situation (live sql
> servers running on each amavisd server), using either same mx weight, or
> VRRP/CARP, heartbeat, virtual ip type setups. 'ra
At 06:14 10-10-2006, Michael Scheidell wrote:
I am experimenting with mysql replication, and have done some research
on key collisions in the case of a 'load balancing' situation (live sql
[snip]
My concern is over use of SERIAL keys in amavisd-new tables, vs
AUTO_INCREMENT keys.
(are SERIAL
>
> ...omissis...
>
> it did does for, say, one year. It may have reached a very high
Of course, "high" is instead "low"...
> totscore and count. Well, now suppose your reliable source
> started sending a lot of spam. Would you like to have to wait a
> month or so before its whitelistening sc
> Another issue may be AWL files, (I suppose a spamassassin question
> also?). Every 'new' ip/email incoming will create a new PRIMARY KEY
> (username,email,ip). If two connections, one on each box, first one
> wins, replication stops and you need to manually issue a bunch of
> commands to skip
> -Original Message-
> From: Giampaolo Tomassoni [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 10, 2006 3:25 PM
> To: Michael Scheidell; SpamAssassin Users List
> Subject: R: Auto_increment vs SERIAL key types
>
> Of course, the underlying sql engine has to sup
> -Original Message-
> From: SM [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 10, 2006 2:08 PM
> To: SpamAssassin Users List
> Subject: Re: Auto_increment vs SERIAL key types
>
>
> At 06:14 10-10-2006, Michael Scheidell wrote:
> >I am experimenting wi
> > Of course, the underlying sql engine has to support views
> (5.0, but I use 4.1)
> > and, most important, updates to a view. Maybe I'm wrong, but
> > this is something that mysql doesn't do. Besides, that's one
> > of the reasons for which I prefer much more postgresql.
> >
> But postgresql
