Behavior of redundant/load-balance
Hi I hope someone will be able to clarify for me the behavior of the redundant/loadbalance grouping. In particular, when using the module redundant features (aka failover) what is the exact way freeradius will proceed? Let me clarify my question. If I have the following configuration (from the documentation): modules { sql sql1 { # configuration to connect to SQL database one } sql sql2 { # configuration to connect to SQL database two } always handled { rcode = handled } } # Handle accounting packets accounting { # always log to detail, stopping if it fails detail redundant { # try module sql1 sql1 # if that's down, try module sql2 sql2 # otherwise drop the request as # it's been "handled" by the "always" # module (see doc/rlm_always) handled } } If sql1 is down, freeradius will move to process the request with sql2, but what does the documentation mean with 'is down' : no connectivity to DB, slow request, ... ? Also once it detects that sql1is down, does it "mark" it as down and afterwards does not query anymore for X minutes? is there a charitable soul to clarify this ? Thanks, Seb.
Sébastien Barbereau wrote:
If sql1 is down, freeradius will move to process the request with sql2, but what does the documentation mean with 'is down' : no connectivity to DB, slow request, ... ?
See doc/configurable_failover. "redundant" means "go to next module on fail" For SQL, this means no DB connectivity.
Also once it detects that sql1is down, does it "mark" it as down and afterwards does not query anymore for X minutes?
It doesn't track that. Each packet is independent of the other packets. In version 3, the new "connection pool" code should be able to handle this. It's not all there yet, but a loss of DB connectivity means that the SQL module can quickly return "fail". Alan DeKok.
participants (2)
-
Alan DeKok -
Sébastien Barbereau