Howard Chu wrote: > Nick Geron wrote: >> We're now thinking some of our issues may be attributable to time >> granularity issues. We're seeing missing information on the consumer if >> multiple successive writes are attempted via a script. If we slow down >> to human speed or insert sleeps in our test code, this gets a little >> better. I see that A.2.4 N-Way MultiMaster Replication notes that >> entryCSNs now record with microseconds, but does this apply to mirrors >> as well? > > CSNs were extended to microsecond resolution only for the benefit of > conflict resolution. For all other purposes, the changecount field > ensures sufficient granularity. In that case, why do we see any difference in propagation between scripted (quick) updates and hand/command line (slow) modifications? Or are you simply saying time is not the issue?
For example - manipulating one particular entry: 1) update server 1 adding 1 attribute = propagates to second server * wait a few seconds 2) update server 1 adding 4 attributes = first of four propagates to second server After waiting a second or so, another successful operation on the 'write' server will propagate all modifications over to the second server as expected. This behavior is why we suspected a time granularity issue. It should be noted that this doesn't work for us (and others as I would expect) as there is no guarantee that another operation on the 'write' server will occur, thereby propagating the current entry. > >> Can I setup a two node N-Way? > > "2" is certainly a valid value of "N". Well, there's that developer 'charm' I've been reading throughout years of archives. Since the admin doc make a distinction between the 'hybrid configuration' of MirrorMode and N-Way Multi-Master, I was more looking for clarification between the two implementations. Not a jackass comment. > Syncrepl doesn't write session logs. Read RFC4533. > I'll look into it. Thanks. Switching gears, what would the devs say is the capabilities in operations per second with 2.4.7? I'm seeing a number of aborts when testing under high load. The latest came from running scripted ldapsearches and ldapmodifies which resulted in a mutex error (or so I am told by one of our developers). Specifically: 1) adding about 100 attributes to an entry 2) diffing the output of ldapsearch between the two nodes in loop 3) once synced, grabbing the attributes, shoving them in a temp file with delete instructions and using that with ldapmodify. I complied with debugging on which results in an abort with "connection.c: 676: connection_state_closing: Assertion 'c_struct_state == 0x02' failed" logged. When tracing is employed (using strace) I have yet to see this behavior.
