Utilizzare la replica tra data center

Seleziona una versione della documentazione:

Questa pagina descrive come utilizzare la replica tra data center creando e utilizzando cluster di database secondari in Kubernetes. Per una panoramica concettuale della replica tra data center, consulta [Informazioni sulla replica tra data center](/alloydb/omni/kubernetes/16.3.0/docs/cross-data-center-replication/about-cross-data-center-replication). ## Prima di iniziare {: #before-you-begin } - Assicurati di avere una connettività di rete affidabile e a bassa latenza tra i data center primario e secondario, che è fondamentale per il funzionamento efficace della replica tra data center. - [Installa](/alloydb/omni/kubernetes/16.3.0/docs/deploy-kubernetes) l'ultima versione dell'operatore AlloyDB Omni per eseguire il deployment di AlloyDB Omni su un cluster Kubernetes nel data center primario e su un cluster Kubernetes nel data center secondario. La replica tra data center è supportata nella versione 1.5.0 o successive dell'operatore AlloyDB Omni. - [Crea un cluster di database AlloyDB Omni](/alloydb/omni/kubernetes/16.3.0/docs/deploy-kubernetes#create) sul cluster Kubernetes nel data center primario. - Assicurati che i server di database primario e di standby nel cluster di database primario abbiano uno spazio di Write-Ahead Logging (WAL) sufficiente per ospitare i file WAL necessari per la replica nel cluster secondario. Tutti i dati che non sono ancora stati replicati nel cluster secondario vengono archiviati nel cluster primario come file WAL, quindi a seconda della velocità di connessione tra i cluster primario e secondario potrebbe essere necessario spazio su disco aggiuntivo a questo scopo. ## Creare un'istanza del cluster di database secondario {: #secondary-db-cluster-instance } Per creare un cluster di database secondario AlloyDB Omni e abilitare la replica dal cluster di database primario:

  1. Assicurati che la connettività esterna sia abilitata nel cluster di database primario AlloyDB Omni. Se la connettività esterna non è abilitata, aggiungi quanto segue alla sezione spec del manifest del cluster di database:

    ...
spec:
  ...
  allowExternalIncomingTraffic: true

  2. Per utilizzare la replica tra data center con un cluster di database primario con l'alta affidabilità (HA) abilitata, verifica che il campo replayReplicationSlotsOnStandbys sia abilitato nel cluster di database primario:

    ...
spec:
  ...
  availability:
    ...
    replayReplicationSlotsOnStandbys: true

    L'abilitazione di questo campo, insieme a logReplicationSlots spiegato nel passaggio successivo, sincronizza lo slot di replica utilizzato dal cluster di database secondario con tutti gli standby HA. Questa configurazione consente al nuovo database primario HA di conservare tutti i file di Write-Ahead Logging (WAL) non ancora utilizzati dal cluster di database secondario dopo un failover o un cambio, consentendogli di riprendere la replica senza interruzioni.

  3. Per abilitare la replica nel cluster di database primario, applica un manifest simile al seguente al cluster Kubernetes nel data center primario:

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

    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.
    • LOG_REPLICATION_SLOT: registra i dati dello slot di replica nei file WAL. Per abilitare questa opzione, imposta il valore su true. Il valore predefinito è false.

    Ti consigliamo di abilitare l'opzione logReplicationSlot con il cluster di database primario con l'alta affidabilità (HA) abilitata per garantire che la replica possa continuare a funzionare dopo un failover o un cambio.

    Attendi che lo stato della replica sia pronto.

  4. Per ottenere le informazioni sulla connessione upstream utilizzate per configurare la replica nel cluster di database secondario, esegui il comando seguente:

    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"
  }
  5. Prendi nota dell'output perché ti servirà per abilitare la replica nel cluster di database secondario nel passaggio successivo.

  6. Crea un cluster AlloyDB Omni sul cluster Kubernetes nel data center secondario con una configurazione identica a quella del cluster di database primario.

  7. Assicurati che la connettività esterna sia abilitata nel cluster di database secondario AlloyDB Omni.

  8. Se la connettività esterna non è abilitata, aggiungi quanto segue alla sezione spec del manifest:

    ...
spec:
  ...
  allowExternalIncomingTraffic: true
  9. 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
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: SECONDARY_REPLICATION_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
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 dell'utente del database da utilizzare per la replica del cluster di database primario, 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 di database primario dall'output del passaggio 3 a cui il database secondario può accedere per la replica.
    • PRIMARY_PORT: la porta di connessione del cluster di database primario 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 di database primario dall'output del passaggio 3 che il database secondario può utilizzare per la replica.

Visualizzare 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:

kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME

Quando il cluster di database secondario è stato configurato correttamente e ha la replica di streaming dal cluster di database primario, lo stato della replica è sia pronto sia integro.

Promuovere un cluster di database secondario

Prima di promuovere un cluster di database secondario, segui questi passaggi per verificare che il cluster di database secondario abbia applicato tutte le transazioni ricevute dal cluster di database primario:

  • 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 di database primario. Esegui la seguente query sul cluster di database primario per controllare il ritardo della replica del database secondario. Verifica che il risultato mostri un ritardo minimo.

    Un valore di ritardo pari a 0 è l'ideale. Se il ritardo è maggiore di 0, puoi comunque promuovere il cluster di database secondario, con il rischio di perdere alcune transazioni recenti già eseguite nel cluster di database primario.

    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 cluster di database primario, aggiorna il campo control del manifest di replica del cluster di database secondario a promote e applicalo al cluster Kubernetes nel data center secondario.

apiVersion: v1
kind: Secret
metadata:
  name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: SECONDARY_REPLICATION_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
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 un cambio

Prima di eseguire un cambio, verifica che i cluster di database primario e secondario appartenenti a entrambi i data center siano online e che i cluster di database siano in uno stato integro.

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

  • 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 di database primario. Esegui la seguente query sul cluster di database primario per controllare il ritardo della replica del database secondario. Verifica che il risultato mostri un valore di ritardo 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 un cambio:

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

    apiVersion: v1
kind: Secret
metadata:
  name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
type: Opaque
data:
  rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
  name: SECONDARY_REPLICATION_NAME
  namespace: SECONDARY_DB_CLUSTER_NAMESPACE
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.

  2. Per ottenere le informazioni sulla connessione upstream per la replica, esegui il comando seguente:

    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"
  }

  3. Per convertire il cluster di database primario AlloyDB Omni in un cluster di database secondario, aggiorna il relativo manifest di replica nel cluster Kubernetes nel data center primario 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 diventi pronto e integro.

  4. Per verificare lo stato della replica, utilizza:

    kubectl get replication REPLICATION_NAME