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

  • Instale a versão 1.1.0 ou superior do operador do 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.
  • Crie um cluster de base de dados do AlloyDB Omni no cluster do Kubernetes no centro de dados principal.

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 HA ativado, certifique-se de que os servidores de base de dados principal e de reserva no cluster de base de dados principal 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. Defina o tamanho do WAL para o cluster da base de dados principal do AlloyDB Omni definindo a secção spec do manifesto do cluster da base de dados:

      kind: DBCluster
  spec:
    primarySpec:
      parameters:
        wal_keep_size: WAL_KEEP_SIZE
        max_wal_size: MAX_WAL_SIZE

    Substitua o seguinte:

    • WAL_KEEP_SIZE: o tamanho mínimo dos ficheiros WAL anteriores armazenados no diretório WAL, caso um servidor secundário precise de os obter para replicação de streaming. Se um servidor secundário ligado ao servidor principal ficar com um atraso superior a wal_keep_size megabytes, o servidor principal pode remover um segmento WAL de que o servidor secundário precisa. Neste caso, a ligação de replicação é terminada. As ligações a jusante também acabam por falhar. Defina WAL_KEEP_SIZE para um valor que suporte os requisitos da sua carga de trabalho, com base na taxa de geração de WAL, nas caraterísticas da rede de replicação e no atraso de replicação entre os clusters de base de dados primários e secundários implementados. A predefinição é 100 MB.
    • MAX_WAL_SIZE: tamanho máximo para permitir o crescimento do WAL durante as verificações automáticas da base de dados. A predefinição é 1504 MB. Este valor tem de ser definido como superior ao valor de wal_keep_size.

  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

    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.

    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