howto decrease reload time on secondary?

[Jim Reid]

>>>>> ">" ==   <dns at roy.de> writes:

    >> What happens if a new reload is started and the reload befor
    >> isn't ready?

You pretty much start all over again because you've effectively
re-initialised your name server.

    >> How can i increase the simultan named-xfers?  (We tried in the
    >> named.conf ...
    >>	transfers-in 40;
    >>	transfers-per-ns 10;
    >>	max-transfer-time-in 60; ... 
    >> without success, to bring the reload time down)

The first two config file options will help increase the number of
simultaneous zone transfers. That however doesn't have much impact on
reload time. That tends to be a function of how many zone files and
SOA records have to be checked. And anyway it's not common to have to
transfer tens of zones at once after a reload. Reducing the time for
an inbound axfr is probably not a good idea either. If a zone transfer
takes longer than your self-imposed 60 second limit, there's probably
a very good reason for that like not enough bandwidth between the
servers or the zone is fairly big. If the zones are small and transfer
in a few seconds - the most likely scenario! - a 60 second limit could
well be pointless because the transfers are over almost as soon as
they've started. Remember too that the name server(s) that you're
transferring from may not be able to cope with lots of simultaneous
zone transfers: have you considered that possibility? ie The transfers
time out because the remote server is unable to handle the connections
quickly enough. Or there's a lossy network in between that's dropping
too many packets.

Have you experimented with the grep serial-queries option in BIND8? I
quote from the documentation (minus the HTML ugliness):

	Slave servers will periodically query master servers to find
	out if zone serial numbers have changed.  Each such query uses
	a minute amount of the slave server's network bandwidth, but
	more importantly each query uses a small amount of memory in the
	slave server while waiting for the master server to respond. The
	serial-queries option sets the maximum number of concurrent
	serial number queries allowed to be outstanding at any given
	time. The default is four (4).

	Note:
	If a server loads a large (tens or hundreds of thousands)
	number of slave zones, this limit should be raised to the high
	hundreds or low thousands -- otherwise the slave server may
	never actually become aware of zone changes in the master
	servers.  Beware, though, that setting this limit arbitrarily
	high can spend a considerable amount of your slave server's
	network, CPU, and memory resources.  As with all tunable
	limits, this one should be changed gently and monitored for
	its effects. 

    >> btw. SunOS 5.7, Bind 6.1.3

There is no BIND 6.1.3. Either you're mistaken or this must be some
Sun version identification string.

PS: I presume you've configured the slave server to keep file copies
of the slaved zones. This saves the unchanged zones from being
transferred each time you restart your server.