redundant_sql Module

The redundant_sql module handles SQL expansions in a redundant manner.

This configuration can be thought of as a virtual module.

e.g. If you have two redundant SQL servers, and you want to use them in the authorize and accounting sections, you could place a redundant block in each section, containing the exact same text. Or, you could uncomment the following lines, and list redundant_sql in the authorize and accounting sections.

The virtual module defined here can also be used with dynamic expansions, under a few conditions:

The section is one of group, redundant, load-balance, or redundant-load-balance
The section contains module names ONLY, and no sub-sections
All modules in the section are using the same driver, e.g. They are all sql, or all ldap, etc.

When those conditions are satisfied, the server will automatically register a dynamic expansion, using the name of the virtual module. In the example below, it will be redundant_sql. You can then use this expansion just like any other:

&reply.Filter-Id := "%redundant_sql( ... )"

In this example, the expansion is done via module sql1, and if that expansion fails, using module sql2.

For best results, configure the pool subsection of the module so that retry_delay is non-zero. That will allow the redundant block to quickly ignore all "down" SQL databases. If instead we have retry_delay = 0, then every time the redundant block is used, the server will try to open a connection to every down database, causing problems.

Default Configuration

redundant redundant_sql {
	sql1
	sql2
}