Questa pagina mostra la documentazione per la versione 15.7.0 di AlloyDB Omni.
Vai a Versioni della documentazione di AlloyDB Omni per scegliere una versione diversa.

Questa pagina è stata tradotta dall'API Cloud Translation.

Gestire l'alta disponibilità in Kubernetes

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

Panoramica

Attiva l'HA nel cluster di database configurando l'operatore Kubernetes AlloyDB Omni per creare repliche di standby dell'istanza di database principale. L'operatore AlloyDB Omni configura il cluster del database in modo da aggiornare continuamente i dati su questa replica e abbina tutte le modifiche ai dati nell'istanza principale.

Abilita alta disponibilità

Prima di attivare l'HA sul cluster di database, assicurati che il cluster Kubernetes abbia quanto segue:

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

Per attivare l'HA:

Modifica il file 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 prenotazioni che vuoi aggiungere. Il valore massimo è 5. Se hai dubbi sul numero di standby di cui hai bisogno, inizia impostando il valore su 1 o 2.
Applica di nuovo il manifest.

Disattivare l'alta disponibilità

Per disattivare l'HA:

Imposta numberOfStandbys su 0 nel manifest del cluster:

spec:
  availability:
    numberOfStandbys: 0

Applica di nuovo il manifest.

Verificare l'HA su un cluster di database

Per controllare lo stato dell'HA su un cluster di database, controlla lo stato HAReady. Se lo stato di HAReady è True, significa che HA è abilitato e funziona nel cluster. Se è False, significa che è abilitato, ma non è pronto perché è in corso la 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 su 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 database principale all'istanza di standby. I seguenti parametri determinano quando avviare un failover automatico:

Il tempo tra un controllo di integrità e l'altro (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 verificarsi del numero specificato di controlli di integrità consecutivi non riusciti, con l'intervallo di tempo specificato tra ogni controllo di integrità non riuscito. Se i valori predefiniti vengono mantenuti, viene eseguito un failover automatico dopo 3 errori consecutivi del controllo di integrità a distanza di 30 secondi ciascuno.

Eseguire un failover manuale è una buona opzione se vuoi recuperare rapidamente da un errore imprevisto e ridurre al minimo i tempi di inattività.

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

Il failover genera la seguente sequenza di eventi:

L'operatore AlloyDB Omni mette offline l'istanza del database principale.
L'operatore AlloyDB Omni esegue la promozione della replica di standby come nuova istanza di database principale.
L'operatore AlloyDB Omni elimina l'istanza di database principale precedente.
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:

Imposta enableAutoFailover su false nel manifest del cluster:

spec:
  availability:
    enableAutoFailover: false

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

Il valore della soglia è il numero di errori consecutivi del controllo di integrità prima dell'attivazione di un failover. Per modificare il periodo del controllo di integrità o il valore della 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 ogni controllo di integrità. Il valore predefinito è 30. Il valore minimo è 1 e il valore massimo è 86400 (equivalente a un giorno).
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.

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 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 da eseguire in caso di errore.

Per monitorare il failover, esegui il seguente comando:

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

Sostituisci quanto segue:

FAILOVER_NAME: il nome assegnato alla risorsa di failover al momento della sua creazione.
NAMESPACE: lo spazio dei nomi del cluster di database.

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

Passaggio a un'istanza in standby

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

Al termine del passaggio, la direzione della replica e i ruoli dell'istanza del database principale e della replica di standby vengono invertiti. Utilizza gli switchover per avere un maggiore controllo sul test della configurazione del piano di ripristino di emergenza senza perdita di dati.

L'operatore AlloyDB Omni supporta il passaggio manuale. Un passaggio al nuovo sistema comporta la seguente sequenza di eventi:

L'operatore AlloyDB Omni mette offline l'istanza del database principale.
L'operatore AlloyDB Omni esegue la promozione della replica di standby come nuova istanza del database principale.
L'operatore AlloyDB Omni imposta l'istanza database principale precedente come replica di standby.

Eseguire uno switchover

Prima di iniziare il passaggio, segui questi passaggi:

Verifica che sia l'istanza del database principale sia la replica di standby siano in stato corretto. Per ulteriori informazioni, consulta Gestire e monitorare AlloyDB Omni.
Verifica che lo stato attuale dell'HA sia in condizione HAReady. Per ulteriori informazioni, consulta Verificare l'HA su un cluster di database.

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

Sostituisci quanto segue:

SWITCHOVER_NAME: un nome per questa risorsa di transizione, ad esempio switchover-1.
DB_CLUSTER_NAME: il nome dell'istanza database principale a cui si applica l'operazione di switchover.
STANBDY_REPLICA_NAME: il nome dell'istanza di database che vuoi promuovere come nuova principale.

Per identificare il nome della replica di standby, esegui il seguente comando:
```
kubectl get instances.alloydbomni.internal.dbadmin.goog
```

Ripara automaticamente un'istanza di riserva

Se un'istanza di standby non è più disponibile, l'operatore AlloyDB Omni ripara l'istanza eliminando la vecchia replica di standby e creandone una nuova che la sostituisce. Il tempo predefinito per attivare un recupero automatico è di 90 secondi.

La riparazione automatica del cluster di database contribuisce a mantenere la replica sana e continua del database principale.

Disattivare la riparazione automatica dell'istanza

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

Per disattivare le correzioni automatiche:

Nel manifest del cluster, imposta enableAutoHeal su false:

spec:
  availability:
    enableAutoHeal: false

Modificare le impostazioni dell'attivatore della riparazione automatica

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

L'operatore AlloyDB Omni esegue regolari controlli di integrità che puoi configurare. Per ulteriori informazioni, consulta Modificare le impostazioni di attivazione del failover automatico. Se una replica di standby raggiunge la soglia di attivazione del ripristino automatico, l'operatore AlloyDB Omni attiva un ripristino automatico.

Il valore della soglia è il numero di errori consecutivi per il controllo di integrità prima dell'attivazione di una correzione. 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 correzione. Il valore predefinito è 3. Il valore minimo è 2 a causa di possibili errori temporanei una tantum nei controlli di integrità in standby.

Risolvere i problemi di riparazione delle istanze

Se utilizzi un numero elevato di cluster di database in un singolo cluster Kubernetes, è possibile (anche se improbabile) che la correzione automatica non riesca a gestire il carico. 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, puoi provare a mitigare l'errore nel seguente modo:

Riduci il numero di cluster di database che gestisci nel tuo cluster Kubernetes.
Aumenta il valore della soglia healthcheckPeriodSeconds in modo che i controlli di integrità si verifichino meno di frequente. Per ulteriori informazioni, consulta Modificare le impostazioni di attivazione del failover automatico.
Aumenta il limite della CPU, il limite della memoria o entrambi per l'operatore AlloyDB Omni. Per ulteriori informazioni, consulta Informazioni sulla gestione automatica della memoria e Analisi dell'utilizzo dell'heap della memoria dell'operatore AlloyDB Omni.

Di seguito sono riportati alcuni esempi di errori che potrebbero essere causati da una correzione automatica eccessiva. Questi esempi omettono i dettagli dell'ambiente che ti aiutano a identificare la fonte dell'errore, ad esempio 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...

Utilizzare la replica di standby come istanza di sola lettura

Per utilizzare una replica di standby come istanza di sola lettura:

Imposta enableStandbyAsReadReplica su true nel manifest del cluster database:
```
spec:
  availability:
    enableStandbyAsReadReplica: true
```
Applica di nuovo il manifest.

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

kubectl describe dbcluster -n NAMESPACE DB_CLUSTER_NAME

L'esempio di risposta seguente 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