Bind9 Log data consistency

Phil Mayers p.mayers at imperial.ac.uk
Tue Mar 8 22:35:24 UTC 2011


On 03/08/2011 09:46 PM, Stefan Certic wrote:
> Hi Sebastian,
>
>
> Thanks for response. Problem with another log file is that solution is
> doubling number of I/O transactions. At some point, data needs to be
> phrased into database and written to disk. I'm afraid doubling
> operations will cause bottlenecks during high load traffic peaks and
> slow-down maximal throughput.
>

AFAIK bind does not do transactional logging, and it doesn't do any mode 
of logging where it will stop answering queries if logging stops. 
Personally I consider this a good thing.

If I were you, I would log to files using standard bind "file" logging, 
and use an asynchronous, stateful "tail" of the logfiles to generate 
database records. Something like:

open logfile
begin loop
begin transaction
select lastposition from logfile_state for update
seek to lastposition
read X lines -> create SQL rows
update logfile_state set lastposition
commit
loop

Since you're storing both the query logs and the file position in the 
same SQL transaction, this should be pretty much bombproof. Obviously 
you'll need to handle filename changes/rotation but that's fairly 
trivial. I've used code like this before - it's handy because you can 
periodically rsync the files to do incremental "remote tail" (you need 
to code in support for partial lines in that case)

I really, really wouldn't stop answering queries if logging stops, but 
if you must - you could add a failure mode to the above process which 
terminates bind or blocks port 53.

HTH



More information about the bind-users mailing list