Date: Mon, 25 Mar 2002 16:17:05 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Tim <tim@sleepy.wojomedia.com> Cc: chat@FreeBSD.ORG Subject: Re: qmail (Was: Maintaining Access Control Lists ) Message-ID: <3C9FBE01.DE7FFFB4@mindspring.com> References: <p05101505b8c430e28572@[10.0.1.9]> <000c01c1d3ab$6d2c6960$6600a8c0@penguin> <p05101509b8c47b17d088@[10.0.1.8]> <20020325015236.A97552@futuresouth.com> <p0510150eb8c48ba6b1f4@[10.0.1.8]> <3C9EFED0.DB176CB8@mindspring.com> <20020325115207.GA22032@sleepy.wojomedia.com> <3C9F1A16.207EA23E@mindspring.com> <20020325140022.GA23251@sleepy.wojomedia.com> <3C9FB0CB.C1C0CD89@mindspring.com> <20020325234504.GA31239@sleepy.wojomedia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tim wrote: > On Mon, Mar 25, 2002 at 03:20:43PM -0800, Terry Lambert wrote: > > > First, I am assuming that you serialize the administration > > > script (no parallel scripts going on). > > > > No. Database updates are atomic at the record level, and > > derived data is a snapshot of a collection of records. So > > the record is not there, it's there and it's old, or it's > > there and it's new. > > I understand that. What happens if: > > database -> ns1 > somebody mucks with the database (updates a serial # for zone for example) > database -> ns2 > > From your previous description, I had assume that it was important > for you to have consistency between ns1 and ns2 (and ns2 never has > newer information than ns1). No. If NS2 has a zone definition that NS1 doesn't have, it's a newly created zone, and there is a requirement for an update from NS1, since NS2 only knows about the existance in the zone. The serial number in both cases is generated data. In the initial create case in the secondary, it's "1". In the case of the primary, it's "generation number". After the transfer on the secondary, it's whatever was on the primary. It's not necessary to maintain teh consistency across the update window for newly created zones. Specifically, it's OK if the secondary contains an empty record that simply means that it is a secondary, and a zone transfer from the primary is needed. The issue is that there is an update window. If I miss the update window on the primary, I'm not going to be able to hit it again for the update interval on the primary anyway, at which time the data is re-derived (DNSUPDAT to the primary fixes that, actually, but I did not use it in the design cited). The failure is safe because of the automatic replication of data from the primary to the secondary. We can actually consider that the ordering of updates is only to ensure the availability of DNS records within some minimum time after instantiation in the database. In fact, we could really update in any order, and the only effect would be to widen the maximum update latency window X from X to (2X-1). This is an artifact of the forwarding of unknown requests to the primary when the secondary is listed as authroitative and has no record. > > This means that you can treat any record creation/update as > > if it happened either before or after the derivation, and > > the derived state is always consistent. > > > > If you couldn't do parallel updating, there'd really be no > > reason to use a database instead of a big honking file lock. > > I am talking about serializing updates of named.conf in ns1 and ns2. They are serialized by a timing window, but by nothing else. Due to the hierarchical relationships, all I need to do is delay the secondary updates by this window from the primary. The secondaries themselves can update concurrently. So for ns1, ns2,...nsN, the ns1 update has to occur first, but all other updates can occur concurrently (in fact, this is preferred). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C9FBE01.DE7FFFB4>