Sorry in advance if you see this reply twice. Already reply but cannot open
it so I repost.
Thank you Vincent for your prompt response.
Agree with you about the design and the architecture of the application but
cannot do anything about that. I was contacted two weeks ago for support.
About your questions :
1-Users register through the portal (a Self Service be like). During
registration, an entry is created in the Oracle Database with all id and
business info and an account is created in the directory server (only cn,
sn and password are valued for the account).
2-The directory severs are not really used in a load balanced configuration
(no load balancer, no DNS round robin either). the application is
configured with one server and if there is a issue with that server,
configuration is changed to point to the other replica.
3-Changelog of the two servers will be different (even we are in a
multi-master configuration, this is more like a master-slave because only
one server is used...) and to avoid loosing the changelog or the backup, I
was thinking why not store it to a remote location (here a share disk...).
the only changelog I can use to achieve if possible this "point-in-time
restore" is the changelog of the failed server that is only guaranted to be
safe in a remote location and not in local.
I have already took a look on the Redo Changelog (
but cannot figure out how to use this as a solution to this issue.
2014-09-30 11:03 GMT+02:00 Vincent Gerris <vgerris(a)gmail.com>:
Replication of accounts is always a challenge :).
What I have seen being used is the Retro changelog mechanism.
A script will poll for changes and keep track of what has been processed
and synced to the other side.
Where are the accounts originally created?
I get the idea the source is your Oracle Database?
I really hope you do not create accounts in both, that would make it very
complex and it should not be done from an architectural point of view.
Some remarks about your list:
- a multi master setup does use it's own storage, replication is done on
an LDAP level. Hence I do not understand the shared storage
Depending on which of the 2 masters is less likely to fail, you could
choose that one, or let the script talk to the cluster IP address if you
I would like to learn more about which part is master and how accounts are
created to be able to say if this is a good solution.
You could also use a bus construction if your are planning to do more
syncing in the future, like :
On Tue, Sep 30, 2014 at 10:36 AM, MND EXA <mndexa(a)gmail.com> wrote:
> Hi Experts,
> We are using 389 DS as authentication source for a web portal. Their is
> about 45 millions entries. The user data is distributed accros the
> Directory Server (just cn, sn and password are valued) and an Oracle
> Database (All identification and business related data). The challenge here
> is to keep consistent accros those two systems (a user having an entry in
> the database should have one in the Directory Server). This especially
> requires being able to perform a point-in-time restore of the Directory
> Server (No problem with the Oracle Database, we able to do that).
> Our environment is made of two Directory Servers in a multi-master
> I came up with waht I think can be a solution but something is telling me
> their should be a better way to do that. So here am to ask for advices from
> yours experts :
> Here what I think be a solution but not confident about that:
> -The backup files and changelog db are store in a share storage monted on
> the Directory Server
> -Every week, take a (full) backup of the server (using db2bak)
> -Whenever their is a issues:
> -Disable replication
> -Make a point-in-time recovery of my database
> -Create a script that dump the changelog db to an ldif file (using
> -Parse the ldif to obtain a compliant ldif file
> -Truncate the ldif file to juste keep the changes to be restored
> -Restore the two Directory Server using their corresponding (full)
> backups (the weekly ones)
> -Active replication
> -Replay the ldif computed from the changelog db using ldapmodify
> This seems daunting, cumbersome... So any advices ?
> Thank you in advance for your responses.
> Kind Regards,
> 389 users mailing list
389 users mailing list