2020-08-18 11:28:26 -04:00
|
|
|
.. _database-connectivity:
|
|
|
|
|
|
|
|
|
|
*********************
|
|
|
|
|
Database Connectivity
|
|
|
|
|
*********************
|
|
|
|
|
Kea servers (kea-dhcp4 and kea-dhcp6) can be configured to use a variety of
|
2020-11-14 00:00:37 +00:00
|
|
|
database backends for leases, hosts, and configuration. All of them may be
|
2020-08-18 11:28:26 -04:00
|
|
|
configured to support automatic recovery when connectivity is lost (see
|
|
|
|
|
``max-reconnect-tries`` and ``reconnect-wait-time``).
|
|
|
|
|
|
2020-08-18 12:02:08 -04:00
|
|
|
It is important to understand how and when automatic recovery comes into play.
|
2020-11-14 00:00:37 +00:00
|
|
|
Automatic recovery, when configured, only operates after a successful startup
|
|
|
|
|
or reconfiguration during which connectivity to all backends has been
|
2020-08-18 11:28:26 -04:00
|
|
|
successfully established.
|
|
|
|
|
|
2020-11-14 00:00:37 +00:00
|
|
|
During server startup, the inability to connect to any of the configured
|
|
|
|
|
backends is always considered fatal. A fatal error is logged and the server
|
|
|
|
|
exits, based on the idea that the configuration should be valid
|
|
|
|
|
at startup. Exiting to the operating system allows nanny scripts to detect
|
2020-08-18 12:02:08 -04:00
|
|
|
the problem.
|
2020-08-18 11:28:26 -04:00
|
|
|
|
2020-11-14 00:00:37 +00:00
|
|
|
During dynamic reconfiguration, all backends are disconnected and then
|
|
|
|
|
reconnected using the new configuration. If connectivity to any of the
|
|
|
|
|
backends cannot be established, the server logs a fatal error but remains
|
|
|
|
|
up. It is able to process commands but does not serve clients. This
|
2020-08-18 11:28:26 -04:00
|
|
|
allows the configuration to be corrected via command, if required.
|
|
|
|
|
|
2020-11-14 00:00:37 +00:00
|
|
|
During normal operations, if connectivity to any of the backends is lost and
|
2020-12-09 19:09:25 +02:00
|
|
|
automatic recovery for that backend is enabled, the server disconnects from the
|
|
|
|
|
respective backend and then attempts to reconnect. During the recovery process,
|
|
|
|
|
the server ceases to serve clients but continues to respond to commands. If
|
|
|
|
|
connectivity to all backends is restored, the server returns to normal
|
|
|
|
|
operations. If connectivity cannot be restored after ``max-reconnect-tries``,
|
|
|
|
|
the server issues a fatal error and exits.
|
