25 Čec
2017
25 Čec
'17
0:17
On 24/07/2017 10:43, Daniel Salzman wrote:
Hi Daniel,
Yes, LMDB itself is designed to be shareable between
different threads or processes,
but it has some performance penalty (serialized write operation). Knot DNS doesn't
expect there can be other unknown zones in the timer database. Such records are
purged during server reload. But I will remove this code as it is not consistent with
other databases and it will be possible to purge zone orphans via knotc zone-purge.
Okay got it.
But what is your motivation for two Knots on one
physical server? And why
to share storages if the zone lists are different?
We have Knot servers providing service for in-addr.arpa. The same
servers also service child zones such as 193.in-addr.arpa,
197.193.in-addr.arpa and 0.0.193.in-addr.arpa.
If this server receives a query for 1.0.0.193.in-addr.arpa/PTR, it will
reply with an answer from the 0.0.193.in-addr.arpa zone (closest match).
Protcol-wise, this is perfectly fine. A cache will be happy with this
response. However, casual observers querying the address of
in-addr-servers.arpa might be expecting a referral. Therefore we agreed
(together with the other operators of in-addr.arpa) that we would serve
it from a different view (BIND) or instance (Knot, NSD). So this is why
we run 2 instances of Knot on the same server.
Now, under Knot 2.3, it's fine for these 2 instances to share the
storage directory, because zones and journal files are written to
separate files. However, Knot 2.4 and above wants to keep data in a
database, and so I was wondering if it might be possible to share the
journal. This is especially important when upgrading from 2.3 to 2.4 and
above.
Your answer is clear. I will just go back and set a different storage
otion, pointing to different directories.
Regards,
Anand