- v1.12 (più recente)
- Versione 1.11
- Versione 1.10
- Elenco delle versioni supportate
- Versione 1.9
- Versione 1.8
- Versione 1.7
- Versione 1.6
- Versione 1.5
- Versione 1.4
- Versione 1.3
- Versione 1.2
- Versione 1.1
Versioni supportate:
Versioni non supportate:
In questa pagina viene descritto come recuperare o ripristinare Cassandra in più regioni.
In un deployment multiregionale, il deployment di Apigee hybrid viene eseguito in più località geografiche, in diversi data center. Se una o più regioni non riescono, ma rimangono in stato integro, puoi utilizzare una regione integro per recuperare le regioni Cassandra non riuscite con i dati più recenti.
In caso di errore catastrofico in tutte le regioni ibride, Cassandra può essere ripristinata. È importante notare che, se nel deployment sono presenti più organizzazioni Apigee, il processo di ripristino ripristina i dati per tutte le organizzazioni. In una configurazione multi-organizzazione, il ripristino solo di un'organizzazione specifica non è supportato.
Questo argomento descrive entrambi gli approcci al salvataggio delle regioni non riuscite:
- Recupero delle regioni non riuscite: descrive i passaggi per recuperare le regioni non riuscite in base a una regione integro.
- Ripristino delle regioni non riuscite: vengono descritti i passaggi per ripristinare le regioni non riuscite da un backup. Questo approccio è necessario solo se sono interessate tutte le regioni ibride.
Recupero delle regioni non riuscite
Per recuperare le regioni non riuscite da una regione integro, segui questi passaggi:
- Reindirizza il traffico API dalle regioni interessate alla regione funzionante. Pianifica la capacità di conseguenza per supportare il traffico dirottato dalle regioni in errore.
- Ritira la regione interessata. Per ogni regione interessata, segui i passaggi descritti in Rimuovere una regione ibrida. Attendi il completamento della disattivazione prima di andare al passaggio successivo.
- Ripristina la regione interessata. Per eseguire il ripristino, crea una nuova regione, come descritto in Deployment in più regioni su GKE, GKE On-Prem e AKS.
Ripristino da un backup
Il backup di Cassandra può risiedere su Cloud Storage o su un server remoto in base alla tua configurazione. Per ripristinare Cassandra da un backup, segui questi passaggi:
- Apri il file degli override per la regione che vuoi ripristinare.
- Imposta
cassandra:hostNetwork
sufalse
. - Applica il file di override:
helm upgrade datastore apigee-datastore/ \ --install \ --namespace apigee \ -f OVERRIDES_FILE
- Prima di continuare, verifica che
hostNetwork
sia impostato sufalse
:kubectl -n apigee get apigeeds -o=jsonpath='{.items[].spec.components.cassandra.hostNetwork}'
- Elimina l'ibrido dalla regione che stai ripristinando:
helm delete DATASTORE_RELEASE_NAME \ --namespace apigee
Dove DATASTORE_RELEASE_NAME è il nome della release del datastore in cui hai installato Cassandra nella regione, ad esempio
datastore-region1
. -
Ripristina la regione desiderata da un backup. Per maggiori informazioni, consulta Ripristinare una regione da un backup.
- Rimuovi i riferimenti alle regioni eliminati e aggiungi quelli ripristinati nei metadati
KeySpaces
. - Recupera il nome del data center cassandra utilizzando l'opzione
nodetool status
.kubectl exec -n apigee -it apigee-cassandra-default-0 -- bash nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status |grep -i Datacenter
dove:
- APIGEE_JMX_USER è il nome utente dell'utente delle operazioni JMX di Cassandra. Utilizzato per l'autenticazione e la comunicazione con l'interfaccia JMX di Cassandra. Consulta la pagina
cassandra:auth:jmx:username
. - APIGEE_JMX_PASSWORD è la password per l'utente delle operazioni JMX di Cassandra.
Consulta la pagina
cassandra:auth:jmx:password
.
- APIGEE_JMX_USER è il nome utente dell'utente delle operazioni JMX di Cassandra. Utilizzato per l'autenticazione e la comunicazione con l'interfaccia JMX di Cassandra. Consulta la pagina
- Aggiorna la replica di
KeySpaces
.- Crea un container client e connettiti al cluster Cassandra tramite l'interfaccia CQL.
- Ottieni l'elenco di spazi delle chiavi utente dall'interfaccia CQL:
cqlsh CASSANDRA_SEED_HOST -u APIGEE_DDL_USER -p APIGEE_DDL_PASSWORD --ssl -e "select keyspace_name from system_schema.keyspaces;"|grep -v system
dove:
- CASSANDRA_SEED_HOST è l'host seed multiregionale di Cassandra. Per la maggior parte delle installazioni multiregionali, utilizza l'indirizzo IP di un host nella prima regione. Consulta
Configurare Apigee
hybrid per più regioni e
cassandra:externalSeedHost
. - APIGEE_DDL_USER e APIGEE_DDL_PASSWORD sono il nome utente
e la password amministratore per l'utente Cassandra Data Definition Language (DDL). I valori predefiniti sono "
ddl_user
" e "iloveapis123
".Consulta
cassandra.auth.ddl.password
nel riferimento sulle proprietà di configurazione e Opzioni della riga di comando nella documentazione di Apache Cassandra cqlsh.
- CASSANDRA_SEED_HOST è l'host seed multiregionale di Cassandra. Per la maggior parte delle installazioni multiregionali, utilizza l'indirizzo IP di un host nella prima regione. Consulta
Configurare Apigee
hybrid per più regioni e
- Per ogni spazio delle chiavi, esegui questo comando dall'interfaccia CQL per aggiornare le impostazioni di replica:
ALTER KEYSPACE KEYSPACE_NAME WITH replication = {'class': 'NetworkTopologyStrategy', 'DATACENTER_NAME':3};
dove:
- KEYSPACE_NAME è il nome dello spazio delle chiavi elencato nell'output del passaggio precedente.
- DATACENTER_NAME è il nome del data center Cassandra ottenuto con
l'opzione
nodetool status
nel passaggio 8.