Well, journal is a complicated piece of stuff to handle. There are many
use-cases (from just IXFR to zone-in-journal) and situations (many small
zones, one big zone, some combination) which behave differently. There
are some more-or-less obvious technical limits. Many users have their
zones by magnitude smaller that their journal can handle; if it's not
your case, you need to think of how it shall behave once it's full, and
configure its tuning accordingly.
This is especially the case with `zonefile-flush: -1`, because journal
needs to save "whole history" of changes, not being able to simply
delete old stuff. It has mechanism to merge older changesets, where most
of the 'added records' and 'removed records' cancel out. I have observed
this works literally infinitely with `journal-content: all`.
You can also check the `kjournalprint` utility, which can tell you much
about what's inside the journal.
/Libor
Dne 29.10.18 v 16:39 Sebastian Wiesinger napsal(a):
* libor.peltan <libor.peltan(a)nic.cz> [2018-10-29
16:20]:
2) No, "discontinuity in changes
history" is not expected. Could you please
describe what did you do before such warning appeared, with longer snippets
of the log? In any case, there is no need to be scared of journal getting
full, once you read the documentation ;)
https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#journal-behaviour In
regards to the journal... well the site states:
"There is also a safety hard limit for overall journal database size,
but it’s strongly recommended to set the per-zone limits in a way to
prevent hitting this one. For LMDB, it’s hard to recover from the
database-full state. "
"Anyway, it’s recommended to carefully tune the journal-size-related
options to avoid surprises of journal getting full."
"Each zone journal has own usage limit on how much DB space it may
occupy. Before hitting the limit, changesets are stored one-by-one and
whole history is linear. While hitting the limit, the zone is flushed
into the zone file, and oldest changesets are deleted as needed to
free some space."
That doesn't sound like the journal can't get full. The only thing
that makes me a bit less anxious is this:
"If zone file flush is disabled, then instead of flushing the zone, the
journal tries to save space by merging older changesets into one. It
works well if the changes rewrite each other, e.g. periodically
changing few zone records, re-signing whole zone... The difference
between the zone file and the zone is thus preserved, even if journal
deletes some older changesets."
So when I have only DNSSEC stuff in the journal it will not grow
because changes are overwritten? Is that what it means?
Regards
Sebastian