Esta página mostra a documentação da versão 15.7.0 do AlloyDB Omni.
Acesse Versões da documentação do AlloyDB Omni para escolher uma versão diferente.

Esta página foi traduzida pela API Cloud Translation.

Trabalhar com a replicação entre data centers

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

Para uma visão geral conceitual da replicação entre centros de dados, consulte Sobre a replicação entre centros de dados.

Antes de começar

Instale o operador AlloyDB Omni versão 1.1.0 ou mais recente para implantar o AlloyDB Omni em um cluster do Kubernetes no data center principal e em um cluster do Kubernetes no data center secundário.
Crie um cluster de banco de dados do AlloyDB Omni no cluster do Kubernetes no data center principal.

Criar um cluster de banco de dados secundário

Para criar um cluster de banco de dados secundário do AlloyDB Omni e ativar a replicação do cluster de banco de dados principal, siga estas etapas:

Kubernetes

Verifique se a conectividade externa está ativada no cluster de banco de dados principal do AlloyDB Omni. Se a conectividade externa não estiver ativada, adicione o seguinte à seção de especificação do manifesto do cluster de banco de dados:
```
  kind: DBCluster
  spec:
   allowExternalIncomingTraffic: true
```
Para ativar a replicação no cluster de banco de dados principal, aplique um manifesto semelhante ao seguinte ao cluster do Kubernetes no data center 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:
- DB_CLUSTER_NAME: o nome do cluster de banco de dados, por exemplo, dbc-1.
- ENCODED_PASSWORD: a senha do usuário do banco de dados a ser usada para a replicação de bancos de dados secundários, codificada como uma string base64, por exemplo, Q2hhbmdlTWUxMjM= for ChangeMe123. O valor padrão é alloydbreplica.
- REPLICATION_NAME: o nome da replicação, por exemplo, replication-1.
Aguarde o status da replicação ficar pronto.

Observação: se não houver replicação ativa no slot, o status de replicação vai aparecer como pronto, mas não saudável. O status "sem integridade" é esperado quando você ainda não configurou o cluster de banco de dados secundário.

Para receber as informações de conexão upstream usadas para configurar a replicação no cluster de banco de dados secundário, execute o seguinte comando:

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

A saída de exemplo é semelhante a esta:

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

Anote a saída, porque você vai precisar dela para ativar a replicação no cluster de banco de dados secundário na próxima etapa.
Crie um cluster do AlloyDB Omni no cluster do Kubernetes no data center secundário com uma configuração idêntica ao cluster do banco de dados principal.
Verifique se a conectividade externa está ativada no cluster de banco de dados secundário do AlloyDB Omni.
Se a conectividade externa não estiver ativada, adicione o seguinte à seção de especificação do manifesto:
```
 allowExternalIncomingTraffic: true
```
Para ativar a replicação no cluster de banco de dados secundário, aplique um manifesto semelhante ao seguinte ao cluster do Kubernetes no data center 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:
- SECONDARY_DB_CLUSTER_NAME: o nome do cluster de banco de dados secundário, por exemplo, dbc-2.
- ENCODED_PASSWORD: a senha do usuário do banco de dados a ser usada para a replicação do cluster de banco de dados principal, codificada como uma string base64, por exemplo, Q2hhbmdlTWUxMjM= for ChangeMe123. O valor padrão é alloydbreplica.
- SECONDARY_REPLICATION_NAME: o nome da replicação, por exemplo, replication-2.
- PRIMARY_HOST: o endpoint de conexão do cluster de banco de dados principal da saída na etapa 3 que o banco de dados secundário pode acessar para a replicação.
- PRIMARY_PORT: a porta de conexão do cluster do banco de dados principal da saída na etapa 3 que o banco de dados secundário pode acessar para a replicação.
- PRIMARY_REPLICATION_SLOT: o nome do slot de replicação no cluster do banco de dados principal da saída na etapa 3 que o banco de dados secundário pode usar para replicação.

Conferir a replicação no cluster de banco de dados secundário

Para conferir informações detalhadas sobre um cluster de banco de dados secundário do AlloyDB Omni e o status da replicação, execute os seguintes comandos:

Kubernetes

kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME

Quando o cluster de banco de dados secundário é configurado e tem a replicação de streaming do cluster de banco de dados principal, o status da replicação está pronto e saudável.

Promover um cluster de banco de dados secundário

Antes de promover um cluster de banco de dados secundário, siga estas etapas para verificar se ele aplicou todas as transações recebidas do cluster de banco de dados primário:

Kubernetes

Verifique o status da replicação do cluster de banco de dados secundário para garantir que ele esteja pronto e seja saudável.
```
kubectl get replication SECONDARY_REPLICATION_NAME
```
Interrompa todas as gravações no cluster do banco de dados principal. Execute a consulta a seguir no cluster de banco de dados principal para verificar o atraso de replicação do banco de dados secundário. Confirme se o resultado mostra um atraso mínimo.

O valor de atraso ideal é 0. Se o atraso for maior que 0, ainda será possível promover o cluster de banco de dados secundário, mas com o risco de perder algumas transações recentes já confirmadas no cluster de banco de dados primário.
```
 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 banco de dados secundário a um cluster de banco de dados principal, atualize o campo control do manifesto de replicação do cluster de banco de dados secundário para promote e aplique isso no cluster do Kubernetes no data center 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

Realizar uma alternância

Antes de realizar uma alternância, verifique se os clusters de banco de dados primário e secundário que pertencem aos dois data centers estão on-line e em um estado saudável.

Para garantir a consistência dos dados dos clusters de banco de dados principal e secundário durante a troca, siga estas etapas para verificar se o cluster secundário aplicou todas as transações recebidas do cluster principal:

Kubernetes

Verifique o status da replicação do cluster de banco de dados secundário para garantir que ele esteja pronto e seja saudável.
```
kubectl get replication SECONDARY_REPLICATION_NAME
```
Interrompa todas as gravações no cluster do banco de dados principal. Execute a consulta a seguir no cluster de banco de dados principal para verificar o atraso de replicação do banco de dados secundário. 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 troca, siga estas etapas:

Kubernetes

Para converter o cluster de banco de dados secundário do AlloyDB Omni em um cluster de banco de dados principal, atualize o manifesto de replicação no cluster do Kubernetes no data center secundário da seguinte maneira:

   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 o status da replicação ficar pronto.

Para conferir as informações de conexão upstream da replicação, execute o seguinte comando:

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

A saída de exemplo é semelhante a esta:

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

Para converter o cluster de banco de dados principal do AlloyDB Omni em um cluster secundário, atualize o manifesto de replicação no cluster do Kubernetes no data center principal, como este:

    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 o status da replicação ficar pronto e saudável.

Para verificar o status da replicação, use:
```
kubectl get replication REPLICATION_NAME
```