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

[Petr Spacek]

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?

-- 
Petr^2 Spacek