Catching DB errors in sqlippool
Alan DeKok
aland at deployingradius.com
Mon Apr 9 16:34:57 CEST 2018
On Apr 9, 2018, at 10:02 AM, Бенджамин Томпсон <b.thompson at latera.ru> wrote:
> It was very easy to set up and I generated some load with radperf and did
> some testing and everything generally worked apart from a couple of
> problems.
That's good.
> The first problem I noticed is that when requsts are sent to multiple DB
> nodes at the same time,
That's a MySQL issue. FreeRADIUS issues one query to the DB. It's up to MySQL to distribute in the cluster.
> the DB sometimes throws a cluster conflict error.
> This error is picked up by the sqlippool module and this is how it looks in
> the logs:
>
> ERROR: (220) sqlippool: rlm_sql_mysql: ERROR 1213 (WSREP detected
> deadlock/conflict and aborted the transaction. Try restarting the
> transaction): 40001
Hmm... that's unfriendly.
> As there was a problem with the transaction I wanted to configure
> FreeRADIUS either to retry the request to the DB or to silently drop the
> packet. The problem is that the module returns the code ok:
Try upgrade to 3.0.16.
Hmm... I can't fix the database problem. But I will push a fix for 3.0.17 which makes the module return "fail" in this situation.
But the best fix is to use a database that works. Having a clustered database fail on simple transactions is... not smart.
Alan DeKok.
More information about the Freeradius-Users
mailing list