El ejemplo en este tema ilustra cómo la matriz de números de época cambia en varios sitios
a medida que se produce la creación y sincronización de réplicas.
- Antes de que se habilite la réplica por primera vez en boston_hub, su matriz de números de época
está vacía:
multitool lsepoch
For VOB replica "/vobs/dev":
Oplog IDs for row "original" (@ minuteman):
original=0
- Después de que el administrador utilice mkreplica –export para crear una répica nueva
(sanfran_hub), la matriz de números de época de boston_hub contiene una fila para sanfran_hub
(observe también que el administrador ha renombrado la réplica original a boston_hub):
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
sanfran_hub=0
original=1
Oplog IDs for row "sanfran_hub" (@ goldengate):
original=0
sanfran_hub=0
- Después de que el administrador en la réplica sanfran_hub importa el paquete de creación de réplicas, la
matriz de números de época para sanfran_hub tiene el aspecto siguiente:
multitool lsepoch
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
original=1
sanfran_hub=0
Oplog IDs for row "sanfran_hub" (@ goldengate):
original=1
sanfran_hub=1
- A medida que se produce el trabajo de desarrollo en las dos réplicas, cada registro de réplica
de su propio estado se actualiza consecuentemente. No obstante, puesto que no ha tenido lugar ninguna sincronización,
la estimación de cada réplica del estado de la otra réplica no cambia.
En boston_hub:
multitool lsepoch
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
sanfran_hub=0
original=9
Oplog IDs for row "sanfran_hub" (@ goldengate):
original=0
sanfran_hub=0
En sanfran_hub:
multitool lsepoch
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
original=1
sanfran_hub=0
Oplog IDs for row "sanfran_hub" (@ goldengate):
original=1
sanfran_hub=4
- El administrador en boston_hub especifica un mandato syncreplica –export para generar
un paquete de actualización para sanfran_hub.
La fila de sanfran_hub se actualiza para
mostrar que todas las operaciones que han tenido lugar en boston_hub se aplicarán a la réplica
sanfran_hub:
multitool lsepoch
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
sanfran_hub=0
boston_hub=10
Oplog IDs for row "sanfran_hub" (@ goldengate):
boston_hub=10
sanfran_hub=0
- En sanfran_hub, el administrador aplica el paquete de actualización. La matriz de números de época
para sanfran_hub refleja ahora los cambios efectuados en la réplica boston_hub:
multitool lsepoch
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
boston_hub=10
sanfran_hub=0
Oplog IDs for row "sanfran_hub" (@ goldengate):
boston_hub=10
sanfran_hub=4
Ejemplo: sincronización y la matriz de números de época
El siguiente ejemplo ilustra cómo la matriz de números de época cambia
en varias réplicas a medida que se produce la creación y sincronización.
- Tras la activación, pero antes de que se habilite la réplica por primera vez en
boston_hub, la matriz de números de época está vacía:
multiutil lsepoch -clan
telecomm -site boston_hub -family PRODA -user lexadmin -password secret
Multiutil:
Estimates of the epochs from each site replayed at each site ‘boston_hub’
(@host1):
boston_hub: 0
- Después de que el administrador en la réplica sanfran_hub importa el paquete de creación de réplicas, la
matriz de números de época para sanfran_hub tiene el aspecto siguiente:
multiutil
lsepoch -clan telecomm -site sanfran_hub -family PRODA -user sfadmin -password
secret
Multiutil: Estimates of the epochs from each site replayed
at each site ‘SANFRAN_HUB’ (@host2):
boston_hub: 2
SANFRAN_HUB:0
Nota: La propia estimación de sanfran_hub
es 0. En este ejemplo, sanfran_hub también estima que se han producido dos operaciones de bases de datos en
boston_hub. Estas operaciones podrían ir desde la creación de un registro nuevo hasta la creación de una réplica.
- A medida que se produce el trabajo de desarrollo en las dos réplicas, cada registro de réplica
de su propio estado se actualiza consecuentemente. No obstante, puesto que no ha tenido lugar ninguna sincronización,
la estimación de cada réplica del estado de la otra réplica no cambia.
En boston_hub:
multiutil lsepoch -clan telecomm -site
boston_hub -user lexadmin -password secret boston_hub
Multiutil: Estimates
of the epochs from each site replayed at each site ‘boston_hub’ (@host1):
boston_hub:
12
SANFRAN_HUB:0
En sanfran_hub:
multiutil lsepoch
-clan telecomm -site sanfran_hub -user sfadmin -password secret
Multiutil:
Estimates of the epochs from each site replayed at each site ‘SANFRAN_HUB’
(@host2):
boston_hub: 2
SANFRAN_HUB:7
- El administrador en boston_hub especifica un mandato syncreplica –export para generar
un paquete de actualización para sanfran_hub.
- En boston_hub, la fila de sanfran_hub se actualiza para
mostrar que todas las operaciones que han tenido lugar en boston_hub se han envido a la réplica sanfran_hub:
multiutil lsepoch -clan telecomm -site boston_hub -user lexadmin -password
secret sanfran_hub
Multiutil: Estimates of the epochs from each site
replayed at each site ‘SANFRAN_HUB’ (@host1):
boston_hub: 12
SANFRAN_HUB:0
- En sanfran_hub, el administrador importa el paquete de actualización. La matriz de números de época
para sanfran_hub refleja ahora los cambios efectuados en la réplica boston_hub:
multiutil lsepoch -clan telecomm -site sanfran_hub -user sfadmin
-password secret sanfran_hub
Multiutil: Estimates of the epochs from
each site replayed at each site ‘SANFRAN_HUB’ (@host1):
boston_hub:
12
SANFRAN_HUB:7