Thursday, March 22, 2018

[389-users] replication question

Hello,

      I am trying to replicate my userRoot database to another 389LDAP server (supplier: 389ds1, consumer: 389ds2). The database on the supplier has not been replicated to any server for more than 2 years. (yikes!!!). 

I have been successful in backing up the database in question, and am now trying to create a replica agreement. I created the root suffix on the consumer side (389ds2) and then created a replication agreement from the admin console. The admin console has been in the state of wait while consumer is initialized. 


Here is the output from the repl-monitor script

Enter password for (:): Master: 389ds1.northshore.edu:389 ldap://389ds1.northshore.edu:389/
Replica ID: 1212
Replica Root: dc=northshore,dc=edu
Max CSN: 5ab3dd8f000004bc0000 (03/22/2018 12:45:03)
Use of uninitialized value in string at /usr/bin/repl-monitor.pl line 814, <> line 1.
Use of uninitialized value in join or string at /usr/bin/repl-monitor.pl line 1151, <> line 1.
Type: consumer
Time Lag: - ?:??:??
Max CSN: none
Use of uninitialized value in concatenation (.) or string at /usr/bin/repl-monitor.pl line 855, <> line 1.
Last Modify Time:
Sent/Skipped: 0 / 0
Update Status: 0 Replica acquired successfully: Incremental update started
Update Started: 03/22/2018 12:45:01
Update Ended: 03/22/2018 12:45:01
Schedule: always in sync
SSL: n
Replica ID: 1971
Replica Root: o=netscaperoot
Max CSN: 5ab1364d000407b30000 (03/20/2018 12:26:53 4 0)
Type: consumer
Time Lag: 0:00:00
Max CSN: 5ab1364d000407b30000 (03/20/2018 12:26:53 4 0)
Last Modify Time: 3/20/2018 12:26:52
Sent/Skipped: 0 / 0
Update Status: 0 Replica acquired successfully: Incremental update succeeded
Update Started: 03/20/2018 13:58:15
Update Ended: 03/20/2018 13:58:15
Schedule: always in sync
SSL: n


My question is... is this hung or is the replication initialization going to take days because of how long it has been since it has replicated the database?
--


Thanks,

Jesse


No comments:

Post a Comment