Configura il failover per MySQL

Questa pagina spiega come configurare il failback per MySQL utilizzando la replica inversa. Il fallback si riferisce a un piano di emergenza per ripristinare il database MySQL di origine in caso di problemi con Spanner.

La replica inversa è utile quando si verificano problemi imprevisti e devi eseguire il failback al database MySQL originale con interruzioni minime del servizio. La replica inversa consente di eseguire il fallback replicando i dati scritti in Spanner nel database MySQL di origine. In questo modo, entrambi i database sono alla fine coerenti.

Il flusso di replica inversa prevede i seguenti passaggi, eseguiti dal Spanner_to_SourceDb modello Dataflow:

  1. Leggi le modifiche da Spanner utilizzando i flussi di modifiche di Spanner.

  2. Assicurati che la modalità di filtraggio sia forward_migration.

  3. Trasforma i dati Spanner in modo che siano compatibili con lo schema del database di origine utilizzando lo strumento di migrazione di Spanner. Per ulteriori informazioni, consulta Trasformazione personalizzata.

  4. Verifica se il database di origine contiene già dati più recenti per la chiave primaria specificata.

  5. Scrivi i dati nel database di origine.

Utilizza il modello Dataflow Spanner_to_SourceDb

Il modello Dataflow garantisce la coerenza a livello di chiave primaria. Il modello crea tabelle di metadati, note come tabelle shadow, in Spanner che contengono il timestamp di commit dell'ultima transazione di scrittura sullo shard per quella tabella specifica.

La scrittura è coerente fino al timestamp di commit della chiave primaria.

Puoi configurare il job Dataflow che esegue la replica inversa in una delle seguenti modalità:

  • Normale: questa è la modalità predefinita. Il job Dataflow legge gli eventi dai modifiche in tempo reale di Spanner, li converte in tipi di dati compatibili con lo schema del database di origine e li applica al database di origine. Il job ripete automaticamente i tentativi in caso di errori. Dopo aver esaurito i tentativi, sposta gli errori nella cartella severe della directory della coda di messaggi non recapitabili (DLQ) nel bucket Cloud Storage. Il job sposta anche tutti gli errori permanenti nella cartella severe.

  • RetryDLQ: in questa modalità, il job Dataflow legge gli eventi dalla cartella severe della DLQ e li riprova. Esegui questa modalità dopo aver corretto tutti gli errori permanenti. Questa modalità legge solo dalla DLQ e non dagli modifiche in tempo reale di Spanner. Se i record elaborati dalla cartella severe vengono spostati nella cartella retry, il job li riprova.

Prima di iniziare

  • Assicurati che la connettività di rete tra il database MySQL di origine e il tuo progettoGoogle Cloud , in cui verranno eseguiti i job Dataflow.

  • Aggiungi gli indirizzi IP dei worker di Dataflow alla lista consentita dell'istanza MySQL di destinazione.

  • Verifica che le credenziali MySQL siano specificate correttamente in source shards file.

  • Verifica che l'istanza MySQL sia online e in esecuzione.

  • Verifica che l'utente MySQL disponga dei privilegi INSERT, UPDATE e DELETE sul database MySQL.

  • Verifica di disporre delle autorizzazioni IAM necessarie per eseguire un modello flessibile Dataflow. Per saperne di più, vedi Crea ed esegui un modello flessibile.

  • Verifica che la porta 12345 sia aperta per la comunicazione tra le VM worker Dataflow.

Ruoli obbligatori

  • Per ottenere le autorizzazioni necessarie per avviare la replica inversa, chiedi all'amministratore di concederti i seguenti ruoli IAM sull'istanza:

  • Per assicurarti che il account di servizio Compute Engine disponga delle autorizzazioni necessarie per avviare la replica inversa, chiedi all'amministratore di concedere i seguenti ruoli IAM al account di servizio Compute Engine sull'istanza:

Esegui la replica inversa

Per eseguire la replica inversa, segui questi passaggi:

  1. Carica il file di sessione nel bucket Cloud Storage.

  2. Crea una notifica Pub/Sub per la cartella retry della directory DLQ. Puoi farlo creando un argomento Pub/Sub e una sottoscrizione Pub/Sub per quell'argomento.

  3. Crea e archivia il modello Dataflow in un'area intermedia. Per saperne di più, consulta Template di build.

  4. Esegui il modello Dataflow di replica inversa utilizzando il seguente comando Google Cloud CLI:

      gcloud dataflow flex-template run "spanner-to-sourcedb-job" \
  --project "PROJECT" \
  --region "REGION" \
  --template-file-gcs-location "TEMPLATE_SPEC_GCSPATH" \
  --parameters "changeStreamName=CHANGE_STREAM_NAME" \
  --parameters "instanceId=INSTANCE_ID" \
  --parameters "databaseId=DATABASE_ID" \
  --parameters "spannerProjectId=SPANNER_PROJECT_ID" \
  --parameters "metadataInstance=METADATA_INSTANCE" \
  --parameters "metadataDatabase=METADATA_DATABASE" \
  --parameters "sourceShardsFilePath=SOURCE_SHARDS_FILE_PATH" \
  --parameters "startTimestamp=START_TIMESTAMP" \
  --parameters "endTimestamp=END_TIMESTAMP" \
  --parameters "shadowTablePrefix=SHADOW_TABLE_PREFIX" \
  [--parameters "sessionFilePath=SESSION_FILE_PATH"] \
  [--parameters "filtrationMode=FILTRATION_MODE"] \
  [--parameters "shardingCustomJarPath=SHARDING_CUSTOM_JAR_PATH"] \
  [--parameters "shardingCustomClassName=SHARDING_CUSTOM_CLASS_NAME"] \
  [--parameters "shardingCustomParameters=SHARDING_CUSTOM_PARAMETERS"] \
  [--parameters "sourceDbTimezoneOffset=SOURCE_DB_TIMEZONE_OFFSET"] \
  [--parameters "dlqGcsPubSubSubscription=DLQ_GCS_PUB_SUB_SUBSCRIPTION"] \
  [--parameters "skipDirectoryName=SKIP_DIRECTORY_NAME"] \
  [--parameters "maxShardConnections=MAX_SHARD_CONNECTIONS"] \
  [--parameters "deadLetterQueueDirectory=DEAD_LETTER_QUEUE_DIRECTORY"] \
  [--parameters "dlqMaxRetryCount=DLQ_MAX_RETRY_COUNT"] \
  [--parameters "runMode=RUN_MODE"] \
  [--parameters "dlqRetryMinutes=DLQ_RETRY_MINUTES"] \
  [--parameters "sourceType=SOURCE_TYPE"] \
  [--parameters "transformationJarPath=TRANSFORMATION_JAR_PATH"] \
  [--parameters "transformationClassName=TRANSFORMATION_CLASS_NAME"] \
  [--parameters "transformationCustomParameters=TRANSFORMATION_CUSTOM_PARAMETERS"] \
  [--parameters "filterEventsDirectoryName=FILTER_EVENTS_DIRECTORY_NAME"]

    Le variabili obbligatorie sono descritte nel seguente elenco:

    • project: l'ID progetto Google Cloud .
    • region: la Google Cloud regione.
    • template-file-gcs-location: il percorso del file Cloud Storage in cui hai eseguito il provisioning del modello Dataflow.
    • changeStreamName: il nome dello stream di modifiche di Spanner da cui legge il job.
    • instanceId: l'ID istanza Spanner.
    • databaseId: l'ID database Spanner.
    • spannerProjectId: l'ID progetto in cui si trovano le istanze Spanner.
    • metadataInstance: l'istanza che archivia i metadati utilizzati dal connettore per controllare il consumo dei dati dell'API change stream.
    • metadataDatabase: il database che archivia i metadati che il connettore utilizza per controllare il consumo dei dati dell'API change stream.
    • sourceShardsFilePath: il percorso del file Cloud Storage che contiene le informazioni del profilo di connessione per gli shard di origine.

    Le variabili facoltative sono descritte nel seguente elenco:

    • startTimestamp: il timestamp da cui iniziare a leggere le modifiche. Il valore predefinito è vuoto.
    • endTimestamp: il timestamp fino al quale leggere le modifiche. Se non fornisci un timestamp, il processo legge le modifiche a tempo indeterminato. Il valore predefinito è vuoto.
    • shadowTablePrefix: il prefisso per la denominazione delle tabelle shadow. Il valore predefinito è shadow_.
    • sessionFilePath: il percorso del file di sessione in Cloud Storage che contiene le informazioni di mapping dello strumento di migrazione Spanner.
    • filtrationMode: la modalità che determina come filtrare i record in base ai criteri. Le modalità supportate sono none o forward_migration.
    • shardingCustomJarPath: la posizione (percorso) in Cloud Storage del file JAR personalizzato che contiene la logica per recuperare l'ID shard. Il valore predefinito è vuoto.
    • shardingCustomClassName: il nome completo della classe che ha l'implementazione dell'ID shard personalizzato. Questo campo è obbligatorio se shardingCustomJarPath è specificato. Il valore predefinito è vuoto.
    • shardingCustomParameters: una stringa contenente i parametri personalizzati da trasferire alla classe di partizionamento personalizzato. Il valore predefinito è vuoto.
    • sourceDbTimezoneOffset: l'offset del fuso orario rispetto al fuso orario UTC per il database di origine. Esempio: +10:00. Valore predefinito: +00:00.
    • dlqGcsPubSubSubscription: la sottoscrizione Pub/Sub utilizzata in una norma di notifica Cloud Storage per la directory di nuovi tentativi DLQ quando viene eseguita in modalità regular. Specifica il nome nel formato projects/<PROJECT_ID>/subscriptions/<SUBSCRIPTION_ID>. Quando imposti questo parametro, il sistema ignora deadLetterQueueDirectory e dlqRetryMinutes.
    • skipDirectoryName: la directory in cui il sistema scrive i record che salta durante la replica inversa. Valore predefinito: skip.
    • maxShardConnections: il numero massimo di connessioni consentite per shard. Valore predefinito: 10000.
    • deadLetterQueueDirectory: il percorso per l'archiviazione dell'output DLQ. Il valore predefinito è una directory nella posizione temporanea del job Dataflow.
    • dlqMaxRetryCount: il numero massimo di tentativi di ripetizione degli errori temporanei da parte del sistema tramite la coda DLQ. Valore predefinito: 500.
    • runMode: il tipo di modalità di esecuzione. Le opzioni sono regular o retryDLQ. Utilizza retryDLQ per riprovare solo i record DLQ gravi. Valore predefinito: regular.
    • dlqRetryMinutes: il numero di minuti tra i nuovi tentativi di DLQ. Valore predefinito: 10.
    • sourceType: il tipo di database di origine in cui eseguire la replica inversa. Valore predefinito: mysql.
    • transformationJarPath: la posizione (percorso) in Cloud Storage del file JAR personalizzato che contiene la logica di trasformazione personalizzata per l'elaborazione dei record nella replica inversa. Il valore predefinito è vuoto.
    • transformationClassName: il nome completo della classe che contiene la logica di trasformazione personalizzata. Questo campo è obbligatorio se transformationJarPath è specificato. Il valore predefinito è vuoto.
    • transformationCustomParameters: una stringa contenente eventuali parametri personalizzati da passare alla classe di trasformazione personalizzata. Il valore predefinito è vuoto.
    • filterEventsDirectoryName: la directory in cui il sistema scrive i record che salta durante la replica inversa. Valore predefinito: skip.

Passaggi successivi