Gestire l'alta disponibilità in Kubernetes

Seleziona una versione della documentazione:

Questa pagina mostra come abilitare e testare l'alta disponibilità (HA) sul cluster di database AlloyDB Omni basato su Kubernetes. L'esecuzione delle attività documentate qui richiede una conoscenza di base dell'applicazione dei file manifest Kubernetes e dell'utilizzo dello strumento a riga di comando kubectl.

Panoramica

Puoi abilitare l'alta affidabilità nel cluster di database indirizzando l'operatore AlloyDB Omni Kubernetes a creare repliche di standby dell'istanza di database principale. L'operatore AlloyDB Omni configura il cluster di database in modo da aggiornare continuamente i dati su questa replica, in modo che corrispondano a tutte le modifiche ai dati sull'istanza principale.

Abilita alta disponibilità

Prima di abilitare l'alta disponibilità nel cluster di database, assicurati che il cluster Kubernetes disponga di quanto segue:

  • Spazio di archiviazione per due copie complete dei tuoi dati
  • Risorse di computing per due istanze di database in esecuzione in parallelo

Per attivare l'alta disponibilità:

  1. Modifica il file manifest del cluster di database in modo da includere una sezione availability nella sezione spec. Questa sezione definisce il numero di standby che vuoi aggiungere impostando il parametro numberOfStandbys.

    spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS

    Sostituisci NUMBER_OF_STANDBYS con il numero di standby che vuoi aggiungere. Il valore massimo è 5. Se stai configurando l'alta affidabilità e non sai quanti standby ti servono, inizia impostando il valore su 1 o 2.

  2. Applica di nuovo il manifest.

Disabilita HA

Per disattivare l'HA:

  1. Imposta numberOfStandbys su 0 nel manifest del cluster:

    spec:
  availability:
    numberOfStandbys: 0

  2. Applica di nuovo il manifest.

Verificare l'alta disponibilità su un cluster di database

Per visualizzare lo stato HA attuale di un cluster di database, controlla la condizione HAReady dello stato del cluster. Se questo valore ha status impostato su True, allora l'alta disponibilità è configurata e funziona sul cluster di database.

Per controllare questo valore nella riga di comando, esegui questo comando:

kubectl get dbcluster.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o jsonpath={.status.conditions[?(@.type == \'HAReady\')]} -n NAMESPACE

Sostituisci quanto segue:

  • DB_CLUSTER_NAME: il nome del cluster di database.

  • NAMESPACE: lo spazio dei nomi del cluster di database.

Eseguire il failover su un'istanza di standby

Se l'istanza principale non è disponibile per un periodo di tempo configurabile, l'operatore AlloyDB Omni esegue automaticamente il failover dall'istanza del database principale all'istanza di standby. Il tempo predefinito per attivare il failover automatico è di 90 secondi.

I failover sono una buona opzione quando vuoi ripristinare rapidamente un errore imprevisto e ridurre al minimo i tempi di inattività, anche se ciò significa potenzialmente perdere una piccola quantità di dati, se il database principale non è disponibile prima che il backup venga aggiornato completamente.

AlloyDB Omni Operator supporta il failover automatico e manuale. Il failover automatico è abilitato per impostazione predefinita.

Il failover comporta la seguente sequenza di eventi:

  1. L'operatore AlloyDB Omni mette offline l'istanza del database principale.

  2. L'operatore AlloyDB Omni promuove la replica di standby a nuova istanza di database principale.

  3. L'operatore AlloyDB Omni elimina l'istanza del database principale precedente.

  4. L'operatore AlloyDB Omni crea una nuova replica di standby.

Disattivare il failover automatico

I failover automatici sono abilitati per impostazione predefinita nei cluster di database.

Per disattivare un failover:

  1. Imposta enableAutoFailover su false nel manifest del cluster:

    spec:
  availability:
    enableAutoFailover: false

Modificare le impostazioni del trigger di failover automatico

Puoi utilizzare le impostazioni per regolare i failover automatici per ogni cluster di database.

L'operatore AlloyDB Omni esegue controlli di integrità regolari ogni 30 secondi. Se un'istanza ha raggiunto la soglia di attivazione del failover automatico, l'operatore AlloyDB Omni attiva un failover automatico.

Il valore predefinito per la soglia di attivazione del failover automatico è 3. Il valore di soglia è il numero di errori consecutivi per il controllo di integrità prima che venga attivato un failover. Per modificare il valore della soglia, imposta autoFailoverTriggerThreshold su un valore intero nel manifest del cluster:

```yaml
spec:
  availability:
    autoFailoverTriggerThreshold: TRIGGER_THRESHOLD
```

Sostituisci quanto segue:

  • TRIGGER_THRESHOLD: un valore intero per il numero di errori consecutivi per il controllo di integrità prima che venga attivato un failover. Il valore predefinito è 3.

Attivare un failover manuale

Per attivare un failover manuale, crea e applica un manifest per una nuova risorsa di failover:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Failover
metadata:
  name: FAILOVER_NAME
  namespace: NAMESPACE
spec:
  dbclusterRef: DB_CLUSTER_NAME

Sostituisci quanto segue:

  • FAILOVER_NAME: un nome per questa risorsa, ad esempio failover-1.

  • NAMESPACE: lo spazio dei nomi di questa risorsa di failover, che deve corrispondere allo spazio dei nomi del cluster di database a cui si applica.

  • DB_CLUSTER_NAME: il nome del cluster di database di cui eseguire il failover.

Per monitorare il failover, esegui questo comando:

kubectl get failover FAILOVER_NAME -o jsonpath={.status.state} -n NAMESPACE

Sostituisci quanto segue:

  • FAILOVER_NAME: il nome che hai assegnato alla risorsa di failover quando l'hai creata.

  • NAMESPACE: lo spazio dei nomi del cluster di database.

Il comando restituisce Success dopo che la nuova istanza del database primario è pronta per l'uso. Per monitorare lo stato della nuova istanza di standby, consulta la sezione successiva.

Failover a un'istanza in standby

Il cambio di ruolo viene eseguito quando vuoi testare la configurazione di ripristino di emergenza o qualsiasi altra attività pianificata che richieda di invertire i ruoli del database principale e della replica di standby.

Al termine dello switchover, i ruoli dell'istanza del database principale e della replica di standby vengono invertiti insieme alla direzione della replica. Devi optare per i cambi di ruolo se vuoi un controllo migliore del processo di test della configurazione di ripristino di emergenza senza perdita di dati.

L'operatore AlloyDB Omni supporta il failover manuale.

Il cambio comporta la seguente sequenza di eventi:

  1. L'operatore AlloyDB Omni mette offline l'istanza del database principale.

  2. L'operatore AlloyDB Omni promuove la replica di standby a nuova istanza di database principale.

  3. L'operatore AlloyDB Omni converte l'istanza del database principale precedente in una replica di standby.

Eseguire un cambio

Prima di eseguire un failover, assicurati di quanto segue:

Per eseguire un failover, crea e applica un manifest per una nuova risorsa di failover:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Switchover
metadata:
    name: SWITCHOVER_NAME
spec:
     dbclusterRef: DB_CLUSTER_NAME
     newPrimary: STANDBY_REPLICA_NAME

Sostituisci quanto segue:

  • SWITCHOVER_NAME: un nome per questa risorsa di failover, ad esempio switchover-1.

  • DB_CLUSTER_NAME: il nome dell'istanza del database principale a cui si applica l'operazione di switchover.

  • STANDBY_REPLICA_NAME: il nome dell'istanza del database che vuoi promuovere come nuova istanza primaria.

    Per identificare il nome della replica di standby, esegui questo comando: posix-terminal kubectl get instances.alloydbomni.internal.dbadmin.goog

Utilizzare la replica di standby come istanza di sola lettura

Per utilizzare una replica di standby come istanza di sola lettura, completa i seguenti passaggi:

  1. Modifica il manifest del cluster di database per impostare il parametro enableStandbyAsReadReplica su true.

    spec:
  availability:
    enableStandbyAsReadReplica: true

  2. Applica di nuovo il manifest.

  3. Verifica che l'endpoint di sola lettura sia riportato nel campo status dell'oggetto DBCluster:

    kubectl describe dbcluster -n NAMESPACE DB_CLUSTER_NAME

    La seguente risposta di esempio mostra l'endpoint dell'istanza di sola lettura:

      Status:
  [...]
  Primary:
    [...]
    Endpoints:
      Name: Read-Write
      Value: 10.128.0.81:5432
      Name: Read-Only
      Value: 10.128.0.82:5432