[Date Prev][Date Next]
> I wonder if replication (syncrepl and slurpd) directives should be in
> their own objects, subordinate to the database object.
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
- slurp-argfile (should be per-replogfile)
- slurp-pidfile (should be per-replogfile)
- per-replog (global/database):
- slurp-argfile (todo)
- slurp-pidfile (todo)
- per-replica (database):
- overlay syncprov
- general (per-shadowed context):
- syncrepl (per shadowed context):
- syncrepl consumer directive
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 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; 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.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497