#  -*- text -*-
#
#
#  $Id: ffce6bc83dbd9749fae6b65455db3555fbfde2ce $

#######################################################################
#
#  = redundant_sql Module
#
#  The `redundant_sql` module handles SQL expansions in a redundant
#  manner.
#
#
#  This configuration is a `virtual` module.
#
#  e.g. If you have two redundant SQL servers, and you want to use
#  them in the recv 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 recv 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.
#
redundant redundant_sql {
	sql1
	sql2
}
