The three types of geodatabase replication are checkout/check-in, one-way, and two-way.
For all replication types, data from an enterprise geodatabase must be used as the source for replica creation. The three replication types are described below.
Checkout/check-in replication allows you to edit the data in the child replica and synchronize these edits with the parent replica.
Once the data has been synchronized, you can no longer synchronize additional edits. If additional edits are required, you must create a new checkout/check-in replica. When creating checkout/check-in replicas, the destination can be either an enterprise or file geodatabase.
One-way replication allows data changes to be sent multiple times in a single direction, from parent to child replica or from child to parent replica. One-way replicas persist after synchronization, allowing you to continue sending data changes.
- One-way, parent-to-child replication—The data in the parent replica is editable, but the data in the child is considered read-only. If edits are performed on the data in the child replica, the edits are overwritten if they conflict with edits applied during synchronization. When creating a one-way, parent-to-child replica, the destination can be an enterprise or file geodatabase.
- One-way, child-to-parent replication—This works in a similar manner, but in the opposite direction. Here the data in the child replica is editable, but the data in the parent replica is considered read-only. If edits are performed on the data in the parent replica, the edits are overwritten if they conflict with edits applied during synchronization. When creating a one-way, child-to-parent replica, both child and parent replicas must be hosted in an enterprise geodatabase.
Two-way replication allows data changes to be sent multiple times from the parent replica to the child replica and/or from the child replica to the parent replica. If the same row is edited in both replica geodatabases, it is detected as a conflict when the replicas are synchronized. Reconcile policies are provided to define how conflicts are processed.
Two-way replicas continue to exist after synchronization, allowing you to continue editing and synchronizing the replicas. When creating two-way replicas, the destination must be an enterprise geodatabase.
Choose a replica type
When deciding which replica type to use, consider the following:
- If you require the ability to create replicas in file geodatabases, you must use either checkout/check-in or one-way replication.
- Two-way replication allows you to synchronize multiple times without having to re-create replicas. This replica type requires an enterprise geodatabase for the source and destination geodatabases.
- One-way replication is ideal for cases where you want to publish changes from your production server to your publication server. One-way replication enforces unidirectional synchronization and doesn't require the child replica's data to be versioned if using the simple model. With a simple model, the fact that the types are simple makes the data more interoperable, since it doesn't have to conform to complex geodatabase data structures.
- If implementing a one-way system where you sometimes need to edit the child replica's data, consider using two-way replication. Since one-way replication assumes that the data is read-only on the child replica, a synchronization might overwrite edits to the child replica's data. The conflict detection logic of two-way replication flags these differences as conflicts, allowing you to decide how to handle the differences. Two-way replication allows data exchange in both directions but also works in cases where you only send changes in one direction.
The following table summarizes the different geodatabase replication types:
|Child replica is stored within a file geodatabase||Supports multiple syncs before unregistering||Can sync updates in both directions|
Checkout/check-in to file geodatabase
Checkout/check-in to enterprise geodatabase
One-way to file geodatabase (Parent - Child)
One-way to enterprise geodatabase (Parent - Child)
One-way to enterprise geodatabase (Child - Parent)
Two-way to enterprise geodatabase