Exemplo: Sincronização e a Matriz de Números de Época

O exemplo neste tópico ilustra como a matriz de números de época é alterada em vários sites quando ocorrem criação e sincronização de réplica.
  1. Antes da replicação ser ativada pela primeira vez em boston_hub, sua matriz de números de época está vazia:
    multitool lsepoch 
    For VOB replica "/vobs/dev":
    Oplog IDs for row "original" (@ minuteman):
         original=0
  2. Depois que o administrador utiliza mkreplica –export para criar uma nova réplica (sanfran_hub), a matriz de números de época de boston_hub contém uma linha para sanfran_hub (observe também que o administrador renomeou a réplica original para 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
  3. Depois que o administrador na réplica sanfran_hub importa o pacote de criação de réplicas, a matriz de números de época de sanfran_hub fica semelhante ao seguinte:
    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
  4. À medida que ocorre o trabalho de desenvolvimento nas duas réplicas, o registro de cada réplica de seu próprio estado é atualizado de acordo. No entanto, como não ocorreu nenhuma sincronização, a estimativa de cada réplica do estado da outra réplica não é alterada.
    At 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
    At 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
  5. O administrador em boston_hub digita um comando syncreplica –export para gerar um pacote de atualização para sanfran_hub.
    A linha sanfran_hub é atualizada para mostrar que todas as operações que ocorreram em boston_hub serão aplicadas à réplica de 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
  6. Em sanfran_hub, o administrador aplica o pacote de atualização. A matriz de números de época para sanfran_hub agora reflete as alterações feitas na réplica de 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

Exemplo: Sincronização e a Matriz de Números de Época

O exemplo a seguir ilustra como a matriz de números de época é alterada em várias réplicas quando ocorrem criação e sincronização de réplica.
  1. Após a ativação, mas antes da replicação ser ativada pela primeira vez em boston_hub, sua matriz de números de época está vazia:

    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

  2. Depois que o administrador na réplica sanfran_hub importa o pacote de criação de réplicas, a matriz de números de época de sanfran_hub fica semelhante ao seguinte:

    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: A estimativa de sanfran_hub de si mesmo é 0. Neste exemplo, sanfran_hub também estima que duas operações do banco de dados ocorreram em boston_hub. Essas operações podem variar da criação de um novo registro até a criação de uma réplica.
  3. À medida que ocorre o trabalho de desenvolvimento nas duas réplicas, o registro de cada réplica de seu próprio estado é atualizado de acordo. No entanto, como não ocorreu nenhuma sincronização, a estimativa de cada réplica do estado da outra réplica não é alterada.

    At 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

    At 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

  4. O administrador em boston_hub digita um comando syncreplica -export para gerar um pacote de atualização para sanfran_hub.
  5. Em boston_hub, a linha sanfran_hub é atualizada para mostrar que todas as operações que ocorreram em boston_hub foram enviadas para a réplica de 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

  6. Em sanfran_hub, o administrador importa o pacote de atualização. A matriz de números de época para sanfran_hub agora reflete as alterações feitas na réplica de 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


Feedback