Chapter 16. Managing attributes within fractional replication


Fractional replication sets attributes that Directory Server does not replicate from a supplier to a consumer (or another supplier). Therefore, Directory Server can replicate a database without replicating all the information that it contains or all of the information in every entry improving the server performance and security.

Use fractional replication in the following cases:

  • You want to limit the number of large attributes that are sent over a slow network.
  • You want to reduce the number of times that Directory Server runs fixup tasks, such as memberOf calculations.
  • You want to exclude sensitive attributes from replication if a consumer server is placed on an untrusted network.

Fractional replication is enabled and configured per replication agreement, not per entry. Excluding attributes from replication is applied equally to all entries within the replication agreement’s scope. You can set different attributes to be replicated for an incremental update (nsDS5ReplicatedAttributeList) and a total update (nsDS5ReplicatedAttributeListTotal) and prevent empty updates during fractional replication (nsds5ReplicaStripAttrs).

Fractional replication parameters are part of the replication agreement and you can configure these parameters using the command line when the replication agreement is created or in the replication agreement wizard in the web console.

In a basic scenario, fractional replication excludes the same list of attributes from total and incremental updates. However, you can configure Directory Server to exclude different attributes from incremental and total updates for performance reasons by using the following configuration attributes:

nsDS5ReplicatedAttributeList
This is the primary fractional replication attribute. When you set only nsDS5ReplicatedAttributeList, Directory Server excludes specified attributes from both incremental and total updates.
nsDS5ReplicatedAttributeListTotal
This fractional replication attribute specifies the list of attributes that Directory Server must exclude only from total (initial) updates.

For example, every time you add a memberOf attribute to an entry, Directory Server runs a memberOf fixup task to resolve the group membership. This can cause overhead on the server if Directory Server runs the task every time replication occurs. Since a total update only occurs for a database that is newly-added to replication or that has been offline for a long time, running a memberOf fixup task after a total update is an acceptable option. In this case, the nsDS5ReplicatedAttributeList attribute contains memberOf and excludes it from incremental updates, but nsDS5ReplicatedAttributeListTotal does not contains memberOf so that it is included in total updates.

The following procedure excludes different attributes from incremental and total updates.

Prerequisites

  • You replicate dc=example,dc=com suffix and the replication agreement example_agreement exists.

Procedure

  1. Use the dsconf utility to configure the fractional replication:

    # dsconf <instance_name> repl-agmt set example_agreement --suffix="dc=example,dc=com" --frac-list="authorityRevocationList accountUnlockTime memberof" --frac-list-total="accountUnlockTime"
    Copy to Clipboard Toggle word wrap

    The command excludes the authorityRevocationList, accountUnlockTime, and memberof attributes from incremental updates and excludes only accountUnlockTime from total updates.

    NOTE
    If you want to exclude the same list of attributes from total and incremental updates, add the list of excluded attributes only to the nsDS5ReplicatedAttributeList configuration attribute using the`--frac-list` option.
  2. Optional: If you want to prevent empty replication updates, use the --strip-list option to add attributes that Directory Server removes from replication. For details, see Preventing empty updates in fractional replication.

Verification

  • View the replication agreement settings:

    # dsconf <instance_name> repl-agmt list --suffix=dc=example,dc=com | grep -i nsDS5ReplicatedAttributeList
    
    nsDS5ReplicatedAttributeList: (objectclass=&#42;) $ EXCLUDE authorityRevocationList accountUnlockTime memberof
    nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE accountUnlockTime
    Copy to Clipboard Toggle word wrap
    IMPORTANT
    The value of nsDS5ReplicatedAttributeList and nsDS5ReplicatedAttributeListTotal must contain the (objectclass=*) $ EXCLUDE part. If you edit the attribute directly, for example by using the ldapmodify utility, you must specify this part together with the list of excluded attributes.

In a basic scenario, fractional replication excludes the same list of attributes from total and incremental updates. However, you can configure Directory Server to exclude different attributes from incremental updates for performance reasons.

Prerequisites

  • You replicate dc=example,dc=com suffix and the replication agreement example_agreement exists.

Procedure

  1. Navigate to Replication Agreements.
  2. Click the Options menu (⋮) of the agreement, where you want to configure the fractional replication, and select Edit to open the wizard window.
  3. Open the Fractional Settings tab and set the following fields:

    • If you want to exclude the same attributes from total and incremental updates, add these attributes only to the Exclude Attributes field.
    • If you want to exclude different attributes from total and incremental updates:

      1. Add attributes excluded from incremental updates to the Exclude Attributes field that configures the nsDS5ReplicatedAttributeList parameter.
      2. Add attributes excluded from total (initial) updates to the Exclude Init Attributes field that configures the nsDS5ReplicatedAttributeListTotal parameter.
  4. Optional: If you want to prevent empty replication updates, add attributes that Directory Server removes from replication to the Strip Attributes field.
  5. Click Save Agreement button.

Verification

  • Open the replication agreement setting to view the changes.

Fractional replication excludes attributes from replication updates (nsDS5ReplicatedAttributeList, nsDS5ReplicatedAttributeListTotal). However, a change to an excluded attribute still triggers a modify event and generates an empty replication update.

To prevent empty updates, use the nsds5ReplicaStripAttrs parameter that adds a list of attributes that Directory Server does not send in an empty replication event and strips from the update sequence. This logically must include operational attributes like modifiersName. If a replication event is not empty, Directory Server still replicates the stripped attributes with other changes.

For example, you excluded the accountUnlockTime attribute from the replication. For a locked user, when the time period set in accountUnlockTime expires, Directory Server automatically unlocks the user. Only the accountUnlockTime attribute has changed, and that attribute is excluded from replication. However, this unlock event also changes the operational attribute internalmodifytimestamp. This triggers a replication event because the user account was modified. But the only data to replicate is the new modify time stamp, otherwise the update is empty. If you have a large number of attributes related to login times or password expiration times, this can create many empty replication updates that negatively affect server performance or interfere with associated applications.

The following procedure strips unnecessary attributes to prevent empty updates.

Prerequisites

  • You replicate dc=example,dc=com suffix and the replication agreement example_agreement exists.

Procedure

  1. Use dsconf utility to tune the fractional replication:

    # dsconf <instance_name> repl-agmt set example_agreement \
        --suffix="dc=example,dc=com" --strip-list="modifiersname \
        modifytimestamp internalmodifiersname"
    Successfully updated agreement
    Copy to Clipboard Toggle word wrap

Verification

  • View the replication agreement settings:

    # dsconf <instance_name> repl-agmt list --suffix=dc=example,dc=com | grep -i nsds5ReplicaStripAttrs
    nsds5ReplicaStripAttrs: modifiersname modifytimestamp internalmodifiersname
    Copy to Clipboard Toggle word wrap

16.4. Viewing replication keep-alive entries

When you update an attribute on a supplier in a replication topology, the changelog change sequence number (CSN) is increased on the supplier. Then the supplier connects to the first consumer and compares the local CSN with the CSN on the consumer. If it is lower, the update is retrieved from the local changelog and replicated to the consumer. In a replication topology with fractional replication enabled, this can cause problems. For example, if only attributes are updated on the supplier that are excluded from replication, no update to replicate is found, and therefore the CSN is not updated on the consumer. In addition, unnecessary searches for updates on the supplier can cause other servers to receive the data later than needed. To work around this problem, Directory Server uses keep-alive entries.

If all updated attributes on the supplier are excluded from replication and the number of skipped updates exceeds 100, Directory Server updates the keepalivetimestamp attribute on the supplier, replicates it to the consumer, and changes the CSN on the consumer. Now CSN on the consumer equals to the CSN on the supplier, and the next time the supplier connects to the consumer only updates that are newer than the CSN on the consumer are searched. This reduces the time a supplier spends to search for new updates to send.

Directory Server automatically creates or updates the replication keep-alive entry on a supplier in the following situations:

  • When a fractional replication agreement skips more than 100 updates and does not send any updates before ending the replication session.
  • When a supplier initializes a consumer, initially it creates its own keep-alive entry. A consumer that is also a supplier does not create its own keep-alive entry unless it also initializes another consumer.

The following procedure searches for the keep-alive entry details that you can use to solve replication problems.

Prerequisites

  • The Directory Manager password

Procedure

  1. Use the ldapsearch utility to find the keep-alive entry:

    # ldapsearch -D "cn=Directory Manager" -b "dc=example,dc=com" -W -H ldap://server.example.com -x 'objectClass=ldapsubentry'
    Enter LDAP Password: password
    
    # repl keep alive 1, example.com
    dn: cn=repl keep alive 1,dc=example,dc=com
    keepalivetimestamp: 20250204204708Z
    objectClass: top
    objectClass: ldapsubentry
    objectClass: extensibleObject
    cn: repl keep alive 1
    Copy to Clipboard Toggle word wrap

    Each keep-alive entry is specific to a given supplier and contains the replica ID of the supplier in the distinguished name (DN). In the example, the replica ID is 1.

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat