L'esempio in questa sezione illustra come la matrice del numero epoch viene modificata sui vari siti appena si verificano la creazione e la sincronizzazione della replica.
- Prima di abilitare la replica per la prima volta in boston_hub, la matrice del numero epoch è vuota:
multitool lsepoch
For VOB replica "/vobs/dev":
Oplog IDs for row "original" (@ minuteman):
original=0
- Una volta che l’amministratore ha utilizzato mkreplica –export per creare una nuova
replica (sanfran_hub), la matrice del numero epoch di boston_hub contiene una riga per
sanfran_hub (l'amministratore ha ridenominato l'origine di replica in 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
- Una volta che l'amministratore sulla replica sanfran_hub importa il pacchetto di creazione della replica, la matrice del numero epoch per
sanfran_hub appare nel modo seguente:
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
- Appena il lavoro di sviluppo si verifica sulle due repliche, ogni record di replica del proprio stato viene aggiornato di conseguenza. Tuttavia, poiché non si verificano sincronizzazioni, ogni stima della replica dello stato dell’altra replica non viene modificata.
In 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
In 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
- L'amministratore di boston_hub immette un comando syncreplica –export
per creare un pacchetto di aggiornamento per sanfran_hub.
La riga sanfran_hub viene aggiornata
per mostrare che tutte le operazioni utilizzate in boston_hub saranno applicate nella replica 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
- In sanfran_hub, l'amministratore applica il pacchetto di aggiornamento. La matrice del numero epoch per sanfran_hub riflette le modifiche apportate alla replica 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
Esempio: sincronizzazione e matrice del numero epoch
Il seguente esempio illustra come viene modificata la matrice del numero epoch sulle varie repliche
appena si verificano la sincronizzazione e la creazione della replica.
- In seguito all'attivazione, ma prima che la replica sia abilitata per la prima volta in
boston_hub, la matrice del numero epoch è vuota:
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
- Una volta che l'amministratore sulla replica sanfran_hub importa il pacchetto di creazione della replica, la matrice del numero epoch per
sanfran_hub appare nel modo seguente:
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 stima di sanfran_hub è 0. In questo esempio, sanfran_hub stima anche l'esito positivo delle due operazioni del database in boston_hub. Queste operazioni possono essere comprese nell'intervallo dalla creazione di un nuovo
record alla creazione di una replica.
- Appena il lavoro di sviluppo si verifica sulle due repliche, ogni record di replica del proprio stato viene aggiornato di conseguenza. Tuttavia, poiché non si verificano sincronizzazioni, ogni stima della replica dello stato dell’altra replica non viene modificata.
In 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
In 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
- L'amministratore di boston_hub immette un comando syncreplica -export
per creare un pacchetto di aggiornamento per sanfran_hub.
- In boston_hub, la riga sanfran_hub viene aggiornata
per mostrare che tutte le operazioni utilizzate in boston_hub sono state inviate nella replica 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
- In sanfran_hub, l'amministratore importa il pacchetto di aggiornamento. La matrice del numero epoch per sanfran_hub riflette le modifiche apportate alla replica 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