Trabalhe com a replicação entre centros de dados

Selecione uma versão da documentação:

Esta página descreve como usar a replicação entre centros de dados criando e trabalhando com clusters de bases de dados secundários no Kubernetes.

Para uma vista geral conceptual da replicação entre centros de dados, consulte o artigo Acerca da replicação entre centros de dados.

Antes de começar

  • Certifique-se de que tem uma conetividade de rede fiável e de baixa latência entre os centros de dados principal e secundário, o que é fundamental para que a replicação entre centros de dados funcione eficazmente.
  • Instale a versão mais recente do operador AlloyDB Omni para implementar o AlloyDB Omni num cluster do Kubernetes no centro de dados principal e num cluster do Kubernetes no centro de dados secundário. A replicação entre centros de dados é suportada na versão 1.5.0 ou superior do operador do AlloyDB Omni.
  • Crie um cluster de base de dados do AlloyDB Omni no cluster do Kubernetes no centro de dados principal.
  • Certifique-se de que os servidores de base de dados primários e de reserva no cluster de base de dados primário têm espaço de registo antecipado (WAL) adequado que possa acomodar os ficheiros WAL necessários para a replicação no cluster secundário. Todos os dados que ainda não foram replicados para o cluster secundário são armazenados no cluster principal como ficheiros WAL. Por isso, consoante a velocidade de ligação entre os clusters principal e secundário, pode precisar de espaço em disco adicional para este fim.

Crie um cluster de base de dados secundário

Para criar um cluster de base de dados secundário do AlloyDB Omni e ativar a replicação a partir do cluster de base de dados principal, siga estes passos:

Kubernetes

  1. Certifique-se de que a conetividade externa está ativada no cluster de base de dados principal do AlloyDB Omni. Se a conetividade externa não estiver ativada, adicione o seguinte à secção spec do manifesto do cluster da base de dados:

      kind: DBCluster
  spec:
   allowExternalIncomingTraffic: true

  2. Para usar a replicação entre centros de dados com um cluster de base de dados principal com alta disponibilidade (HA) ativada, confirme que o campo replayReplicationSlotsOnStandbys está ativado no cluster de base de dados principal:

    kind: DBCluster
  spec:
    availability:
      replayReplicationSlotsOnStandbys: true

    A ativação deste campo, juntamente com o logReplicationSlots explicado no passo seguinte, sincroniza o espaço de replicação usado pelo cluster da base de dados secundária com todos os standbys de HA. Esta configuração ajuda o novo servidor principal de HA a reter todos os ficheiros de registo antecipado (WAL) ainda não consumidos pelo cluster de base de dados secundário após uma comutação por falha ou uma comutação, o que lhe permite retomar a replicação sem interrupções.

  3. Para ativar a replicação no cluster da base de dados principal, aplique um manifesto semelhante ao seguinte ao cluster do Kubernetes no centro de dados principal:

    apiVersion: v1
kind: Secret
metadata:
 name: ha-rep-pw-DB_CLUSTER_NAME
type: Opaque
data:
 rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
 name: REPLICATION_NAME
spec:
 dbcluster:
   name: DB_CLUSTER_NAME
 upstream:
   password:
     name: ha-rep-pw-DB_CLUSTER_NAME
     logReplicationSlot: LOG_REPLICATION_SLOT

    Substitua o seguinte:

    • DB_CLUSTER_NAME: o nome do cluster da base de dados, por exemplo, dbc-1.
    • ENCODED_PASSWORD: a palavra-passe do utilizador da base de dados a usar para a replicação a partir de bases de dados secundárias, codificada como uma string base64, por exemplo, Q2hhbmdlTWUxMjM= for ChangeMe123. O valor predefinido é alloydbreplica.
    • REPLICATION_NAME: o nome da replicação, por exemplo, replication-1.
    • LOG_REPLICATION_SLOT: registe os dados do espaço de replicação nos ficheiros WAL. Para ativar esta opção, defina o respetivo valor como true. O valor predefinido é false.

    Recomendamos que ative a opção logReplicationSlot com o cluster da base de dados principal que tenha a alta disponibilidade (HA) ativada para garantir que a replicação pode continuar a funcionar após uma comutação por falha ou uma comutação.

    Aguarde até que o estado da replicação esteja pronto.

  4. Para obter as informações de ligação a montante usadas para configurar a replicação no cluster de base de dados secundário, execute o seguinte comando:

      kubectl get replication REPLICATION_NAME
  kubectl get replication REPLICATION_NAME -o json | jq .status.upstream

    O exemplo de resultado tem um aspeto semelhante ao seguinte:

      {
   "host": "35.230.32.36",
   "password": {
     "name": "ha-rep-pw-dbc-1"
   },
   "port": 5432,
   "replicationSlotName": "dbc_1_replication_1",
   "username": "alloydbreplica"
  }

  5. Tome nota do resultado, uma vez que precisa dele para ativar a replicação no cluster de base de dados secundário no passo seguinte.

  6. Crie um cluster do AlloyDB Omni no seu cluster do Kubernetes no centro de dados secundário com uma configuração idêntica à do cluster da base de dados principal.

  7. Certifique-se de que a conetividade externa está ativada no cluster de base de dados secundário do AlloyDB Omni.

  8. Se a conetividade externa não estiver ativada, adicione o seguinte à secção de especificações do respetivo manifesto:

     allowExternalIncomingTraffic: true

  9. Para ativar a replicação no cluster da base de dados secundária, aplique um manifesto semelhante ao seguinte ao cluster do Kubernetes no centro de dados secundário:

      apiVersion: v1
  kind: Secret
  metadata:
    name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
  type: Opaque
  data:
    rep-user-pw: "ENCODED_PASSWORD"
  ---
  apiVersion: alloydbomni.dbadmin.goog/v1
  kind: Replication
  metadata:
    name: SECONDARY_REPLICATION_NAME
  spec:
    dbcluster:
      name: SECONDARY_DB_CLUSTER_NAME
    downstream:
      host: PRIMARY_HOST
      port: PRIMARY_PORT
      username: alloydbreplica
      password:
        name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
      replicationSlotName: PRIMARY_REPLICATION_SLOT
      control: setup

    Substitua o seguinte:

    • SECONDARY_DB_CLUSTER_NAME: o nome do cluster da base de dados secundária, por exemplo, dbc-2.
    • ENCODED_PASSWORD: a palavra-passe do utilizador da base de dados a usar para a replicação do cluster da base de dados principal, codificada como uma string base64, por exemplo, Q2hhbmdlTWUxMjM= for ChangeMe123. O valor predefinido é alloydbreplica.
    • SECONDARY_REPLICATION_NAME: o nome da replicação, por exemplo, replication-2.
    • PRIMARY_HOST: o ponto final de ligação do cluster da base de dados principal a partir do resultado no passo 3 ao qual a base de dados secundária pode aceder para replicação.
    • PRIMARY_PORT: a porta de ligação do cluster da base de dados principal a partir do resultado no passo 3 a que a base de dados secundária pode aceder para replicação.
    • PRIMARY_REPLICATION_SLOT: o nome do espaço de replicação no cluster da base de dados principal a partir do resultado no passo 3 que a base de dados secundária pode usar para replicação.

Veja a replicação no cluster da base de dados secundária

Para ver informações detalhadas sobre um cluster de base de dados secundário do AlloyDB Omni e o respetivo estado de replicação, execute os seguintes comandos:

Kubernetes 

kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME

Quando o cluster da base de dados secundária é configurado com êxito e tem replicação de streaming a partir do cluster da base de dados principal, o estado de replicação está pronto e é saudável.

Promova um cluster de base de dados secundário

Antes de promover um cluster de base de dados secundário, execute os seguintes passos para verificar se o cluster de base de dados secundário aplicou todas as transações recebidas do cluster de base de dados principal:

Kubernetes

  • Verifique o estado da replicação do cluster da base de dados secundária para garantir que está pronto e em bom estado.

    kubectl get replication SECONDARY_REPLICATION_NAME

  • Interrompa todas as gravações no cluster da base de dados principal. Execute a seguinte consulta no cluster da base de dados principal para verificar o atraso de replicação da base de dados secundária. Confirme se o resultado apresenta um atraso mínimo.

    Um valor de atraso de 0 é o ideal. Se o atraso for superior a 0, ainda pode promover o cluster de base de dados secundário, com o risco de perder algumas transações recentes já confirmadas no cluster de base de dados principal.

     psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'

Para promover um cluster de base de dados secundário a um cluster de base de dados principal, atualize o campo control do manifesto de replicação do cluster de base de dados secundário para promote e aplique-o no cluster do Kubernetes no centro de dados secundário.

Kubernetes 

    apiVersion: v1
    kind: Secret
    metadata:
      name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
    type: Opaque
    data:
      rep-user-pw: "ENCODED_PASSWORD"
    ---
    apiVersion: alloydbomni.dbadmin.goog/v1
    kind: Replication
    metadata:
      name: SECONDARY_REPLICATION_NAME
    spec:
      dbcluster:
        name: SECONDARY_DB_CLUSTER_NAME
      downstream:
        host: PRIMARY_HOST
        port: PRIMARY_PORT
        username: alloydbreplica
        password:
          name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
        replicationSlotName: PRIMARY_REPLICATION_SLOT
        control: promote

Faça uma comutação

Antes de fazer a comutação, verifique se os clusters de base de dados principal e secundária pertencentes a ambos os centros de dados estão online e se os clusters de base de dados estão em bom estado.

Para garantir a consistência dos dados dos clusters de base de dados principal e secundário durante a comutação, siga estes passos para verificar se o cluster de base de dados secundário aplicou todas as transações recebidas do cluster de base de dados principal:

Kubernetes

  • Verifique o estado da replicação do cluster da base de dados secundária para garantir que está pronto e em bom estado.

    kubectl get replication SECONDARY_REPLICATION_NAME

  • Interrompa todas as gravações no cluster da base de dados principal. Execute a seguinte consulta no cluster da base de dados principal para verificar o atraso de replicação da base de dados secundária. Confirme se o resultado mostra um valor de atraso de 0.

     psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'

Para fazer uma comutação, conclua os seguintes passos:

Kubernetes

  1. Para converter o cluster de base de dados secundário do AlloyDB Omni num cluster de base de dados principal, atualize o respetivo manifesto de replicação no cluster do Kubernetes no centro de dados secundário da seguinte forma:

       apiVersion: v1
   kind: Secret
   metadata:
    name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
   type: Opaque
   data:
     rep-user-pw: "ENCODED_PASSWORD"
   ---
   apiVersion: alloydbomni.dbadmin.goog/v1
   kind: Replication
   metadata:
    name: SECONDARY_REPLICATION_NAME
   spec:
    dbcluster:
       name: SECONDARY_DB_CLUSTER_NAME
     upstream:
       password:
         name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME

    Aguarde até que o estado da replicação esteja pronto.

  2. Para obter as informações de ligação a montante para a replicação, execute o seguinte comando:

    kubectl get replication SECONDARY_REPLICATION_NAME
kubectl get replication SECONDARY_REPLICATION_NAME -o json | jq .status.upstream

    O exemplo de resultado tem um aspeto semelhante ao seguinte:

     {
   "host": "34.23.207.137",
   "password": {
     "name": "ha-rep-pw-dbc-2"
   },
   "port": 5432,
   "replicationSlotName": "dbc_2_replication_2",
   "username": "alloydbreplica"
 }

  3. Para converter o cluster de base de dados principal do AlloyDB Omni num cluster de base de dados secundário, atualize o respetivo manifesto de replicação no cluster do Kubernetes no centro de dados principal de forma semelhante ao seguinte:

        apiVersion: v1
    kind: Secret
    metadata:
     name: ha-rep-pw-DB_CLUSTER_NAME
    type: Opaque
    data:
      rep-user-pw: "ENCODED_PASSWORD"
    ---
    apiVersion: alloydbomni.dbadmin.goog/v1
    kind: Replication
    metadata:
      name: REPLICATION_NAME
    spec:
      dbcluster:
        name: DB_CLUSTER_NAME
      downstream:
        host: SECONDARY_HOST
        port: SECONDARY_PORT
        username: alloydbreplica
        password:
          name: ha-rep-pw-DB_CLUSTER_NAME
        replicationSlotName: SECONDARY_REPLICATION_SLOT
       control: rewind

    Aguarde até que o estado de replicação fique pronto e saudável.

  4. Para verificar o estado da replicação, use:

    kubectl get replication REPLICATION_NAME