Anyone has experience with DLZ drivers?

[Adam Tkac]

Graeme Fowler napsal(a):
> Yes, I have some (although I've not used it in the last 15 months or
> so). I built an authoritative name server solution for a large UK based
> domain registration company using DLZ, and the DLZ part worked
> flawlessly.
>
> We went from a startup time of over 18 hours for each nameserver (on
> pretty fast hardware) to a startup time less than ten seconds. We used a
> MySQL backend (the only reason for this was that we had a number of
> experienced MySQL administrators) where each client-facing nameserver
> had its' own copy of a replicated master database; BIND never
> experienced memory problems, which it used to do with the old
> "monolithic" config file whereby the few clients we had using the system
> for recursion would cause the named process to chew up to 2 or 3GB of
> RAM (I forget which) at which point the kernel would kill the process,
> and we'd be back into 18-hour startup land.
>
> With hindsight, stopping recursion would have helped with that, but we
> were young and naive at the time :)
>
> As I recall, the cluster (it was load balanced) was serving somewhere in
> the region of 3-500 queries/second when I departed the company, and the
> frontend servers had almost no load.
>
> Of course, with a setup like this you have to take several issues into
> account:
>
> 1. Replication must be robust (yes, I know, MySQL...)
> 2. The DB server the DLZ zones load from must never lock - DB dumps must
> be taken elsewhere. We used an intermediary slave server off the master
> for this.
> 3. The master server must never, ever, drop the database (this is *much*
> easier to do than deleting zillions of zone files!).
> 4. Databases must be consistent on all client-facing servers.
> 5. Using MySQL's query cache reduces the load on the DB servers
> dramatically, especially if the zone data is relatively static.
>
> Much of this advice is the same as it is for servers using a per-zone
> config with "normal" zone files, but the semantics are different.
>
> Obviously, good DB design is important too - you're not dealing with
> zone files, so optimising the DB or the lookups you need to do helps
> with performance. It moves at this point from being a "classical"
> nameserver being managed by system admins with DNS experience to a
> well-optimised database run by a DB administrator with an application on
> top of it run by others (where both roles might be carried out by the
> same person/people, but still).
>
> Graeme

Thanks much for your reply

Adam