Hi Chuck,
I'm unaware of the culprit at the moment, but I would try:
- Increasing the zone file synchronization delay via
https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#zonefile-sync
- Changing the journal database mode to asynchronous via
https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#journal-db-mode
- Switching off the zone journal via
https://www.knot-dns.cz/docs/2.6/singlehtml/index.html#journal-content
Regards,
Daniel
On 2018-01-29 20:34, Chuck Musser wrote:
Hi,
After upgrading our fleet of slave servers from 2.5.4 to 2.6.4, I
noticed that, on a few slaves, a large zone that changes rapidly is
now consistently behind the master to a larger degree that we consider
normal. By "behind", I mean that the serial number reported by the
slave in the SOA record is less than reported the master server.
Normally we expect small differences between the serial on the master
and the slaves because our zones change rapidly. These differences are
often transient. However, after the upgrade, a subset of the slaves
(always
the same ones) have a much larger difference. Fortunately, the
difference
does not increase without bound.
The hosts in question seem powerful enough: one has 8 2gHz Xeons and
32G RAM, which is less powerful than some of the hosts that are
keeping up. It may be more a case of their connectivity. Two of the
affected slaves are in the same location.
For now, I've downgraded these slaves back to 2.5.4, and they are able
to keep up again.
Is there a change that would be an obvious culprit for this or is
something that we could tune? One final piece of information: We
always apply the change contained in the ecs-patch branch (which
returns ECS data if the client requests it). I don't know if the
effect of this processing is significant. We do need it as part of
some ongoing research we're conducting.
Chuck