Hi WIlhelm, I believe that this is unintentional. The library used by Kea for the database connection supports that syntax. Kea makes no checks of the host parameter. The parameter is passed to the library call as is. This isn't supported, however.
FYI, other users have made use of "haproxy" (https://www.haproxy.org/) to provide multiple database support. If this won't work for you, perhaps you could open an issue requesting multiple database server support be added here: https://gitlab.isc.org/isc-projects/kea/-/issues/ Thank you, Darren Ankney On Tue, Jun 10, 2025 at 11:01 AM Wilhelm Wijkander <li...@0x5e.se> wrote: > > Hey again Darren and sorry for a being a bit late in answering :) > > Den ons 4 juni 2025 kl 18:21 skrev Darren Ankney <darren.ank...@gmail.com>: > > Currently, Kea does not support multiple database servers directly. > > This article may be of some use: > > https://kb.isc.org/docs/experimenting-with-postgresql-high-availability > > That was a nice read - thanks! > > The text mentions that "if the current db01 failed, then the config > above could be changed to connect to db02". This manual config change > in the event of an outage is exactly what I'd like to avoid - instead > pointing Kea to a list of pgsql servers to try in order. > > And to an extent this is actually already possible like i mentioned, > although not documented in the ARM what I can see. Specifying two > pgsql servers separated by a comma in the hosts value in the dhcp4/6 > configuration will cause Kea to try connecting to the first one, and > if that fails move on to the next one. > > So far so good, but the issue is if you use streaming replication all > database servers except the current primary will be read-only. I > tested this by specifying two pgsql hosts as previously described, but > the first one set to read-only. With this setup Kea starts up and I > can do read-only operations, but when I for example try a > "reservation-add" command in the API I get a failure. It seems like > Kea does not check on startup that the database is actually > read-write(but the ARM claims that Kea will refuse to start in this > case, so maybe this is an error?). > > Setting target_session_attrs to "read-write" in the underlying call to > libpq should alleviate this, I think? I might attempt to address this, > if I get the time. > All of the above applies to version 2.7.9. > > Thanks for your time and help! > Wilhelm > -- > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. > > Kea-users mailing list > Kea-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/kea-users -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
