... | ... | @@ -108,5 +108,12 @@ The trigger should be added on the `lease4_avail` table to delete entries as a r |
|
|
|
|
|
*IPv6 to be described*
|
|
|
|
|
|
## Considerations About Multiple Kea Instances
|
|
|
|
|
|
It appears to be a common use case to have multiple Kea servers connected to the same database. These servers share lease information in the `lease4` and `lease6` tables. The SQL trigger mechanism addresses the problem of consistency between the `leaseX` and `leaseX_avail` tables during normal operation. The aspect which requires some consideration is the servers' startup and reconfiguration phases.
|
|
|
|
|
|
Each server connected to the database is configured with a set of address pools. The servers may be configured with different address pools, the same address pools or overlapping address pools. The server connecting to the lease database is unaware whether any other server is connected to it and what pools it is configured to serve addresses from. The server connecting to the database is interested in "pre-allocating" the leases for the pools it is configured to serve, but it must not delete any existing entries in the `leaseX_avail` tables as they might have been inserted by another Kea instance according to its configuration. The server connecting to the database should traverse addresses in its own pools and create the corresponding entries in the `leaseX_avail` tables. If any of the entries already exist (because the pools of the two servers overlap), the server skips to the next address leaving this entry in place.
|
|
|
|
|
|
*Note: skipping the existing entry upon insert can be achieved by using ON CONFLICT/DO NOTHING construct in PostgreSQL.*
|
|
|
|
|
|
When the server terminates it must not delete any entries from the `leaseX_avail` tables because another server may be using them. The may obviously lead to a dirty database including extraneous data for the leases which belong to the address pools not configured on any server. If this is a concern, it is possible to introduce a configuration parameter which enables cleanup of the stale entries. The cleanup may only be enabled in deployments where a single server is connected to the database at a given time. |