Gestione delle repliche di lettura

Questa pagina descrive come gestire le repliche di lettura. Queste operazioni includono la disattivazione e l'abilitazione della replica, la promozione di una replica, la configurazione della replica parallela e il controllo dello stato della replica.

Per ulteriori informazioni sul funzionamento della replica, consulta Replica in Cloud SQL.

Disabilita replica

Per impostazione predefinita, una replica viene avviata con la replica abilitata. Tuttavia, puoi disabilitare la replica, ad esempio, per eseguire il debug o analizzare lo stato di un'istanza. Quando è tutto pronto, riabiliti esplicitamente la replica. La disabilitazione o la riattivazione della replica non riavvia l'istanza di replica.

La disabilitazione della replica non arresta l'istanza di replica, che diventa un'istanza di sola lettura che non è più replicata dalla sua istanza principale. Continuerai a ricevere addebiti per l'istanza. Nella replica disabilitata, puoi riattivarla, eliminarla o promuoverla su un'istanza autonoma.

Per disabilitare la replica:

Console

  1. Nella console Google Cloud, vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Seleziona un'istanza di replica facendo clic sul nome.
  3. Fai clic su Disabilita replica nella barra dei pulsanti.
  4. Fai clic su Ok.

gcloud

gcloud sql instances patch REPLICA_NAME \
--no-enable-database-replication

REST v1

Per eseguire questo comando cURL al prompt della riga di comando, acquisisci un token di accesso utilizzando il comando gcloud auth print-access-token. Puoi anche utilizzare Explorer API nella pagina Instances:patch per inviare la richiesta API REST.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • project-id: l'ID progetto
  • replica-name: il nome dell'istanza di replica

Metodo HTTP e URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

Corpo JSON della richiesta: 

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Per eseguire questo comando cURL al prompt della riga di comando, acquisisci un token di accesso utilizzando il comando gcloud auth print-access-token. Puoi anche utilizzare Explorer API nella pagina Instances:patch per inviare la richiesta API REST.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • project-id: l'ID progetto
  • replica-name: il nome dell'istanza di replica

Metodo HTTP e URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

Corpo JSON della richiesta: 

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Abilita replica

Se una replica non è in fase di replica da molto tempo, impiegherà più tempo per raggiungere l'istanza principale. In questo caso, elimina la replica e creane una nuova.

Per abilitare la replica:

Console

  1. Nella console Google Cloud, vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Seleziona un'istanza di replica facendo clic sul nome.
  3. Fai clic su Abilita la replica.
  4. Fai clic su Ok.

gcloud

gcloud sql instances patch REPLICA_NAME \
--enable-database-replication

REST v1

Per eseguire questo comando cURL al prompt della riga di comando, acquisisci un token di accesso utilizzando il comando gcloud auth print-access-token. Puoi anche utilizzare Explorer API nella pagina Instances:patch per inviare la richiesta API REST.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • project-id: l'ID progetto
  • replica-name: il nome dell'istanza di replica

Metodo HTTP e URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

Corpo JSON della richiesta: 

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Per eseguire questo comando cURL al prompt della riga di comando, acquisisci un token di accesso utilizzando il comando gcloud auth print-access-token. Puoi anche utilizzare Explorer API nella pagina Instances:patch per inviare la richiesta API REST.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • project-id: l'ID progetto
  • replica-name: il nome dell'istanza di replica

Metodo HTTP e URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

Corpo JSON della richiesta: 

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Promuovi una replica

La promozione di una replica di lettura interrompe la replica e converte l'istanza in un'istanza principale di Cloud SQL autonoma con funzionalità di lettura e scrittura.

Se promosse, le repliche di lettura vengono configurate automaticamente con i backup, ma non vengono configurate automaticamente come istanze ad alta disponibilità (HA). Puoi abilitare l'alta disponibilità dopo aver promosso la replica, proprio come faresti per qualsiasi istanza non di replica. La configurazione di una replica di lettura per l'alta disponibilità viene eseguita come per un'istanza principale. Scopri di più sulla configurazione dell'istanza per l'alta disponibilità.

Prima di promuovere una replica di lettura, se quella principale è ancora disponibile e gestisce i client, devi:

  1. Arresta tutte le scritture nell'istanza principale.
  2. Controlla lo stato di replica della replica (segui le istruzioni nella scheda mysql Client).
  3. Verifica che la replica sia in fase di replica, quindi attendi che il ritardo di replica riportato dalla metrica Seconds_Behind_Master sia pari a 0.

In caso contrario, un'istanza appena promossa potrebbe non disporre di alcune transazioni impegnate nell'istanza principale.

Per promuovere una replica a un'istanza autonoma:

Console

  1. Nella console Google Cloud, vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Seleziona un'istanza di replica facendo clic sul nome.
  3. Fai clic su Promuovi replica.
  4. Fai clic su Ok.

gcloud

gcloud sql instances promote-replica REPLICA_NAME

REST v1

Per eseguire questo comando cURL al prompt della riga di comando, acquisisci un token di accesso utilizzando il comando gcloud auth print-access-token. Puoi anche utilizzare Explorer API nella pagina Instances:promoteReplica per inviare la richiesta API REST.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • project-id: l'ID progetto
  • replica-name: il nome dell'istanza di replica

Metodo HTTP e URL: 

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Per eseguire questo comando cURL al prompt della riga di comando, acquisisci un token di accesso utilizzando il comando gcloud auth print-access-token. Puoi anche utilizzare Explorer API nella pagina Instances:promoteReplica per inviare la richiesta API REST.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • project-id: l'ID progetto
  • replica-name: il nome dell'istanza di replica

Metodo HTTP e URL: 

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Verifica che l'istanza sponsorizzata sia configurata correttamente. In particolare, se necessario, valuta la possibilità di configurare l'istanza per l'alta disponibilità.

Configura la replica parallela

La riduzione del ritardo di replica è importante per gestire le prestazioni della replica. Il ritardo della replica si verifica quando gli aggiornamenti di una replica di lettura rimangono indietro rispetto agli aggiornamenti dell'istanza principale. Questa sezione descrive in che modo gli utenti possono abilitare la replica parallela, che può ridurre il tempo di replica.

Nella replica MySQL, viene utilizzato un thread SQL di replica per eseguire le transazioni raccolte nel log di inoltro nella replica di lettura. La replica parallela riduce il ritardo di replica aumentando il numero di thread SQL che svolgono queste transazioni. Le repliche di lettura con replica parallela abilitata a volte sono chiamate repliche multithread.

La replica parallela è disponibile nei tre scenari seguenti in Cloud SQL per MySQL:

Per semplicità, in questa pagina vengono utilizzati i termini "istanza principale" e "replica di lettura".

Passaggi di base per modificare i flag di replica parallela

Per abilitare la replica parallela, segui questi passaggi:

  1. Su una replica di lettura, disabilita la replica.
  2. Nella replica di lettura, imposta i flag per la replica parallela. Usa il comando gcloud per impostare i flag. L'opzione della console Google Cloud è disabilitata quando la replica è disabilitata.
  3. Nella replica di lettura, abilita la replica.
  4. Facoltativamente, sull'istanza principale, imposta i flag per ottimizzare le prestazioni per la replica parallela.

Repliche di lettura: flag per la replica parallela

Cloud SQL per MySQL supporta diversi flag per la replica parallela sulle repliche di lettura. Per informazioni sui flag, fai clic su questi link alla documentazione di MySQL 8.0:

La modifica di questi flag non riavvia la replica di lettura.

La seguente tabella contiene gli intervalli consentiti e i valori predefiniti per questi flag:

Flag di replica di lettura Valori consentiti Valore predefinito MySQL 5.7 Valore predefinito MySQL 8.0
slave_parallel_workers 0-1024 0 0 (MySQL 8.0.26 e versioni precedenti)
4 (MySQL 8.0.27 e versioni successive)
slave_parallel_type DATABASE, LOGICAL_CLOCK DATABASE DATABASE (MySQL 8.0.26 e versioni precedenti)
LOGICAL_CLOCK (MySQL 8.0.27 e versioni successive)
slave_preserve_commit_order ON, OFF OFF OFF (MySQL 8.0.26 e versioni precedenti)
ON (MySQL 8.0.27 e versioni successive)
slave_pending_jobs_size_max 1024-1GB 16MB 128 MB

Il flag slave_preserve_commit_order impedisce la creazione di lacune nella sequenza di transazioni eseguite dal log di inoltro della replica.

L'impostazione slave_preserve_commit_order=1 richiede quanto segue:

Il flag slave_pending_jobs_size_max imposta la memoria massima, in byte, disponibile per le code dell'applicatore che contengono eventi non ancora applicati.

Istanza principale: flag per la replica parallela

Cloud SQL per MySQL supporta diversi flag da utilizzare su un'istanza principale. Puoi utilizzare questi flag per ottimizzare le prestazioni di replica per le repliche di lettura associate con la replica parallela abilitata. Per informazioni sui flag, fai clic su questi link alla documentazione di MySQL 8.0:

La modifica di questi flag non riavvia l'istanza principale.

La seguente tabella contiene gli intervalli consentiti e i valori predefiniti per questi flag:

Flag istanza principale Valori consentiti Valore predefinito MySQL 5.7 Valore predefinito MySQL 8.0
binlog_transaction_dependency_history_size 1-1000000 25000 25000
binlog_transaction_dependency_tracking COMMIT_ORDER, WRITESET, WRITESET_SESSION COMMIT_ORDER WRITESET
transaction_write_set_extraction OFF, MURMUR32, XXHASH64 OFF XXHASH64

In MySQL 5.7, se binlog_transaction_dependency_tracking è impostato su WRITESET o WRITESET_SESSION, transaction_write_set_extraction deve essere impostato su un valore non OFF (XXHASH64 o MURMUR32).

Controlla lo stato della replica

Quando visualizzi un'istanza di replica utilizzando la console Google Cloud o accedi all'istanza utilizzando un client di amministrazione, ottieni dettagli sulla replica, tra cui stato e metriche. Quando utilizzi gcloud CLI, ottieni un breve riepilogo della configurazione della replica.

Prima di controllare lo stato della replica di un'istanza di replica Cloud SQL, utilizza il comando
gcloud sql instances describe per visualizzare lo stato dell'istanza. Di conseguenza, puoi verificare se la replica è abilitata per l'istanza di replica.

Per le istanze di replica sono disponibili le seguenti metriche. Scopri di più sulle metriche aggiuntive disponibili per tutte le istanze, incluse quelle non di replica.

MetricaDescrizione
Stato di replica
(cloudsql.googleapis.com/database/replication/state)

Indica se la replica trasmette attivamente un flusso di log dall'istanza principale alla replica. I valori possibili sono:

  • Running
  • Stopped
  • Error

Questa metrica segnala Running se i thread I/O e SQL della replica segnalano che sono in esecuzione. Per ulteriori informazioni, consulta le metriche relative allo stato di esecuzione del thread I/O slave e allo stato di esecuzione del thread SQL slave di seguito oppure consulta la sezione Controllo dello stato di replica nel Manuale di riferimento di MySQL.
Ritardo della replica
(cloudsql.googleapis.com/database/replication/replica_lag)

Il periodo di tempo in cui lo stato della replica rimane indietro rispetto allo stato dell'istanza principale. Si tratta della differenza tra (1) l'ora corrente e (2) il timestamp originale in cui l'organizzazione principale ha eseguito il commit della transazione attualmente applicata alla replica. In particolare, le scritture potrebbero essere conteggiate come in ritardo anche se sono state ricevute dalla replica, se quest'ultima non ha ancora applicato la scrittura al database.

Per le repliche a cascata, ogni coppia di replica principale viene monitorata separatamente e non esiste un'unica metrica che restituisce il ritardo end-to-end (da quello principale a quello di replica).

Questa metrica registra il valore di Seconds_Behind_Master quando SHOW SLAVE STATUS viene eseguito sulla replica. Per maggiori informazioni, consulta la sezione Verifica dello stato di replica nel Manuale di riferimento di MySQL.
Ritardo di rete
(cloudsql.googleapis.com/database/replication/network_lag)

Il tempo, in secondi, necessario dalla scrittura del binlog nel database principale per raggiungere il thread di IO nella replica.

Se il valore di network_lag è pari a zero o trascurabile, ma il valore di "replica_lag" è elevato, significa che il thread SQL non è in grado di applicare modifiche di replica abbastanza velocemente.
Stato in esecuzione del thread I/O slave
(cloudsql.googleapis.com/database/mysql/replication/slave_io_running_state)

Indica se il thread di I/O per la lettura del log binario dell'istanza principale è in esecuzione sulla replica. I valori possibili sono:

  • Yes
  • No
  • Connecting

Questa metrica segnala il valore di Slave_IO_Running quando SHOW SLAVE STATUS viene eseguito sulla replica. Per maggiori informazioni, consulta la sezione Verifica dello stato di replica nel Manuale di riferimento di MySQL.
Stato in esecuzione del thread SQL slave
(cloudsql.googleapis.com/database/mysql/replication/slave_sql_running_state)

Indica se il thread SQL per l'esecuzione di eventi nel log di inoltro è in esecuzione sulla replica. I valori possibili sono:

  • Yes
  • No
  • Connecting

Questa metrica segnala il valore di Slave_SQL_Running quando SHOW SLAVE STATUS viene eseguito sulla replica. Per maggiori informazioni, consulta la sezione Verifica dello stato di replica nel Manuale di riferimento di MySQL.

Per controllare lo stato della replica:

Console

Cloud SQL segnala le metriche Replication State e Replication Lag nella dashboard di monitoraggio predefinita di Cloud SQL.

Per visualizzare altre metriche per le repliche all'interno di una o più regioni e per le repliche di server esterni, crea una dashboard personalizzata e aggiungi le metriche che vuoi monitorare:

  1. Nella console Google Cloud, vai alla pagina Monitoring.

    Vai a Monitoring

  2. Seleziona la scheda Dashboard.
  3. Fai clic su Crea dashboard.
  4. Assegna un nome alla dashboard e fai clic su OK.
  5. Fai clic su Aggiungi grafico.
  6. In Tipo di risorsa, seleziona Database Cloud SQL.
  7. Esegui una delle seguenti operazioni:
    1. Per monitorare la metrica dello stato di replica: nel campo Seleziona una metrica, digita Replication state. Quindi, aggiungi un filtro per state = "Running". Il grafico mostra 1 se la replica è in esecuzione e 0 negli altri casi.
    2. Per monitorare la metrica del tempo di replica: nel campo Seleziona una metrica, digita replica_lag. Il grafico mostra l'intervallo di tempo in cui lo stato della replica è in ritardo rispetto a quello dell'unità principale.
    3. Per monitorare lo stato del thread I/O della replica: nel campo Seleziona una metrica, digita Slave I/O thread running state. Dopodiché, aggiungi un filtro su state = "Yes". Il grafico mostra 1 se il thread è in esecuzione e 0 negli altri casi.
    4. Per monitorare lo stato del thread SQL della replica: nel campo Seleziona una metrica, digita Slave SQL thread running state. Dopodiché, aggiungi un filtro su state = "Yes". Il grafico mostra 1 se il thread è in esecuzione e 0 negli altri casi.

gcloud

Per un'istanza di replica, controlla lo stato della replica con:

gcloud sql instances describe REPLICA_NAME

Nell'output, cerca le proprietà databaseReplicationEnabled e masterInstanceName.

Per un'istanza principale, controlla se esistono repliche con:

gcloud sql instances describe PRIMARY_INSTANCE_NAME

Cerca la proprietà replicaNames nell'output.

Client mysql

  1. Connettiti alla replica con un client MySQL.

    Per informazioni, consulta la pagina relativa alle opzioni di connessione per le applicazioni esterne.

  2. Controlla lo stato della replica: 
    SHOW SLAVE STATUS \G

    Cerca le seguenti metriche nell'output del comando:

    • Master_Host: il nome dell'istanza principale.
    • Slave_IO_Running, Slave_SQL_Running: indica se i thread I/O e SQL sono in esecuzione. Questi thread sono responsabili del trasferimento degli eventi dal log di inoltro della replica principale al log di inoltro della replica e dell'esecuzione di questi eventi dal log di inoltro. Il valore della metrica è Yes se il thread è in esecuzione. Affinché la replica sia attiva, entrambi i thread devono essere in esecuzione.
    • Seconds_Behind_Master: la quantità di tempo, in secondi, entro la quale la replica è in ritardo nell'elaborazione delle transazioni dell'istanza principale, ovvero la differenza tra (1) l'ora attuale e (2) il timestamp originale in cui l'organizzazione principale ha confermato la transazione attualmente in fase di applicazione sulla replica. Il valore è NULL se la replica viene interrotta.
    • Master_Log_file, Read_Master_Log_Pos, Relay_Master_Log_File, Exec_Master_Log_Pos: queste metriche mostrano le coordinate (nome file e offset) a cui il thread di I/O ha letto eventi fino a (Master_Log_file e Read_Master_Log_Pos) e che il thread SQL ha eseguito eventi fino a (Relay_Master_Log_File e Exec_Master_Log_Pos). Se sono uguali (ovvero Master_Log_file è uguale a Relay_Master_Log_File e Read_Master_Log_Pos è uguale a Exec_Master_Log_Pos), la replica ha elaborato tutti gli eventi ricevuti dall'istanza principale.

Per maggiori dettagli sull'output di questo comando, consulta la documentazione di MySQL sulla verifica dello stato di replica.

Risolvere i problemi

Problema Risoluzione dei problemi
La replica di lettura non ha avviato la replica al momento della creazione. È probabile che i file di log contengano un errore più specifico. Ispeziona i log in Cloud Logging per trovare l'errore effettivo.
Impossibile creare la replica di lettura: errore non validoFlagValue. Uno dei flag nella richiesta non è valido. Potrebbe essere un flag che hai fornito esplicitamente o un flag impostato su un valore predefinito.

Innanzitutto, verifica che il valore del flag max_connections sia maggiore o uguale al valore del flag principale.

Se il flag max_connections è impostato correttamente, controlla i log in Cloud Logging per trovare l'errore effettivo.
Impossibile creare la replica di lettura: errore sconosciuto. È probabile che i file di log contengano un errore più specifico. Ispeziona i log in Cloud Logging per trovare l'errore effettivo.

Se l'errore è: set Service Networking service account as servicenetworking.serviceAgent role on consumer project, disattiva e riattiva Service Networking API. Questa azione crea l'account di servizio necessario per continuare il processo.
Lo spazio sul disco è esaurito. La dimensione del disco dell'istanza principale può diventare piena durante la creazione della replica. Modifica l'istanza principale per eseguirne l'upgrade a una dimensione del disco più grande.
L'istanza di replica utilizza troppa memoria. La replica utilizza la memoria temporanea per memorizzare nella cache le operazioni di lettura più richieste, il che può portare a utilizzare più memoria rispetto all'istanza principale.

Riavvia l'istanza di replica per recuperare lo spazio di memoria temporaneo.
Replica interrotta. È stato raggiunto il limite massimo di spazio di archiviazione e l'aumento automatico dello spazio di archiviazione non è abilitato.

Modifica l'istanza per abilitare automatic storage increase.
Il ritardo della replica è costantemente elevato. Il carico di scrittura è troppo elevato per essere gestito dalla replica. Il ritardo della replica si verifica quando il thread SQL su una replica non è in grado di stare al passo con il thread di IO. Alcuni tipi di query o carichi di lavoro possono causare un ritardo di replica elevato, temporaneo o permanente, per un determinato schema. Alcune delle cause più comuni del ritardo di replica sono:
  • Query lente sulla replica. Trovale e correggile.
  • Tutte le tabelle devono avere una chiave univoca/primaria. Ogni aggiornamento in una tabella di questo tipo senza una chiave univoca/principale causa scansioni complete della tabella sulla replica.
  • Le query come DELETE ... WHERE field < 50000000 causano un ritardo di replica con la replica basata su righe, poiché un numero enorme di aggiornamenti è accumulato sulla replica.

Ecco alcune possibili soluzioni:
Il ritardo della replica aumenta improvvisamente. Ciò è causato da transazioni a lunga esecuzione. Quando viene eseguito il commit di una transazione (una istruzione singola o più istruzioni) sull'istanza di origine, l'ora di inizio della transazione viene registrata nel log binario. Quando la replica riceve questo evento binlog, confronta il timestamp con il timestamp attuale per calcolare il ritardo di replica. Di conseguenza, una transazione a lunga esecuzione sull'origine comporterebbe un ritardo di replica immediato e di grandi dimensioni sulla replica. Se il numero di modifiche alle righe nella transazione è elevato, l'esecuzione della replica impiegherà molto tempo. Nel frattempo, il ritardo di replica aumenta. Al termine della transazione della replica, il periodo di recupero dipenderà dal carico di lavoro di scrittura sull'origine e dalla velocità di elaborazione della replica.

Per evitare una transazione lunga, alcune possibili soluzioni includono:

  • Suddividi la transazione in più transazioni di piccola entità
  • Suddividi una singola query di scrittura di grandi dimensioni in batch più piccoli
  • Prova a separare le query SELECT lunghe da una transazione combinata con DML
La modifica dei flag di replica parallela genera un errore. È stato impostato un valore errato per uno o più di questi flag.

Sull'istanza principale in cui è visualizzato il messaggio di errore, imposta i flag di replica parallela:

  1. Modifica i flag binlog_transaction_dependency_tracking e transaction_write_set_extraction:
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. Aggiungi il flag slave_pending_jobs_size_max:

    slave_pending_jobs_size_max=33554432

  3. Modifica il flag transaction_write_set_extraction:

    transaction_write_set_extraction=XXHASH64

  4. Modifica il flag binlog_transaction_dependency_tracking:

    binlog_transaction_dependency_tracking=WRITESET
La creazione della replica non riesce a causa del timeout. Le transazioni non impegnate a lunga esecuzione nell'istanza principale possono causare la mancata creazione della replica di lettura.

Ricrea la replica dopo aver arrestato tutte le query in esecuzione.

Passaggi successivi