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