[bind10-dev] some other details about differences

[Likun Zhang]

Jinmei worte on Saturday, October 15, 2011 2:33 AM
> 
> 1. Housekeeping
> 
> For a longer term the diffs table will get larger and larger, and I
> guess we should eventually worry about its size.  In BIND 9 there's a
> configuration max-journal-size, and if it's set to a finite value
> named will keep the size of journal files so that the file size won't
> exceed the specified maximum.  In the approach of using a database
> table, we cannot use a "file size", so we probably use the max number
> of versions that can be stored.  We'll probably also need a separate
> housekeeping process (which maybe co-located on some existing b10-
> program) that manages the size of diffs for each zone.
> 

Vorner wrote on Saturday, October 15, 2011 4:17 AM
> Having the maximum number of revisions or maximum number of RRs in the DB
> seems reasonable. Also, as the RFC suggests, we don't need diffs older than
> which could be used. If the diffs would be longer than the zone, then there's no
> need to store them. We don't need that, but we have an upper limit on when
> they might still be useful. If the diffs table has more than twice as much records
> as the zone, then it's too large for sure.

For reference here. RFC1995 also pointed out, if the diff size is bigger than zone, the transfer should fall back to AXFR, so we have to compare the size of diff and zone when we considering the max diff size.


> 3. Propagation to in-memory data source
> One trivial way is to have the target process retrieve the diffs from
> the database and apply it to the in-memory image.  This may work, but
> I'm a bit worried about its performance implication if it's running
> with a high volume of updates (e.g. over several thousands of
> updates/sec).  We might want to use a direct channel between
> xfrin/DDNS process and the process managing the in-memory image, e.g.,
> via the command control channel.
> 
> Right now I'm not sure if this concern is real, and if so what's the
> best way to deal with that.

I'm not sure we should think too much about it. If there are several updates per second, all the dns queries should be served by the slaves, not by the master(If I am the smart administrator, :) )

> ---
> JINMEI, Tatuya
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev