This page shows documentation for version 15.5.5 of AlloyDB Omni.
See the latest AlloyDB Omni documentation.

Questa pagina è stata tradotta dall'API Cloud Translation.

Utilizzare la replica tra data center

Questa pagina descrive come utilizzare la replica tra data center creando e lavorando con cluster di database secondari in Kubernetes.

Per una panoramica concettuale della replica tra data center, consulta Informazioni sulla replica tra data center.

Prima di iniziare

Installa l'operatore AlloyDB Omni versione 1.1.0 o successiva per eseguire il deployment di AlloyDB Omni su un cluster Kubernetes nel data center principale e su un cluster Kubernetes nel data center secondario.
Crea un cluster di database AlloyDB Omni sul cluster Kubernetes nel data center principale.

Crea un cluster di database secondario

Per creare un cluster di database secondario AlloyDB Omni e attivare la replica dal cluster di database principale:

Kubernetes

Assicurati che la connettività esterna sia abilitata nel cluster del database principale di AlloyDB Omni. Se la connettività esterna non è abilitata, aggiungi quanto segue alla sezione delle specifiche del manifest del cluster di database:
```
  kind: DBCluster
  spec:
   allowExternalIncomingTraffic: true
```
Per attivare la replica nel cluster del database principale, applica un manifest simile al seguente al cluster Kubernetes nel data center principale:
```
 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
```
Sostituisci quanto segue:
- DB_CLUSTER_NAME: il nome del cluster di database, ad esempio dbc-1.
- ENCODED_PASSWORD: la password dell'utente del database da utilizzare per la replica dai database secondari, codificata come stringa base64, ad esempio Q2hhbmdlTWUxMjM= for ChangeMe123. Il valore predefinito è alloydbreplica.
- REPLICATION_NAME: il nome della replica, ad esempio replication-1.
Attendi che lo stato della replica sia pronto.

Per ottenere le informazioni di connessione a monte utilizzate per configurare la replica nel cluster di database secondario, esegui il seguente comando:

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

L'output di esempio è simile al seguente:

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

Prendi nota dell'output, poiché ti servirà per attivare la replica nel cluster di database secondario nel passaggio successivo.
Crea un cluster AlloyDB Omni sul tuo cluster Kubernetes nel data center secondario con una configurazione identica a quella del cluster del database principale.
Assicurati che la connettività esterna sia abilitata nel cluster di database secondario AlloyDB Omni.
Se la connettività esterna non è abilitata, aggiungi quanto segue alla sezione delle specifiche del manifest:
```
 allowExternalIncomingTraffic: true
```
Per abilitare la replica nel cluster di database secondario, applica un manifest simile al seguente al cluster Kubernetes nel data center secondario:
```
  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
```
Sostituisci quanto segue:
- SECONDARY_DB_CLUSTER_NAME: il nome del cluster di database secondario, ad esempio dbc-2.
- ENCODED_PASSWORD: la password per l'utente del database da utilizzare per la replica del cluster del database principale, codificata come stringa base64, ad esempio Q2hhbmdlTWUxMjM= for ChangeMe123. Il valore predefinito è alloydbreplica.
- SECONDARY_REPLICATION_NAME: il nome della replica, ad esempio replication-2.
- PRIMARY_HOST: l'endpoint di connessione del cluster del database principale dall'output del passaggio 3 a cui il database secondario può accedere per la replica.
- PRIMARY_PORT: la porta di connessione del cluster del database principale dall'output del passaggio 3 a cui il database secondario può accedere per la replica.
- PRIMARY_REPLICATION_SLOT: il nome dello slot di replica nel cluster del database principale dall'output del passaggio 3 che il database secondario può utilizzare per la replica.

Visualizza la replica nel cluster di database secondario

Per visualizzare informazioni dettagliate su un cluster di database secondario AlloyDB Omni e sul relativo stato di replica, esegui i seguenti comandi:

Kubernetes

kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME

Quando il cluster di database secondario è configurato correttamente e dispone della replica in streaming dal cluster di database principale, lo stato della replica è pronto e corretto.

Promuovere un cluster di database secondario

Prima di promuovere un cluster di database secondario, svolgi i seguenti passaggi per verificare che il cluster di database secondario abbia applicato tutte le transazioni ricevute dal cluster di database principale:

Kubernetes

Controlla lo stato della replica del cluster di database secondario per assicurarti che sia pronto e integro.
```
kubectl get replication SECONDARY_REPLICATION_NAME
```
Interrompi tutte le scritture nel cluster del database principale. Esegui la seguente query sul cluster del database principale per controllare il ritardo nella replica del database secondario. Verifica che il risultato mostri un ritardo minimo.

Un valore di tempo di latenza pari a 0 è ideale. Se il ritardo è maggiore di 0, puoi comunque promuovere il cluster di database secondario, con il rischio di perdere alcune transazioni recenti già committate nel cluster di database principale.
```
 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;'
```

Per promuovere un cluster di database secondario a un cluster di database principale, aggiorna il campo control del manifest di replica del cluster di database secondario in promote e applicalo al cluster Kubernetes nel data center secondario.

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

Eseguire uno switchover

Prima di eseguire uno switchover, verifica che i cluster di database principali e secondari appartenenti a entrambi i data center siano online e in uno stato corretto.

Per garantire la coerenza dei dati dei cluster di database principali e secondari durante il passaggio, segui questi passaggi per verificare che il cluster di database secondario abbia applicato tutte le transazioni ricevute dal cluster di database principale:

Kubernetes

Controlla lo stato della replica del cluster di database secondario per assicurarti che sia pronto e integro.
```
kubectl get replication SECONDARY_REPLICATION_NAME
```
Interrompi tutte le scritture nel cluster del database principale. Esegui la seguente query sul cluster del database principale per controllare il ritardo nella replica del database secondario. Verifica che il risultato mostri un valore di tempo di latenza pari a 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;'
```

Per eseguire il passaggio, completa i seguenti passaggi:

Kubernetes

Per convertire il cluster di database secondario AlloyDB Omni in un cluster di database principale, aggiorna il relativo manifest di replica sul cluster Kubernetes nel data center secondario come segue:

   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

Attendi che lo stato della replica sia pronto.

Per ottenere le informazioni di connessione a monte per la replica, esegui il seguente comando:

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

L'output di esempio è simile al seguente:

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

Per convertire il cluster di database principale AlloyDB Omni in un cluster di database secondario, aggiorna il relativo manifest di replica sul cluster Kubernetes nel data center principale in modo simile al seguente:

    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

Attendi che lo stato della replica sia pronto e corretto.

Per verificare lo stato della replica, utilizza:
```
kubectl get replication REPLICATION_NAME
```