Re: sql-back+replication -- continued

[Leen Besselink <leen@wirehub.nl>]

> Disclaimer: I'm just a webbuilder and fairly new to openldap and ldap,
> so I probably won't be able to implement some of the ideas below.

maybe not !

[..]
> 1. slapd keeps a replication log... and there are triggers/procedural
> language in the database that add any changes to that log..., but locking
[..]
> 
> 2. slapd doesn't keep a replicationlog-file, but triggers in the database
> write to a file in the format that slurpd understands. Triggers that write
[..]
> 
> 3. simplest way of doing replication is obviously letting the sql-backend
> do replication, between sql-backends, but it wouldn't be as fast, but
[..]
> but the best option is probably:
> 
> 4. the database (using triggers/procedural language) keeps a tabel with
> replication information, which is then read by a modified slurpd.
> 
> This seems a fairly simple solution, slurpd could even still use the same
> working methods, copy-data to file and start working, check input-source
> for news, sleep, etc.
> 
[..]

Adding an other process is also a way to solve it. You could have a
process (or even cronjob ?) that reads the database-tabel, like a slurpd
and creates/adds to a replication-log the same way that slapd creates
it. Everything else is the same (maybe create an extra slapd.conf-file
for the slurpd-processor to read it's settings from).

For now I could probably 'slap' one together in Python, this is a fairly
simple and elegant solution.

Also (if using PostgreSQL) it would be possible to have the python-module
be used directly from the database.

hmmm...