Solutions
ForgeRock Identity Platform
Does not apply to Identity Cloud

Generation IDs do not match error after restoring a DS (All versions) replica

Last updated Jan 12, 2023

The purpose of this article is to provide assistance if a "Generation IDs do not match" error occurs during replication after restoring an old backup or LDIF data to a DS instance.


Note

This article is specific to restoring old data only.

Similar errors are expected on a new directory server node after you configure replication but before you initialize replication. This is normal and the final phase of setting up replication, as the new backend needs the Generation ID task run to reset the Generation ID. See Manual Initialization for further information.

Symptoms

When restoring a replica, the following error is shown in the DS error logs:

[10/Oct/2016:15:19:33 +0000] category=SYNC severity=SEVERE_WARNING msgID=15 msg=Directory server DS(42134) has connected to replication server RS(42706) for domain "cn=admin data" at ds.example.com/10.127.0.61:8080, but the generation IDs do not match, indicating that a full re-initialization is required. The local (DS) generation ID is 123456 and the remote (RS) generation ID is 987654 [10/Oct/2016:15:19:33 +0000] category=SYNC severity=SEVERE_WARNING msgID=15 msg=Replication server RS(42706) not sending update 00000148c7a7e07c102600000001 for domain "cn=admin data" to directory server DS(42134) at ds.example.com/10.127.0.61:8989 because its generation ID 123456 is different to the local generation ID 987654

The restored replica is not synchronized with the other replication servers.

Recent Changes

Restored an old backup or imported LDIF data to a DS instance.

Causes

The generation ID contained in the restored data is not the same as the one in the current replication topology. The generation ID is a checksum of attributes from some entries and is used during replication to check that the suffix being updated is the same as the one offering the updates.

Solution

This issue can be resolved using one of the following approaches:

  • Re-initialize the suffix from another replica, since the generation IDs will naturally be in sync.
  • Restore a replica as follows if you are certain the data is correct:
    • DS 7 and later: Use the start-disaster-recovery and end-disaster-recovery commands as part of your restore process.
    • DS 6.x: Use the pre-external-initialization and post-external-initialization commands as part of your restore process.

Re-initialize the suffix

You can re-initialize the suffix as follows:

  • DS 7.1 and later: $ ./dsrepl initialize --bindDN uid=admin --bindPassword password --baseDN dc=example,dc=com --toServer ds-1 --hostname localhost --port 4444 --trustStorePath /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --no-prompt
  • DS 7: $ ./dsrepl initialize --bindDN uid=admin --bindPassword password --baseDN dc=example,dc=com --toServer ds-1 --hostname localhost --port 4444 --trustStorePath /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --no-prompt
  • DS 6.x: $ ./dsreplication initialize --adminUID admin --adminPassword password --baseDN dc=example,dc=com --hostSource ds1.example.com --portSource 4444 --hostDestination ds2.example.com --portDestination 5444 --trustAll --no-prompt

Use start-disaster-recovery and end-disaster-recovery (DS 7 and later)

If you are certain the data is correct, you can use start-disaster-recovery and end-disaster-recovery commands as part of your restore process. These commands ensure the generation ID of the replicated domain is updated. "Old" changes will not get replayed because they were targeting the data using the previous generation ID.

You restore a replica as follows:

  1. Run the following command to force all replicas' generation IDs for the affected data to an invalid state; this stops replication completely for the affected data:
    • DS 7.1 and later: $ dsrepl start-disaster-recovery --baseDN dc=example,dc=com --hostname ds.example.com --port 4444 --bindDN uid=admin --bindPassword password --trustStorePath /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --no-prompt
    • DS 7: $ dsrepl start-disaster-recovery --baseDN dc=example,dc=com --hostname ds.example.com --port 4444 --bindDN uid=admin --bindPassword password --trustStorePath /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --no-prompt
  2. Restore or import from ldif to restore the data:
  3. Run the following command to recalculate all replicas' generation IDs for the affected data; this resumes replication. Ensure you use the same baseDN as in step 1:
    • DS 7.1 and later: $ dsrepl end-disaster-recovery --baseDN dc=example,dc=com --hostname ds.example.com --port 4444 --bindDN uid=admin --bindPassword password --trustStorePath /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --no-prompt
    • DS 7: $ dsrepl end-disaster-recovery --baseDN dc=example,dc=com --hostname ds.example.com --port 4444 --bindDN uid=admin --bindPassword password --trustStorePath /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --no-prompt

Use pre-external-initialization and post-external-initialization (DS 6.x)

If you are certain the data is correct, you can use pre-external-initialization and post-external-initialization as part of your restore process. These commands ensure the generation ID of the replicated domain is updated. "Old" changes will not get replayed because they were targeting the data using the previous generation ID.

You restore a replica as follows:

  1. Prepare the domain on all servers for being externally initialized. You must specify the baseDN of the data you are going to be changing, for example:$ ./dsreplication pre-external-initialization --hostname ds.example.com --port 4444 --baseDN dc=example,dc=com --adminUID admin --adminPassword password --trustAll --no-prompt
  2. Restore or import from ldif to restore the data:
    • Using the restore command, for example: $ ./restore --hostname ds.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --backupID 20160614031032Z --backupDirectory /path/to/ds/backupfile
    • Using the import-ldif command, for example: $ ./import-ldif --hostname ds.example.com --port 4444--includeBranch dc=example,dc=com --backendID userRoot --ldifFile /path/to/ldif_file
  3. Enter the following command to set the new generation ID for the domain and broadcast it to all the servers, which allows them to replicate again. Ensure you use the same baseDN as in step 1: $ ./dsreplication post-external-initialization --hostname ds.example.com --port 4444 --baseDN dc=example,dc=com --adminUID admin --adminPassword password --trustAll --no-prompt

See Also

How do I restore old backup data to a DS 6.x replication topology?

How do I roll back an entire network of DS 6.x replicas to a previous backup?

How do I configure DS 6.x to ensure accidentally deleted or changed data can be restored when replication is enabled?

Manual Initialization

Backup and Restore

Related Training

ForgeRock Directory Services Core Concepts (DS-400)

Related Issue Tracker IDs

N/A


Copyright and Trademarks Copyright © 2023 ForgeRock, all rights reserved.