Gestire l'alta disponibilità in Kubernetes

Seleziona una versione della documentazione:

Questa pagina descrive come attivare e testare l'alta affidabilità (HA) sul cluster di database AlloyDB Omni basato su Kubernetes. Questo documento presuppone una conoscenza di base dell'applicazione dei file manifest di Kubernetes e dell'utilizzo dello strumento a riga di comando kubectl.

Panoramica

Per attivare l'alta affidabilità nel cluster di database, configura l'operatore AlloyDB Omni Kubernetes in modo che crei repliche in standby dell'istanza del database primario. L'operatore AlloyDB Omni configura il cluster di database in modo che aggiorni continuamente i dati su questa replica e corrisponda a tutte le modifiche ai dati nell'istanza principale.

Puoi anche abilitare l'alta affidabilità nel cluster di database abilitato per TDE. Per saperne di più sulla creazione di un cluster abilitato per TDE, consulta Crea un cluster abilitato per TDE.

Abilita alta disponibilità

Prima di abilitare l'alta affidabilità nel cluster di database, assicurati che il cluster Kubernetes abbia 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 affidabilità, segui questi passaggi:

  1. Modifica il manifest del cluster di database in modo da includere una sezione availability nella sezione spec. Questa sezione utilizza il parametro numberOfStandbys per specificare il numero di standby da aggiungere.

    spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS

    Sostituisci NUMBER_OF_STANDBYS con il numero di standby che vuoi aggiungere. Il valore massimo è 5. Se non sai con certezza il numero di standby di cui hai bisogno, inizia impostando il valore su 1 o 2.

  2. Applica nuovamente il manifest.

Disabilita HA

Per disattivare l'HA, segui questi passaggi:

  1. Imposta numberOfStandbys su 0 nel manifest del cluster:

    spec:
  availability:
    numberOfStandbys: 0

  2. Applica nuovamente il manifest.

Verifica l'alta affidabilità su un cluster di database

Per controllare lo stato dell'alta affidabilità su un cluster di database, controlla lo stato di HAReady. Se lo stato di HAReady è True, l'alta affidabilità è abilitata e funziona sul cluster. Se è False, è abilitato, ma non è pronto perché è in fase di configurazione.

Per controllare lo stato di HAReady utilizzando la riga di comando kubectl, esegui il seguente 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.

Esegui il failover a un'istanza in 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 in standby. I seguenti parametri determinano quando avviare un failover automatico:

  • Il tempo tra i controlli di integrità (il valore predefinito è 30 secondi)

  • Il numero di controlli di integrità consecutivi non riusciti (il valore predefinito è 3)

Un failover automatico viene avviato dopo il numero specificato di controlli di integrità non riusciti consecutivi, con il tempo specificato tra ogni controllo di integrità non riuscito. Se vengono mantenuti i valori predefiniti, viene eseguito un failover automatico dopo tre errori consecutivi del controllo di integrità, ciascuno a distanza di 30 secondi.

L'esecuzione di un failover manuale è una buona opzione quando vuoi riprenderti rapidamente da un errore imprevisto e ridurre al minimo i tempi di inattività.

L'operatore AlloyDB Omni supporta il failover automatico e manuale. Il failover automatico è abilitato per impostazione predefinita.

Il failover genera la seguente sequenza di eventi:

  1. L'operatore AlloyDB Omni porta l'istanza del database primario offline.

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

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

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

Disabilita il failover automatico

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

Per disattivare il failover automatico, segui questi passaggi:

  1. Imposta enableAutoFailover su false nel manifest del cluster:

    spec:
  availability:
    enableAutoFailover: false

Regola le impostazioni di attivazione del 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 sull'istanza del database primario e su tutte le repliche in standby. La frequenza predefinita per i controlli di integrità è di 30 secondi. Se un'istanza raggiunge la soglia di attivazione del failover automatico, l'operatore AlloyDB Omni attiva un failover automatico.

Il valore di soglia è il numero di errori consecutivi del controllo di integrità prima che venga attivato un failover. Per modificare il periodo del controllo di integrità o il valore di soglia, imposta i campi healthcheckPeriodSeconds e autoFailoverTriggerThreshold su valori interi nel manifest del cluster:

spec:
  availability:
    healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
    autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD

Sostituisci quanto segue:

  • HEALTHCHECK_PERIOD: un valore intero che indica il numero di secondi di attesa tra un controllo di integrità e l'altro. Il valore predefinito è 30. Il valore minimo è 4 e il valore massimo è 86400 (equivalente a 24 ore).

  • AUTOFAILOVER_TRIGGER_THRESHOLD: un valore intero per il numero di errori consecutivi del controllo di integrità prima che venga attivato un failover. Il valore predefinito è 3. Il valore minimo è 0. Non esiste un valore massimo. Se questo campo è impostato su 0, viene utilizzato il valore predefinito 3.

Attiva 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 per 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 al momento della creazione.

  • 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 in standby, consulta la sezione successiva.

Switchover a un'istanza in standby

Il cambio viene eseguito quando vuoi testare la configurazione del ripristino di emergenza o qualsiasi altra attività pianificata che richiede il cambio dei ruoli del database primario e della replica in standby.

Al termine dello switchover, la direzione della replica e i ruoli dell'istanza del database primario e della replica in standby vengono invertiti. Utilizza gli switchover per ottenere un maggiore controllo sui test della configurazione di ripristino di emergenza senza perdita di dati.

AlloyDB Omni operator supporta il cambio manuale. Un cambio di ruolo comporta la seguente sequenza di eventi:

  1. L'operatore AlloyDB Omni porta l'istanza del database primario offline.

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

  3. AlloyDB Omni operator imposta l'istanza del database primario precedente come replica in standby.

Esegui un cambio

Prima di iniziare un'operazione di switchover, segui questi passaggi:

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

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 switchover, ad esempio switchover-1.

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

  • STANDBY_REPLICA_NAME: il nome dell'istanza di database che vuoi promuovere come nuova istanza principale.

    Per identificare il nome della replica in standby, esegui questo comando:

    kubectl get instances.alloydbomni.internal.dbadmin.goog

Ripara automaticamente un'istanza in standby

Se un'istanza in standby non è disponibile, l'operatore AlloyDB Omni ripara l'istanza eliminando la replica in standby precedente e creandone una nuova che ne prende il posto. Il tempo predefinito per l'attivazione di una riparazione automatica è di 90 secondi.

La riparazione automatica del cluster di database aiuta a mantenere una replica sana e continua del database primario.

Disabilita la riparazione automatica dell'istanza

Per impostazione predefinita, la riparazione automatica di un'istanza in standby è abilitata sui cluster di database.

Per disattivare le riparazioni automatiche, segui questi passaggi:

  1. Nel manifest del cluster, imposta enableAutoHeal su false:

    spec:
  availability:
    enableAutoHeal: false

Regola le impostazioni di attivazione della riparazione automatica

Per ogni cluster di database, puoi utilizzare le impostazioni per regolare le riparazioni automatiche.

AlloyDB Omni operator esegue controlli di integrità regolari che puoi configurare. Per saperne di più, consulta Modifica le impostazioni di attivazione del failover automatico. Se una replica in standby raggiunge la soglia di attivazione della riparazione automatica, l'operatore AlloyDB Omni attiva una riparazione automatica.

Il valore di soglia è il numero di errori consecutivi del controllo di integrità prima che venga attivata una riparazione. Per modificare il valore della soglia, imposta autoHealTriggerThreshold nel manifest del cluster:

spec:
  availability:
    autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD

Sostituisci quanto segue:

  • AUTOHEAL_TRIGGER_THRESHOLD: un valore intero per il numero di errori consecutivi del controllo di integrità prima che venga attivata una riparazione. Il valore predefinito è 5. Il valore minimo è 2 a causa di possibili errori temporanei e una tantum nei controlli di integrità in standby.

Risolvi i problemi relativi alla riparazione delle istanze

Se utilizzi un numero elevato di cluster di database in un singolo cluster Kubernetes o se hai cluster di database con provisioning insufficiente, la riparazione automatica potrebbe causare l'indisponibilità dell'operatore AlloyDB Omni o dei cluster di database. Se ricevi un errore che inizia con HealthCheckProber: health check for instance failed e fa riferimento a un timeout o a un errore di connessione, prova le seguenti correzioni consigliate:

Di seguito sono riportati alcuni esempi di errori che potrebbero essere causati da un sovraccarico della riparazione automatica. Questi esempi omettono i dettagli dell'ambiente che ti aiutano a identificare l'origine dell'errore, come il nome di un cluster o un indirizzo IP.

  • HealthCheckProber: health check for instance failed" err="DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context deadline exceeded...

  • HealthCheckProber: health check for instance failed" err="rpc error: code = Code(10303) desc = DBSE0303: Healthcheck: Health check table query failed. dbdaemon/healthCheck: read healthcheck table: timeout...

  • HealthCheckProber: health check for instance failed" err="rpc error: code = Code(12415) desc = DBSE2415: Postgres: failed to connect to database. dbdaemon/healthCheck: failed to connect...

Utilizza la replica in standby come istanza di sola lettura

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

  1. Imposta enableStandbyAsReadReplica su true nel manifest del cluster di database:

    spec:
  availability:
    enableStandbyAsReadReplica: true

  2. Applica nuovamente 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

Passaggi successivi