Utilizzare la replica tra data center

Seleziona una versione della documentazione:

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

  • Verifica di disporre di una connessione di rete affidabile e a bassa latenza tra i data center principale e secondario, fondamentale per il funzionamento efficace della replica tra data center.
  • Installa l'ultima versione di AlloyDB Omni operator per eseguire il deployment di AlloyDB Omni su un cluster Kubernetes nel data center principale e su un cluster Kubernetes nel data center secondario. La replica tra data center è supportata in AlloyDB Omni operator versione 1.5.0 e successive.
  • Crea un cluster di database AlloyDB Omni sul cluster Kubernetes nel data center principale.
  • Assicurati che i server di database primario e di standby nel cluster di database primario dispongano di spazio adeguato per il Write-Ahead Logging (WAL) in grado di contenere i file WAL richiesti per la replica nel cluster secondario. Tutti i dati non ancora replicati nel cluster secondario vengono archiviati nel cluster primario come file WAL. A seconda della velocità di connessione tra i cluster primario e secondario, potrebbe essere necessario spazio su disco aggiuntivo per questo scopo.
  • Tieni presente le seguenti informazioni sugli standby ad alta affidabilità del database secondario (anteprima): se la versione dell'AlloyDB Omni operator e la versione dell'agente del control plane sono 1.7.0 o successive, il cluster di database secondario può supportare gli standby ad alta affidabilità (HA).

    A differenza degli standby ad alta affidabilità nel cluster di database primario, gli standby ad alta affidabilità nel cluster di database secondario sono asincroni finché il cluster di database secondario non viene promosso a database primario. Gli standby ad alta affidabilità diventano automaticamente sincroni o asincroni se il ruolo del cluster di database viene modificato durante uno switchover.

Crea un cluster di database secondario

Per creare un cluster di database secondario AlloyDB Omni e abilitare la replica dal cluster di database primario, segui questi passaggi:

  1. Verifica che la connettività esterna sia abilitata sul 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 alta affidabilità (HA) abilitata, verifica che il campo replayReplicationSlotsOnStandbys sia abilitato nel cluster di database primario:

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

    L'attivazione 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 ad alta affidabilità. Questa configurazione aiuta il nuovo database primario ad alta affidabilità a conservare i file Write-Ahead Logging (WAL) non ancora utilizzati dal cluster di database secondario dopo un failover o uno switchover, consentendo al cluster di database secondario di riprendere la replica senza interruzioni.

  3. Per abilitare la replica sul 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 degli slot di replica nei file WAL. Per attivare questa opzione, imposta il relativo valore su true. Il valore predefinito è false.

    Ti consigliamo di attivare l'opzione logReplicationSlot con un cluster di database primario con alta affidabilità (HA) abilitata per assicurarti 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 sul cluster di database secondario, esegui questo 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"
  }
  5. Prendi nota dell'output, poiché ti servirà per abilitare la replica sul cluster di database secondario nel passaggio successivo.
  6. Crea un cluster AlloyDB Omni nel tuo cluster Kubernetes nel data center secondario con una configurazione identica a quella del cluster di database primario.
  7. Verifica 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 sul 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 dal 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 4 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 4 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 4 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 questi comandi:

kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME

Quando il cluster di database secondario è configurato correttamente e ha la replica in modalità flusso dal cluster di database primario, lo stato della replica è pronto e integro.

Promuovi un cluster di database secondario

Quando promuovi un cluster di database secondario, devi prima verificare che abbia applicato tutte le transazioni ricevute dal cluster di database primario.

  1. Verifica che lo stato della replica del cluster di database secondario sia pronto e integro: 
    kubectl get replication SECONDARY_REPLICATION_NAME
  2. Interrompi tutte le scritture nel cluster di database primario. Esegui un checkpoint sul cluster di database primario, quindi esegui la seguente query sul cluster di database primario per verificare il ritardo di replica del database secondario. Verifica che il risultato mostri un ritardo minimo.
    1. Esegui un checkpoint per scaricare la memoria sul disco.
      psql -h PRIMARY_HOST -U postgres -d postgres -c 'CHECKPOINT;'
    2. Controlla il ritardo di replica. Un valore di ritardo pari a 0 è ottimale. Se il ritardo è superiore a 0, puoi comunque promuovere il cluster di database secondario. Tuttavia, esiste il rischio di perdere le transazioni recenti di cui è già stato eseguito il commit 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;'

  3. Promuovi un cluster di database secondario a cluster di database primario aggiornando il campo control del manifest di replica del cluster di database secondario a promote. Poi, applica il manifest di replica aggiornato 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

Esegui un cambio

Prima di eseguire un cambio, verifica che i cluster di database primari e secondari in entrambi i data center siano online e in stato integro.

Per mantenere la coerenza dei dati tra i cluster di database principale e secondario ed eseguire uno switchover, segui questi passaggi:

  1. Verifica che lo stato della replica del cluster di database secondario sia pronto e integro: 
    kubectl get replication SECONDARY_REPLICATION_NAME
  2. Interrompi tutte le scritture nel cluster di database primario, quindi esegui le seguenti operazioni sul cluster di database primario:
    1. Esegui un checkpoint per scaricare la memoria sul disco: 
      psql -h PRIMARY_HOST -U postgres -d postgres -c 'CHECKPOINT;'
    2. Controlla il ritardo di replica del cluster di database secondario e 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;'

  3. Per promuovere il cluster di database secondario a cluster di database primario e convertire il cluster di database primario precedente in un cluster di database secondario, segui questi passaggi:

    1. Per convertire il cluster di database secondario di AlloyDB Omni in un cluster di database primario, aggiorna il 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

      Sostituisci SECONDARY_DB_CLUSTER_NAME con il nome del cluster di database secondario, ad esempio dbc-2.

      Attendi che lo stato della replica sia pronto.

    2. Per ottenere le informazioni sulla connessione upstream per la replica, esegui questo 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"
  }

    3. Per convertire il cluster di database primario AlloyDB Omni in un cluster di database secondario, aggiorna il manifest di replica sul cluster Kubernetes nel data center primario:

      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. Verifica lo stato della replica:

      kubectl get replication REPLICATION_NAME

Esegui il ripristino di emergenza non pianificato

Se il data center principale o il cluster di database primario diventa inaspettatamente non disponibile, puoi eseguire un failover di ripristino di emergenza non pianificato. Per farlo, promuovi il cluster di database secondario, quindi riconfigura il cluster di database primario precedente dopo che torna online:

  1. Promuovi il cluster di database secondario AlloyDB Omni a cluster di database primario. Aggiorna il manifest di replica del cluster di database secondario nel cluster Kubernetes nel data center secondario, come descritto nel passaggio 3a di Esegui uno switchover.
  2. Una volta che il data center principale originale diventa disponibile, converti il cluster di database primario precedente in un cluster di database secondario che esegue la replica dal nuovo database primario. Segui i passaggi 3b, 3c e 3d descritti in Esegui un cambio, con una modifica al passaggio 3c. Nel passaggio 3c, imposta control: setup anziché control: rewind per reinizializzare il cluster dal nuovo nodo principale. Non utilizzare control: rewind perché il cluster di database primario precedente potrebbe contenere modifiche che non sono state sincronizzate prima del failover.