[Date Prev][Date Next]
Overall this makes sense to me. Then instead of pointing slurpd at a
config file, one would invoke it with an LDAPuri like
I note that our back-ldif implementation (which still needs to be
submitted to ITS) stores one entry per filesystem file, so one might
Pierangelo Masarati wrote:
I think replication in general might need some reordering; asn long as we
intend to keep slurpd around, we need to identify what's key to
Yes, I've pretty much done that - a "host" option on input is emitted as
So, I think it would be good to have a separate entry for: "replica",
"syncrepl", "replog", each containing the appropriate data as attributes:
- uri (I'd drop the "host" option, since an hostport can always be written
as a URI)
The syncprov overlay object already appears as a child of the database,
that doesn't seem to need any changing.
The presence of a (unique) "shadow" entry as child of a database could
indicate it's shadowed; if the type is "syncrepl", it means it's a
syncrepl consumer, otherwise only the "updateref" and "updatedn" fields
should be allowed.
The presence of a (unique) "syncprov" entry a child of a database could
indicate it's a syncrepl producer;
Except this doesn't reflect the current implementation, where a single
replog object (the global one) would logically be the parent of many
per-database replica objects. That disconnect needs to be addressed.
the presence of a (unique) "replog"
entry as child of a database could indicate it's a slurpd master; the
presence of (multiple) "replica" entries as children of the "replog" entry
would store each replica's data.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support