Bug 1975775

Summary: lmdb support is missing
Product: Red Hat Enterprise Linux 9 Reporter: Petr Menšík <pemensik>
Component: bindAssignee: Petr Menšík <pemensik>
Status: CLOSED CURRENTRELEASE QA Contact: Petr Sklenar <psklenar>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 9.0CC: aegorenk, psklenar
Target Milestone: betaKeywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: bind-9.16.20-2.el9 Doc Type: Enhancement
Doc Text:
Feature: Fast memory-mapped database support is enabled in BIND builds. It offers much faster additions and removals of zones added in runtime. Reason: Catalog Zone provides ability to setup secondary server hosting multiple zones, all of them configured by remote zone recipe received from another server. It then adds or removes served zones according to updates of the recipe zone. Result: A named server can add or remove high number of zones runtime without significant performance penalty.
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-12-07 21:33:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Petr Menšík 2021-06-24 11:35:28 UTC
Description of problem:
LMDB can be used by BIND to store efficiently dynamically added zones via rndc addzone. Even when it works even without it, it uses inefficient text file parsing. It is unsuitable for working with higher number of dynamic zones.

This is important part of Catalog Zones [1] feature support, which I think would be interesting for our customers. Fedora builds have it enabled already, I think RHEL9 builds should them enabled too.

Version-Release number of selected component (if applicable):
bind-9.16.15-2.el9

How reproducible:
always

Steps to Reproduce:
1. add allow-new-zones yes; to options
2. use rndc addzone
3.

Additional info:

Slight disadvantage is lmdb would be required also by unrelated tools package bind-utils, but a size of lmdb-libs is only 100kB.

Adds new tool named-nzd2nzf, which converts binary lmdb database to text representation used without this feature.

1. https://kb.isc.org/docs/aa-01401

Comment 1 Petr Menšík 2021-06-24 12:39:14 UTC
Needs just change in spec to start building with LMDB.

diff --git a/bind.spec b/bind.spec
index e7ee351..5a7742b 100644
--- a/bind.spec
+++ b/bind.spec
@@ -21,7 +21,7 @@
 # kyua no longer in buildroot in RHEL9
 %bcond_with    UNITTEST
 %bcond_without DNSTAP
-%bcond_with    LMDB
+%bcond_without LMDB
 %bcond_without DOC
 # Because of issues with PDF rebuild, include only HTML pages
 %bcond_with    DOCPDF

Comment 11 Petr Menšík 2021-08-25 20:02:53 UTC
Fixed in build bind-9.16.20-2.el9

Additional test might check whether named-checkconf on contents:

options {
  lmdb-mapsize 24M;
};

Reports warning. It would return still $? == 0, but would print warning on version with disabled LMDB. It should not print anything if LMDB feature is enabled.

After rndc-addzone-delzone test finished, version with support LMDB should contain in /var/named files *.nzd, database files converted from original /var/named/*.nzf plain configuration files.
New tool named-nzd2nzf can be used to display its contents readable to humans.

bz1315821-rndc-addzone-delzone test should pass with or without LMDB feature, but with LMDB updates should be faster and able to handle singnificantly more zones added in dynamic way. Presence of *.nzd files should be indication of working LMDB support.

Comment 22 Petr Menšík 2021-08-30 12:13:31 UTC
We have found during testing LMDB database does not immediately flush changed lmdb database to disk. After adding or deleting zone via rndc addzone or rndc delzone, results are not immediately visible on disk file named-nzd2nzf /var/named/_default.nzd. However, after proper shutdown of named those records are stored on permanent disk store.

It changed the behaviour compared to plain text configuration of nzf, where it always rewrote <viewname>.nzf file right away. According to LMDB API [1], it should use mdb_env_sync() call to request flushing configuration to disk. rndc sync would be good candidate to do it. No such call is present in BIND 9.16.20 at the moment.

1. http://www.lmdb.tech/doc/group__mdb.html

Comment 24 Petr Menšík 2021-09-02 12:05:42 UTC
(In reply to Petr Menšík from comment #22)
> We have found during testing LMDB database does not immediately flush
> changed lmdb database to disk. After adding or deleting zone via rndc
> addzone or rndc delzone, results are not immediately visible on disk file
> named-nzd2nzf /var/named/_default.nzd. However, after proper shutdown of
> named those records are stored on permanent disk store.
> 
> It changed the behaviour compared to plain text configuration of nzf, where
> it always rewrote <viewname>.nzf file right away. According to LMDB API [1],
> it should use mdb_env_sync() call to request flushing configuration to disk.
> rndc sync would be good candidate to do it. No such call is present in BIND
> 9.16.20 at the moment.
> 
> 1. http://www.lmdb.tech/doc/group__mdb.html

Later testing contradicts those results and current tests do pass with checking of nzd database right after zone modification. I were unable to find why results are different now and what is the difference between previous testing results. Yet it is reliable and behaves the same even after retries.