[RADIATOR] AuthBy SQL - Fail back to primary

[Jani Lahti]

Hello Robert

Radiator configuration offers no direct way to switch back to the primary
database, because all database connections are treated as equal. Below I'll
suggest some approaches so you can see if they fit your needs.

For situations when you detect that you're using secondary database and
want to change back to primary, and you know that there's some
database-specific SQL statement that you can use to disconnect the
connection(s). For example in DB2, there's a DISCONNECT statement.
https://www.ibm.com/docs/en/db2-as-a-service?topic=statements-disconnect .

Create a separate <Handler> that only catches some particular auth or acct
request (that you have a way to send when needed), and then in <AuthBy SQL>
use AuthSQLStatement or AcctSQLStatement to execute the SQL statement that
disconnects from the database. Radiator then starts a new connection when
needed, with the next available DB source. You need to use the same
connection details so that Radiator knows which connection you want to
disconnect.
https://files.radiatorsoftware.com/radiator/ref/AuthBySQL.html#AuthSQLStatement

If you want to use some other method to trigger the change, you can also
use some of the many Radiator's internal code hooks to disconnect the
database connection. For example if you use PostAuthSelectHook in <AuthBy
SQL> you can programmatically disconnect from the database after validating
that the incoming request had proper credentials.
https://files.radiatorsoftware.com/radiator/ref/AuthBySQL.html#PostAuthSelectHook

There are plenty of hooks to choose from. You can set Radiator to catch an
operating system signal using WINCHHook.
https://files.radiatorsoftware.com/radiator/ref/GlobalParameters.html#WINCHHook

If you want to initiate the db change with HTTP API call, set up
<ServerHTTP> and in its config block use PageNotFoundHook to create an API
endpoint. There's an example of using this method on the mailing list, too:
https://lists.open.com.au/pipermail/radiator/2025-May/022109.html
https://files.radiatorsoftware.com/radiator/ref/ServerHTTP.html#Trace_ServerHTTP-3

You can also use MainLoopHook to perform timed checks. In the hook code,
check which connection is in use (connected to secondary server) and if a
suitable alternative (the primary server no longer in FailureBackoffTime)
is available, then disconnect from the secondary in order to allow Radiator
to connect to the primary database.
https://files.radiatorsoftware.com/radiator/ref/GlobalParameters.html#MainLoopHook

Some useful code bits if you choose to use some Hook:
$self->{dbsource} is of form "dbi:SQLite:./radiator.db Connection id:
0-00000"

You can get a handle to an AuthBy using its Identifier string:
$authby = Radius::AuthGeneric::find($authby_identifier);
and get the $dbsource from there for your own checks (i.e. are we connected
to primary or not):
$dbsource = $authby->{dbsource};
If reconnection is wanted, just disconnect from the current dbsource:
$authby->disconnect();

Looping back to the start, you can naturally trigger a Hook with a RADIUS
request too, just set up a suitable Handler.

If you're using SessionDatabase, ClientListSQL or other SQL-related
features, you may want to disconnect and change those connections, too.

Using similar ideas, I've configured a setup that spans three data centers,
each with multiple servers. The Radiator servers primarily use databases
local to the DC, but they can fail over to DB backends in other DCs if
needed, and then switch back later.

//jani

On Sat, 14 Feb 2026 at 15:00, Robert Blayzor via radiator <
radiator at lists.open.com.au> wrote:

> In AuthBy SQL I can list multiple DB servers and they are tried in the
> order they appear.
>
> If one fails, it will move to the next in the list, but stays connected
> to that one until that connection fails.
>
> Is there a way to change this behavior to revert to the first in the
> list after FailureBackoffTime has expired and can be connected to again?
>
> In some cases we have a local DB server that may be unavailable from
> time to time, (upgrades, etc) but is the best primary source rather than
> the next one in the list.
>
> --
> inoc.net!rblayzor
> PGP:  https://pgp.inoc.net/rblayzor/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20260218/3a6d446e/attachment-0001.html>