Administration databases replica IDs not in synch

I have domain containing 10 servers. DDM was alerting me to some errors and in investigating these I have noticed that several administration databases have different replica IDs on different servers.

I have read several articles that discuss the similarities between the replica ID’s of the domino directory and other databases (admin4.nsf, events4.nsf, ddm.nsf, catalog.nsf, activity.nsf and statrep.nsf) as per the link below

http://www-1.ibm.com/support/docview.wss?uid=swg21099635

Everything appears to be functioning correctly however I would like to get everything running by the book with the replica ID’s all linked as per the above article. I have tried to recreate DDM.nsf on server10 by stoping events.nsf, dbcacheflush and deleting the DB, load event and the db is recreated (stopping the server wasn’t an option at the time). The database was created with exactly the same replica ID as the deleted file.

I have not tried to force replicas to be created by bringing down the server and copying the files as I am trying to avoid having to manually update all the replication formulas etc that go along with these databases.

Of note is that the organisation has gone through mergers and de-mergers in the past and little documentation is available about exactly what was done.

Now for the questions……

  1. Does anyone know exactly where/how the replica ID of these databases are generated? Is it in the directory the catalog or somewhere else?

  2. Does anyone know if the similar replica ID actually serves a purpose

  3. Does anyone know how to force the database to be created with a similar replica ID to the Domino Directory?

I have included the list of databases and replica ID’s for reference

events4.nsf

Replica ID	Server

4A25696202076EEB	Server1

802560B70248E566	Server2

802560B70248E566	Server3

802560B70248E566	Server4

802560B70248E566	Server5

802560B70248E566	Server5

802560B70248E566	Server6

802560B70248E566	Server6

802560B70248E566	Server7

802560B70248E566	Server8

802560B70248E566	Server9

802560B70248E566	Server10

activity.nsf

Replica ID	Server

4A25696209076EEB	Server5

4A2569620B076EEB	Server3

4A2569620B076EEB	Server4

4A2569620B076EEB	Server6

4A2569620B076EEB	Server10

statrep.nsf

Replica ID	Server

4A25696204076EEB	Server3

CA256A8600140FD1	Server5

CA256A8600140FD1	Server5

CA256AAA002CD2B2	Server8

CA256AB200243677	Server9

CA256AC5002FB749	Server7

CA256B190011E302	Server6

CA256B190011E302	Server6

CA256B270004C9C8	Server2

CA256B3E0005B841	Server1

catalog.nsf

Replica ID	Server

4A25624200527126	Server7

4A25624200527126	Server8

4A25624200527126	Server9

4A25696201076EEB	Server3

4A25696207076EEB	Server2

4A25696207076EEB	Server4

4A25696207076EEB	Server1

4A25696207076EEB	Server5

4A25696207076EEB	Server5

4A25696207076EEB	Server6

4A25696207076EEB	Server6

4A25696207076EEB	Server10

names.nsf

Replica ID	Server

4A25696200076EEB	Server2

4A25696200076EEB	Server3

4A25696200076EEB	Server4

4A25696200076EEB	Server1

4A25696200076EEB	Server1

4A25696200076EEB	Server5

4A25696200076EEB	Server5

4A25696200076EEB	Server6

4A25696200076EEB	Server7

4A25696200076EEB	Server8

4A25696200076EEB	Server9

4A25696200076EEB	Server10

ddm.nsf

Replica ID	Server

4A2569620A076EEB	Server3

4A2569620A076EEB	Server1

CA2572EC000A2649	Server4

CA2572EC000A2649	Server6

CA2572EC000A2649	Server10

admin4.nsf

Replica ID	Server

802560B70348E566	Server2

802560B70348E566	Server3

802560B70348E566	Server4

802560B70348E566	Server1

802560B70348E566	Server5

802560B70348E566	Server5

802560B70348E566	Server6

802560B70348E566	Server7

802560B70348E566	Server8

802560B70348E566	Server9

802560B70348E566	Server10

Subject: Administration databases replica IDs not in synch

Michael,

  1. I think only IBM Lotus knows how exactly the replica ID is generated, but it can be said that it’s based on time and time zone settings. Any replica ID for example of a database created in GMT+1 time zone (ie Amsterdam) starts with C125, the replica of a database created in Chicago time zone (GMT-6) starts with 8625

  2. Yes, it definitely serves a purpose if you want to have the databases replicate. If the replica ID’s are different, databases cannot replicate and they won’t stay in sync.

  3. If the servers can find each other they should create a database with correct replica ID automatically. Some databases, such as admin4.nsf are automatically created when you shut down the server, delete the database and restart the server. That could solve the issue for other databases as well. If the database is not automatically created, create them manually. Important: NEVER delete the Domino Directory (names.nsf) as the server cannot start without it.

An interesting tool to adjust the replica ID’s for databases is Antrid (http://www.rprsystems.com/index.html), but I would advise you not to use in on system databases. It can be very helpfull though when merging different databases into one, such as mail files. Make sure the replica ID’s are the same, replicate them with eachother and done.

Subject: RE: Administration databases replica IDs not in synch

Thanks Frank for such a thorough response.

I have been doing admin for a few years so I am aware of the basic principals of replication and don’t worry there is no was I would delete names.nsf :). I had heard of Antrid but as you suggest I was a little cautions about using such a tool on the admin databases. I would expect the recreation I performed on DDM.nsf by stopping the event task, dbcache flush, deleting the database and loading the event task would have had the same effect as deleting the file from the OS and restarting the server. Doing this generated the same replica ID on DDM.nsf of CA2572EC000A2649. This is still vastly different to that of names.nsf ( 4A25696200076EEB ).

*note the database was definitely deleted, the log shows the delete command executing and when the event task loaded it threw messages about being unable to find and subsequently creating the new DDM.nsf).

All servers in the domain are able to replicate, replication is performed by a central hub server. I can trace successfully from server to any other server.

Subject: RE: Administration databases replica IDs not in synch

Hello Michael

Did you work out if there actually was a problem with having the rep ids of system dbs seemingly unrelated to that of the nab? Or did you find a way to fix the rep ids?

Kind regards

Yahya