Product SiteDocumentation Site

16.7. Managing Replication Agreements Between FreeIPA Servers

Information is shared between the FreeIPA servers and replicas using multi-master replication. What this means is that servers and replicas all receive updates and, therefore, are data masters. The domain information is copied between the servers and replicas using replication.
As replicas are added to the domain, mutual replication agreements are automatically created between the replica and the server it is based on. Additional replication agreements can be created between other replicas and servers or the configuration of the replication agreement can be changed using the ipa-replica-manage command.
When a replica is created, the replica install script creates two replication agreements: one going from the master server to the replica and one going from the replica to the master server.
Server and Replica Agreements
Figure 16.1. Server and Replica Agreements

As more replicas and servers are added to the domain, there can be replicas and servers that have replication agreements to other servers and replicas but not between each other. For example, the first FreeIPA server is Server A. Then, the admin creates Replica B, and the install script creates a Server A => Replica B replication agreement and a Replica B => Server A replication agreement. Next, the admin creates Replica C based on Server A. The install script creates a Server A => Replica C replication agreement and a Replica C => Server A replication agreement. Replica B and Replica C both have replication agreements with Server A — but they do not have agreements with each other. For data availability, consistency, failover tolerance, and performance, it can be beneficial to create a pair of replication agreements between Replica B and Replica C, even though their data will eventually be replicated over to each other through replication with Server A.

16.7.1. Listing Replication Agreements

The ipa-replica-manage command can list all of the servers and replicas in the replication topology, using the list command:
# ipa-replica-manage list
srv1.example.com
srv2.example.com
srv3.example.com
srv4.example.com
After getting the server/replica list, then it is possible to list the replication agreements for the server. These are the other servers/replicas to which the specified server sends updates.
# ipa-replica-manage list srv1.example.com
srv2.example.com
srv3.example.com

16.7.2. Creating and Removing Replication Agreements

Replication agreements are created by connecting one server to another server.
ipa-replica-manage server1 server2
If only one server is given, the replication agreements are created between the local host and the specified server.
For example:
# ipa replica-manage connect srv2.example.com srv4.example.com
Replication occurs over standard LDAP; to enable SSL, then include the CA certificate for the local host (or the specified server1). The CA certificate is then installed in the remote server's certificate database to enable TLS/SSL connections. For example:
# ipa replica-manage connect --cacert=/etc/ipa/ca.crt srv2.example.com srv4.example.com
To remove a replication agreement between specific servers/replicas, use the disconnect command:
# ipa replica-manage disconnect srv2.example.com srv4.example.com
Using the disconnect command removes that one replication agreement but leaves both the server/replica instances in the overall replication topology. To remove a server entirely from the FreeIPA replication topology, with all its data, (and, functionally, removing it from the FreeIPA domain as a server), use the del server:
# ipa replica-manage del srv2.example.com

16.7.3. Forcing Replication

Replication between servers and replicas occurs on a schedule. Although replication is frequent, there can be times when it is necessary to initiate the replication operation manually. For example, if a server is being taken offline for maintenance, it is necessary to flush all of the queued replication changes out of its changelog before taking it down.
To initiate a replication update manually, use the force-sync command. The server which receives the update is the local server; the server which sends the updates is specified in the --from option.
# ipa replica-manage force-sync --from srv1.example.com

16.7.4. Reinitializing FreeIPA Servers

When a replica is first created, the database of the master server is copied, completely, over to the replica database. This process is called initialization. If a server/replica is offline for a long period of time or there is some kind of corruption in its database, then the server can be re-initialized, with a fresh and updated set of data.
This is done using the re-initialize command. The target server being initialized is the local host. The server or replica from which to pull the data to initialize the local database is specified in the --from option:
# ipa replica-manage re-initialize --from srv1.example.com