Available with Standard or Advanced license.
Geodatabase replication supports many workflow options on top of those already offered through traditional versioning. The following are a number of scenarios accommodated through geodatabase replication.
Replica tree
Geodatabase replication can be used to create replica trees, similar to version trees, allowing organizations to distribute their data across several geodatabases in a hierarchical structure.
For example, some organizations require the ability to replicate a single organization-wide geodatabase across different offices. Each office has a replica with only the data applicable to its area and can transfer changes of this data to the main office. This allows the main office to perform analysis on data that is up to date across the entire extent. Connections within an office are fast, but they are much slower between offices. The regional offices can also replicate their geodatabases to local offices in the same way that the main office replicates its geodatabase to the regions.
Central hub
A replica geodatabase can be used as a central hub to host readers and editors. To keep connection speeds fast, editors can create a replica to check out data from the central hub, perform edits, and then check the changes back in by synchronizing with the geodatabase.
The central hub can also be used to propagate changes between multiple child replicas. To move changes from one replica to another, the changes in one replica are first synchronized with the parent (or hub) replica. A second child replica can then synchronize with the parent to get these changes.
Mobile users
Mobile users within an organization, such as a maintenance crew, require the ability to edit a portion of the enterprise geodatabase in the field. They need to disconnect completely from the organization's infrastructure, often for a prolonged period of time. When preparing for a particular work order or project, the relevant data is replicated and transferred to a portable device, such as a laptop. This device is then disconnected from the network, enabling the field crew to operate independently of the network. The field crew can continue to work with and modify the replicated data even though they are disconnected from the network. When a connection to the network is reestablished, any changes made to the data will be transferred back and synchronized with data maintained in the enterprise geodatabase.
Tip:
For this scenario, it is recommended that each field editor have their own replica to work with. If there are numerous editors that will be syncing at the same time, it is recommended that each editor have their own version and create a replica from that version. This simplifies the synchronization process and avoids conflicting data collection.
Contractors
Some organizations need to contract out the maintenance for part of their geodatabase and have that contractor provide updates every month. The organization needs to be able to incorporate the contractor's changes without completely reloading the data. It also needs an easy way to review just the updates for the month instead of having to perform QA tests on the entire dataset.
This can be accomplished by sending the contractor a replica of the appropriate data for updates. When the contractor sends the changes back to the organization, they can be synchronized with the data maintained in the enterprise geodatabase.
Production and publication geodatabases
An organization needs to support a group of editors as well as users accessing the system with read-only access. To satisfy the requirements of each group, the organization has two enterprise geodatabases. One is a production geodatabase, which is edited directly by the editors, while the other is a replica of this geodatabase and is accessed by the readers. Readers can access this data through ArcGIS Enterprise.
In this scenario, the replica in the publication geodatabase is a read-only copy of the production geodatabase. The data on the publication geodatabase does not need to be versioned. The replication can be restricted to sending data in only one direction. Edits are made on the production geodatabase and are sent from it to the publication geodatabase. These edits are transferred and synchronized with the data on the publication geodatabase and then served to the readers.
Multigroup data management
Within your organization, data management may be divided among several different groups. For example, one group may be in charge of managing the physical assets, while another is tasked with managing the land base data for the same area. Another example is where several teams are working on many completely independent projects. The datasets for each project may for the most part be from different geographic areas, but the organization wants a central repository for all projects.
Your organization can use geodatabase replication to distribute your data among various groups, splitting up data into appropriate projects. Each project team receives a replica of the necessary data from the central enterprise geodatabase. The teams then edit each replica independently of one another, possibly in separate geographic locations, and transfer those edits to the central enterprise geodatabase. Conversely, any edits made to the central enterprise geodatabase are transferred to the appropriate replica in the project teams as well.
Centralized data from many sources
Another common replication practice is to have a centralized location where data is collected. Organizations set up in this manner have a central geodatabase that houses a collection of data from other offices.
An example of this is distribution of data between state offices and a national office. Each state office works independently, managing its own datasets and periodically sending updates to the national office. The edits from each state are synchronized into one comprehensive dataset in the national geodatabase. In this child-to-parent replication configuration, the national geodatabase is assigned the role of parent, and the state geodatabases are assigned the role of child.
