Re: back-config

["Pierangelo Masarati" <ando@sys-net.it>]

> 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
replication:

- master:
    - general:
        - slurp-argfile (should be per-replogfile)
        - slurp-pidfile (should be per-replogfile)
    - slurpd:
        - per-replog (global/database):
            - replogfile
            - slurp-argfile (todo)
            - slurp-pidfile (todo)
        - per-replica (database):
            - replica
    - syncrepl:
        - overlay syncprov
        - sessionlog

- slave:
    - general (per-shadowed context):
        - updateref
        - updatedn
    - slurpd:
        - none
    - 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:

"replica":
- uri (I'd drop the "host" option, since an hostport can always be written
as a URI)
- bindmethod
- binddn
- cred
- ...

"syncrepl":
- uri
- ...

"replog":
- replogfile
- slurp-argfile
- slurp-pidfile

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.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497