La replicación de geodatabases se genera encima del versionado tradicional. Durante la creación de réplicas, las versiones de las geodatabases corporativas de origen y objetivo se establecen como versiones de réplica. Los cambios en estas versiones de réplica se intercambian durante la sincronización. Puesto que las versiones de réplica están vinculadas, puede pensar en ellas como una manera de extender la jerarquía de versiones para que abarque varias geodatabases.
La versión predeterminada, o cualquier versión con nombre, se puede utilizar como versión de réplica para la réplica primaria o secundaria. Varias réplicas pueden compartir también la misma versión de réplica.
Réplicas unidireccionales y bidireccionales
El siguiente diagrama muestra las versiones de réplica para réplicas unidireccionales y bidireccionales. Para la replicación bidireccional, la réplica primaria utiliza la versión denominada RV1 como versión de réplica. La réplica primaria de los ejemplos de replicación unidireccional utiliza la versión denominada RV2 como versión de réplica para ambos ejemplos.
Para ambas réplicas secundarias alojadas en geodatabases corporativas, la versión predeterminada es la versión de réplica. Aparte del hecho de que se utilizan para la replicación, las versiones de réplica no son diferentes de otras versiones. Dado que las geodatabases de archivos no admiten el versionado, no se crea ninguna versión de réplica en la geodatabase secundaria de una réplica unidireccional.
Nota:
También es posible utilizar una versión con nombre como versión de réplica en cualquier geodatabase corporativa en el diagrama siguiente.
Réplicas de check-out
La replicación de check-out/check-in es capaz de replicar tanto datos versionados como datos no versionados. Para las réplicas de check-out que implican datos versionados, se crea una nueva versión con nombre para que sirva como versión de réplica secundaria, si la réplica secundaria es una geodatabase corporativa.
La replicación de check-out/check-in también permite que las geodatabases de archivos alojen réplicas secundarias. Puesto que estos tipos de geodatabase no admiten el control de versiones, no se crea ninguna versión de réplica para el elemento secundario. Éste es también el caso cuando se desprotegen datos no versionados. Para estos escenarios, se utiliza lógica adicional para determinar los cambios que se envían durante la sincronización.
Al utilizar la replicación de check-out/check-in, se crea una nueva versión con el nombre de la réplica. La combinación de nombre de usuario y nombre de réplica debe ser única. Por ejemplo, user1 y user2 podrían crear cada uno una réplica llamada MyReplica, porque los nombres completos de las réplicas serían user1.MyReplica y user2.MyReplica. Sin embargo, user1 no podría crear más de una réplica denominada MyReplica, porque ese nombre de réplica no sería único.
El siguiente diagrama muestra dos ejemplos de réplicas de check-out/check-in y sus versiones de réplica. Una réplica primaria utiliza la versión RV1 como la versión de réplica, que la otra utiliza la versión RV2 como la versión de réplica. Una réplica secundaria está alojada en un archivo y la otra está alojada en una geodatabase corporativa. Para la geodatabase corporativa que aloja la réplica secundaria, se creó automáticamente RV2 y se estableció como la versión de réplica durante la creación. El nombre RV2 para esta versión de réplica se tomó del nombre de la réplica. Esta versión de réplica es en la que se realizarán las ediciones en la réplica secundaria para la sincronización con la réplica principal.
Explorar:
Para las réplicas de check-out/check-in, durante la creación se agrega una versión de sincronización a la geodatabase de la réplica principal. La versión de sincronización es un elemento secundario de la versión de réplica pero no se muestra arriba, puesto que solo se utiliza durante la sincronización. Consulte Sincronización y versionado para obtener más información.
Utilizar el archivado para realizar el seguimiento de los cambios de la réplica
En el caso de la replicación unidireccional, puede decidir utilizar el archivado en lugar del control de versiones para realizar el seguimiento de los cambios de la réplica. En el caso de esta opción, la geodatabase principal debe ser una geodatabase corporativa que haga referencia a la versión predeterminada. La ventaja de administrar la replicación de esta manera es que mantiene los procesos de conciliación y compresión separados del proceso de sincronización.
Cuando se utiliza el control de versiones para realizar el seguimiento de los cambios, se crean versiones del sistema. Debido a estas versiones del sistema, es necesario sincronizar periódicamente para lograr una compresión efectiva. Cuando se utiliza el archivado para hacer el seguimiento de los cambios de réplica, no se crean versiones del sistema. Por tanto, los procesos reconciliar y enviar y comprimir no se ven afectados, con lo que se consigue una administración de la versión y de la réplica independientes. Esto también posibilita que el programa de sincronización sea más flexible.
En el diagrama que aparece a continuación, se muestra una replicación unidireccional de principal a secundaria con archivado entre geodatabases corporativas, en la que se utiliza la versión predeterminada como versión de réplica tanto para la réplica principal como para la réplica secundaria en la geodatabase corporativa. Dado que las geodatabases de archivos no admiten el versionado, no se crea ninguna versión de réplica en la geodatabase de archivos secundaria.
La replicación unidireccional de secundaria a principal también se puede utilizar cuando ambas geodatabases son geodatabases corporativas. La versión de réplica secundaria debe ser la predeterminada en este caso.
