[Freeipa-devel] DNS SOA serial managed by 389 DS plugin: design

[Simo Sorce]

On Tue, 2013-02-12 at 10:57 +0100, Petr Spacek wrote:
> On 11.2.2013 17:23, Simo Sorce wrote:
> > On Mon, 2013-02-11 at 15:37 +0100, Petr Spacek wrote:
> >> Possible optimization
> >>
> >> Increment serial value at most once per second.
> >>
> >> Basic idea: Write current timestamp (no incrementation) and write
> >> serial value
> >> to the database with one second delay.
> >>
> >> Problem: How to solve LDAP server crash? Write timestamp immediately
> >> and
> >> (while reading) subtract 1 if timestamp == serial?
> >>
> > I am not sure I understand the solution here ?
> >
> > Maybe a simpler solution is to always write the serial as time() + 1 ?
> 
> I tried to solve following problem:
> (numbers represent time in "second.millisecond" format)
> 
> 1.000 : new_serial = time() + 1
> 1.100 : record test.example.com. updated
> 1.100 : zone serial overwritten with new_serial
> 1.500 : zone transfer started
> 1.500 : search result for all records and zone serial stored
> 1.500 : search result is transferred to slaves
> 1.700 : record test2.example.com. updated
> 1.700 : zone serial overwritten with new_serial
> <no changes from now>
> 
> Result:
> Zones on master and it's slave servers have serial = "new_serial" but the zone 
> content is different (records under test2.example.com. are not equal).
> 
> 
> 
> What I tried to describe above is that search for zone serial returns:
> if (serial value == time())
> 	return (serial value - 1)
> else
> 	return (serial value)
> 
> Example:
> 1.000 : new_serial = time()
> 1.100 : record test.example.com. updated
> 1.100 : zone serial overwritten with new_serial
> 1.500 : zone transfer started
> 1.500 : search result for all records and zone serial stored
> 1.500 : zone serial in search result is (new_serial - 1)
> 1.500 : snapshot is transferred to slaves
> 1.700 : record test2.example.com. updated
> 1.700 : zone serial overwritten with new_serial
> <no changes from now>
> 2.000 : now the search for serial value returns new_serial, i.e. slaves see 
> value incremented by one from last zone transfer (1.500)
> 9.000 : serial value is unchanged from last search
> 
> Expected result:
> Zone data can be inconsistent between master and slaves for only one second. 
> Data will be consistent if directory server crashed at 1.701 - new zone 
> transfer can be initiated after server restart.
> 
> Requirement:
> DS plugin have to modify serial value during reads. Does getimeofday() cost 
> too much to do it for all read-serial operations?
> 
> Makes it sense?

Thanks, makes a lot of sense.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York