Re: sql-back+replication -- continued

[Leen Besselink <leen@wirehub.nl>]

> Quoting Leen Besselink (leen@wirehub.nl):
> > 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).
> 
> Why use two processes?  slapd has only incomplete knowledge about
> database changes, so you need replication out of the database; as the
> database knows about all changes, that mechanism is sufficient.
> 
Good question, i didn't think about that yet, maybe because I like really
simple solution that don't duplicate code. Thanks, your right, it's
better/easier to admin to have one process. I'll probably start with a
sql2replog.py and probably build from there.

> > For now I could probably 'slap' one together in Python, this is a fairly
> > simple and elegant solution.
> 
> Hmm, I'm using my own backend, so my comments don't apply to standard
> OpenLDAP, but the setup is roughly like what you are describing:
> 

Well, only real difference is that you share the the backend-code, but I
assume that it's very custom code.

[.. really nice ASCII-picture ..]
> 
> The major reason that standard slave servers think about the
> pseudo-master as the real master is that I like to have the option of
> turning on write-access on the Pseudo-master in case of a database
> failure, keeping the DB out of picture temporarily (and pushing the
> replication log into the DB later).
> 

Very inventive and maybe even a necassary evil, 'manual HA' probably
usefull for sheduled maintenance, etc. also.

I guess I would have one of the standard-slaves be the temporary master,
but this might be better idea, depending on the situation.

> The replication process and master backend share their database access
> code.
> 
> Insane?  Yes, the setup is insane.  I'd really prefer to get the
> legacy database out of the setup and use plain LDAP...
> 
thanx, for the ideas, I can probably use them.

_____________________________________
New things are always on the horizon.