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.

Prima di iniziare

  • Assicurati di disporre di 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 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 e successive dell'operatore AlloyDB Omni.
  • Crea un cluster di database AlloyDB Omni sul cluster Kubernetes nel data center primario.
  • Assicurati che i server di database primario e standby nel cluster di database primario dispongano di spazio di Write-Ahead Logging (WAL) sufficiente per ospitare i file WAL necessari 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, potresti aver bisogno di spazio su disco aggiuntivo a questo scopo.
  • Tieni presente le seguenti informazioni sugli standby ad alta affidabilità (HA) 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 disponibilità (HA) nel cluster di database primario, gli standby ad alta disponibilità (HA) nel cluster di database secondario sono asincroni finché il cluster di database secondario non viene promosso a database primario. Gli standby ad alta disponibilità (HA) diventano automaticamente sincroni o asincroni se il ruolo del cluster di database viene modificato durante un cambio.

Crea un cluster di database secondario

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

  1. Verifica 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 seguente, sincronizza lo slot di replica utilizzato dal cluster di database secondario con tutti gli standby ad alta disponibilità (HA). Questa configurazione consente al nuovo database primario ad alta disponibilità (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, consentendo al cluster di database secondario 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 un cluster di database primario con l'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 nel 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 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. 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 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 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 dispone della replica di streaming dal cluster di database primario, lo stato della replica è sia pronto sia integro.

Promuovi un cluster di database secondario

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

  1. Per verificare che il cluster sia pronto e integro, controlla lo stato della replica del cluster di database secondario.
    kubectl get replication SECONDARY_REPLICATION_NAME
  2. Interrompi tutte le scritture nel cluster di database primario. Esegui un checkpoint nel cluster di database primario, quindi esegui la seguente query nel cluster di database primario per controllare il ritardo della 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 della replica. Un valore di ritardo pari a 0 è ottimale. Se il ritardo è maggiore di 0, puoi comunque promuovere il cluster di database secondario. Tuttavia, esiste il rischio di perdere le 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;'

  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. Quindi, 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 primario e secondario appartenenti a entrambi i data center siano online e che i cluster di database siano in uno stato integro.

Per applicare 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:

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

    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

      Sostituisci SECONDARY_DB_CLUSTER_NAME, che è 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 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, esegui questo comando:

      kubectl get replication REPLICATION_NAME

Esegui il ripristino di emergenza non pianificato

Se si verifica un failover di RE:

  1. Per convertire il cluster di database secondario AlloyDB Omni in un cluster di database primario, aggiorna il manifest di replica del cluster nel cluster Kubernetes nel data center secondario. Per ulteriori informazioni, consulta il passaggio 3a in Esegui un cambio.
  2. Per convertire il cluster di database primario precedente in un cluster di database secondario che esegue la replica dal nuovo database primario (inversione dei ruoli), attendi che il database primario originale diventi disponibile. Utilizza il controllo rewind nella configurazione della replica downstream per determinare se la conversione funziona come previsto. Se riscontri problemi, utilizza invece il controllo setup.