Question on sql.conf -> accounting_start_query <-> accounting_start_query_alt
Hello, to prevent duplicate entries in the radacct table, shouldn't the accounting_start_query be the "UPDATE" query and the accounting_start_query_alt be the "INSERT into" query as it is the case on stop and update. In which case would the accounting_start_query fail and the accounting_start_query_alt work? Could someone point me in the right direction? I know, that freeradius manages handled retransmitted Acct-Requests, so duplicate entries only would show up if at some point it wouldn't remember. I don't know if this is impossible. Thank you. Andreas
Hello, I thought a second time about it and i guess it is an performance related decision, because it is most likely that no entry exits.
/ to prevent duplicate entries in the radacct table, shouldn't the />/ accounting_start_query be the "UPDATE" query and the / How are you going to UPDATE an entry that doesn't exist?
Alan DeKok.
As I understand the behavior of rlm_sql the update of a non existing entry will fail and the alternate accounting_start_query_alt(with insert) will be transmitted to sql-server. This is the case if a Start Record is missing for an incomming Stop-record for instance. But as i said above the benefit of non duplicate entries vs. performance would not be worth it, right. So now for me remains in which case won't an Insert work but the alternate Update, or what for is accounting_start_query_alt. Another question a little bit of another topic. In may you wrote, that the functions of radsqlrelay will be an integral part of an next freeradius version. You talked about a few weeks here "radius server and sql server <http://lists.freeradius.org/pipermail/freeradius-users/2005-May/043936.html>". Ok it belongs to cvs head. Could you tell me the stand of development or where i can find the information? Sorry for my mistake on the meaning of "string" in RFC 2865 in articel "Difference between dictionary and RFC 2865 for Attribute Class <http://lists.freeradius.org/pipermail/freeradius-users/2005-July/045566.html>". It was related to the wish of informational use of the Class Attribute. Thank you Andreas Andreas Engler wrote:
Hello,
to prevent duplicate entries in the radacct table, shouldn't the accounting_start_query be the "UPDATE" query and the accounting_start_query_alt be the "INSERT into" query as it is the case on stop and update.
In which case would the accounting_start_query fail and the accounting_start_query_alt work?
Could someone point me in the right direction?
I know, that freeradius manages handled retransmitted Acct-Requests, so duplicate entries only would show up if at some point it wouldn't remember. I don't know if this is impossible.
Thank you.
Andreas
Andreas Engler wrote:
So now for me remains in which case won't an Insert work but the alternate Update, or what for is accounting_start_query_alt.
INSERT may fail if your SQL schema defines a unique index to prevent insertion of duplicate accounting records. With MySQL 4.1 you could use the ON DUPLICATE KEY UPDATE clause instead of an accounting_start_query_alt query. mysql> INSERT INTO radacct [...] ON DUPLICATE KEY UPDATE [...];
Another question a little bit of another topic. In may you wrote, that the functions of radsqlrelay will be an integral part of an next freeradius version. You talked about a few weeks here "radius server and sql server <http://lists.freeradius.org/pipermail/freeradius-users/2005-May/043936.html>". Ok it belongs to cvs head. Could you tell me the stand of development or where i can find the information?
You'll find manpages in the CVS head. Please read rlm_sql_log(5) and radsqlrelay(8). -- Nicolas Baradakis
Hello, i want to configure a mysql db failover. In my tests it seems that if the first mysql db is not reachable the first two authentication attempts are rejecting the user, because the rlm_sql module returns ok and no failover will happen. The module recognised that the db is not reachable but returns ok. On the thrid attempt the server switched to the redundant second db. Is this the deliberate behavior? Is there a way to switch direct to second db if the first db fails or are the two rejects mandantory before failover? Thank you Andreas Engler
participants (3)
-
Alan DeKok -
Andreas Engler -
Nicolas Baradakis