Questa pagina descrive come risolvere i problemi e correggere il ritardo di replica per le repliche di lettura Cloud SQL.
Panoramica
Le repliche di lettura di Cloud SQL utilizzano la replica basata su righe MySQL con transazione globale (GTID). Le modifiche vengono scritte nel log binario dell'istanza principale inviati alla replica, dove vengono ricevuti e applicati al database.Il ritardo della replica può verificarsi in alcuni scenari, ad esempio:
- L'istanza principale non riesce a inviare le modifiche alla replica abbastanza rapidamente.
- La replica non può ricevere le modifiche abbastanza rapidamente.
- La replica non riesce ad applicare le modifiche abbastanza rapidamente.
network_lag per monitorare i primi due scenari quando
l'istanza principale non può inviare modifiche abbastanza velocemente oppure la replica non può ricevere modifiche
abbastanza rapidamente.
Il ritardo totale viene osservato con la metrica replica_lag.
La differenza tra replica_lag e network_lag può indicare il terzo motivo per cui la replica non riesce ad applicare le modifiche di replica abbastanza rapidamente.
Queste metriche sono descritte nella sezione Monitorare il ritardo nella replica riportata di seguito.
Configurazione più rapida delle repliche
Esistono due modi per fare in modo che una replica MySQL applichi le modifiche più velocemente. Gli utenti possono configurare le proprie repliche con le seguenti opzioni:
- Replica parallela
- Svuotamento ad alte prestazioni
Replica parallela
La replica parallela potrebbe ridurre il ritardo della replica configurando la replica in modo da utilizzare più thread che agiscono in parallelo per applicare le modifiche alla replica. Per informazioni sull'uso della replica parallela, consulta Configurazione della replica parallela.
Svuotamento ad alte prestazioni
Per impostazione predefinita, Cloud SQL per MySQL esegue lo svuotamento dei log di ripristino sul disco dopo ogni transazione. Il flushing ad alte prestazioni riduce la frequenza con cui vengono svuotati i log di ripetizione a una volta al secondo sul disco, migliorando le prestazioni di scrittura.
Imposta la innodb_flush_log_at_trx_commit
sulla replica di lettura a 2. Devi anche impostare il flag sync_binlog su un
un valore più alto per l'applicazione del flag innodb_flush_log_at_trx_commit.
Per ulteriori informazioni su questo flag, consulta la sezione Suggerimenti per l'utilizzo dei flag.
Quando il flag innodb_flush_log_at_trx_commit è impostato sulla replica di lettura e Cloud SQL rileva che potrebbe essere stato registrato un arresto anomalo, Cloud SQL ricrea automaticamente la replica.
Ottimizza le query e lo schema
Questa sezione suggerisce alcune ottimizzazioni comuni di query e schemi che puoi apportare per migliorare il rendimento della replica.
Livello di isolamento delle query nella replica di lettura
I livelli di isolamento delle transazioni REPEATABLE READ e SERIALIZABLE acquisiscono blocchi che potrebbero bloccare le modifiche di replica. Valuta la possibilità di ridurre il livello di isolamento per le query nella replica. Il READ COMMITTED
livello di isolamento delle transazioni potrebbe avere un rendimento migliore.
Transazioni a lunga esecuzione nel database principale
Se un numero elevato di righe viene aggiornato in una singola transazione, può causare un improvviso picco nel numero di modifiche da applicare all'istanza principale e quindi inviato alla replica. Vale per gli aggiornamenti o le eliminazioni con istruzioni singole che interessano molte righe contemporaneamente. Le modifiche vengono inviate alla replica dopo il commit. L'applicazione di un picco improvviso di modifiche nella replica può aumentare la possibilità della contesa del blocco nella replica, se anche il carico della query alta, con conseguente ritardo della replica.
Valuta la possibilità di suddividere le transazioni di grandi dimensioni in più transazioni di minore entità.
Chiavi primarie mancanti
Le repliche di lettura di Cloud SQL utilizzano la replica basata su riga, che ha prestazioni scarse se Le tabelle MySQL replicate non hanno chiavi primarie. Consigliamo a tutti delle tabelle replicate hanno chiavi primarie.
Per MySQL 8 o versioni successive, ti consigliamo di impostare il flag
sql_require_primary_key
a ON per richiedere che le tabelle nel database abbiano chiavi primarie.
Blocchi esclusivi a causa di DDL
I comandi DDL (Data Definition Language), come ALTER TABLE e
CREATE INDEX, possono causare un ritardo nella replica a causa di bloccati esclusivi. Per evitare conflitti di blocco, valuta la possibilità di pianificare l'esecuzione di DDL
durante i periodi in cui il carico delle query sulle repliche è inferiore.
Replica sovraccaricata
Se una replica di lettura riceve troppe query, la replica potrebbe essere bloccata. Valuta la possibilità di suddividere le letture tra più repliche per ridurre il carico su ciascuna.
Per evitare picchi di query, ti consigliamo di limitare le query di lettura della replica nella logica dell'applicazione o in un livello proxy, se ne utilizzi uno.
Se si verificano picchi di attività sull'istanza principale, valuta la possibilità di estenderli aggiornamenti.
Database principale monolitico
Valuta la possibilità di eseguire lo sharding del database principale in verticale (o orizzontalmente) per evitare che una o più tabelle in ritardo rallentino tutte le altre.
Monitora il ritardo della replica
Puoi utilizzare le metriche replica_lag e network_lag per monitorare il ritardo della replica e identificare se la causa del ritardo si trova nel database principale, nella rete o nella replica.
| Metrica | Descrizione |
|---|---|
| Ritardo della replica ( cloudsql.googleapis.com) |
Il numero di secondi in cui lo stato della replica è in ritardo rispetto alla replica dell'istanza principale. Questa è la differenza tra l'ora attuale e il timestamp originale in cui il database principale ha impegnato la transazione attualmente applicata replica. In particolare, le scritture potrebbero essere conteggiate come in ritardo anche se sono state ricevute dalla replica, se la replica non ha ancora applicato la scrittura al database. Questa metrica segnala il valore di |
| Numero dell'ultimo errore del thread I/O ( cloudsql.googleapis.com) |
Indica l'ultimo errore che ha causato il fallimento del thread I/O. Se questo valore è diverso da zero,
la replica è interrotta. Si tratta di un raro, ma potrebbe succedere. Controllo
Documentazione MySQL per capire cosa indica il codice di errore. Ad esempio, i file binlog nell'istanza principale potrebbero essere stati eliminati prima che la replica li ricevesse.
In genere, Cloud SQL ricrea automaticamente la replica se la replica è interrotta.
Questa metrica |
| Numero dell'ultimo errore del thread SQL ( cloudsql.googleapis.com) |
Indica l'ultimo errore che ha causato il fallimento del thread SQL. Se il valore è diverso da zero,
la replica è interrotta. Si tratta di un raro, ma potrebbe succedere. Consulta la documentazione di MySQL per capire cosa indica il codice di errore.
Cloud SQL in genere ricrea automaticamente la replica se la replica è interrotta.
Questa metrica |
| Ritardo della rete ( cloudsql.googleapis.com) |
Il tempo, in secondi, necessario per scrivere il file binlog nel database principale fino al raggiungimento del thread IO nella replica. Se |
Verifica la replica
Per verificare che la replica funzioni, esegui la seguente istruzione su replica:
mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Queueing master event to the relay log
Master_Host: xx.xxx.xxx.xxx
Master_User: cloudsqlreplica
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.199927
Read_Master_Log_Pos: 83711956
Relay_Log_File: relay-log.000025
Relay_Log_Pos: 24214376
Relay_Master_Log_File: mysql-bin.199898
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 24214163
Relay_Log_Space: 3128686571
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
Master_SSL_CA_File: master_server_ca.pem
Master_SSL_CA_Path: /mysql/datadir
Master_SSL_Cert: replica_cert.pem
Master_SSL_Cipher:
Master_SSL_Key: replica_pkey.pem
Seconds_Behind_Master: 2627
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 321071839
Master_UUID: 437d04e9-8456-11e8-b13d-42010a80027b
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: System lock
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:52111095710-52120776390
Executed_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:1-52113039508
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
Se la replica è in corso, Slave_IO_State (prima colonna) mostra Waiting
for master to send event o un messaggio simile. Inoltre, il campo Last_IO_Error è vuoto.
Se la replica non viene eseguita, nella colonna Slave_IO_State viene visualizzato lo stato
Connecting to master e nella colonna Last_IO_Error viene visualizzato lo stato
error connecting to master cloudsqlreplica@x.x.x.x:3306.
Secondo la documentazione MySQL, altri campi interessanti relativi al ritardo di replica sono:
| Campo | Descrizione |
|---|---|
Master_Log_File |
Il nome del file di log binario di origine da cui il thread I/O sta attualmente leggendo. |
Read_Master_Log_Pos |
La posizione nel file di log binario di origine corrente fino alla quale è stato letto il thread I/O. |
Relay_Log_File |
Il nome del file di log di inoltro da cui il thread SQL sta attualmente leggendo ed eseguito. |
Relay_Log_Pos |
La posizione nel file di log di inoltro corrente fino alla quale il thread SQL ha letto ed eseguito. |
Relay_Master_Log_File |
Il nome del file di log binario di origine contenente l'evento più recente eseguito dal thread SQL. |
Nell'esempio riportato sopra, Relay_Master_Log_File ha il valore mysql-bin.199898.
Master_Log_File ha il valore mysql-bin.199927. Il suffisso numerico 199898 è
meno di 199927. Ciò significa che, anche se la replica ha ricevuto un file log mysql-bin.199927 più recente, sta ancora applicando la versione precedente di mysql-bin.199898.
In questo caso, il thread SQL presenta un ritardo nella replica.
Puoi anche connetterti al database principale ed eseguire:
SHOW MASTER STATUS;
Questo comando mostra quale file binlog viene scritto nel database principale.
Se il file di log binario del database primario è più recente di Master_Log_File nella replica,
significa che il thread di I/O è in ritardo. La replica sta ancora leggendo una data
il file di log binario del database principale.
Quando il thread di I/O è in ritardo, anche la metrica network_lag è elevata. Quando il thread SQL presenta un ritardo, ma non il thread I/O, la metrica network_lag non è elevata, ma replica_lag è elevata.
I comandi precedenti ti consentono di osservare i dettagli del ritardo
ma le metriche network_lag e replica_lag offrono un modo per
le occorrenze passate del ritardo.