Questa pagina descrive come risolvere il problema del tempo di replica per le repliche di lettura di Cloud SQL.
Panoramica
Le repliche di lettura di Cloud SQL utilizzano la replica basata su riga di MySQL con gli identificatori di transazione globali (GTID). Le modifiche vengono scritte nel log binario dell'istanza principale e inviate alla replica, dove vengono ricevute e poi applicate al database.Il ritardo della replica può verificarsi in alcuni scenari, ad esempio:
- L'istanza principale non può inviare le modifiche abbastanza rapidamente alla replica.
- La replica non può ricevere le modifiche abbastanza rapidamente.
- La replica non può applicare le modifiche abbastanza rapidamente.
network_lag per monitorare i primi due scenari in cui l'istanza principale non riesce a inviare modifiche abbastanza rapidamente o la replica non riceve le 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 può applicare le modifiche alla replica abbastanza rapidamente.
Queste metriche sono descritte nella sezione Monitorare il ritardo di replica di seguito.
Configurazione della replica più rapida
Esistono due modi per velocizzare l'applicazione delle modifiche in una replica MySQL. Gli utenti possono configurare le proprie repliche con le seguenti opzioni:
- Replica parallela
- Lavaggio ad alte prestazioni
Replica parallela
La replica parallela può contribuire al ritardo della replica configurando la replica in modo da utilizzare più thread che agiscono in parallelo per applicare modifiche alla replica. Per informazioni sull'utilizzo della replica parallela, consulta Configurare la replica parallela.
Lavaggio ad alte prestazioni
Per impostazione predefinita, Cloud SQL per MySQL svuota i log di ripetizione su disco dopo ogni transazione. Lo svuotamento ad alte prestazioni riduce a una volta al secondo la frequenza con cui i log di ripristino vengono scaricati sul disco, il che migliora le prestazioni di scrittura.
Imposta il flag innodb_flush_log_at_trx_commit sulla replica di lettura su 2. Devi inoltre impostare il flag sync_binlog su un
valore più alto affinché il flag innodb_flush_log_at_trx_commit venga applicato.
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 essersi verificato un arresto anomalo, Cloud SQL ricrea automaticamente la replica.
Ottimizza query e schema
Questa sezione suggerisce alcune ottimizzazioni comuni di query e schemi che puoi apportare per migliorare le prestazioni di 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 alla replica. Valuta la possibilità di ridurre il livello di isolamento per le query nella replica. Il livello di isolamento delle transazioni READ COMMITTED potrebbe avere un rendimento migliore.
Transazioni a lunga esecuzione nel database principale
L'aggiornamento di un numero elevato di righe in una singola transazione può causare un picco improvviso del numero di modifiche che devono essere applicate all'istanza principale e poi inviate alla replica. Questo vale per gli aggiornamenti o le eliminazioni di singole istruzioni che interessano più 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à di bloccare un conflitto nella replica se anche il carico delle query sulla replica è elevato, causando un 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, con prestazioni inadeguate se le tabelle MySQL replicate non hanno chiavi primarie. Consigliamo che tutte le tabelle replicate abbiano chiavi primarie.
Per MySQL 8 o versioni successive, ti consigliamo di impostare il flag sql_require_primary_key su ON per richiedere che le tabelle nel database abbiano chiavi primarie.
Blocchi esclusivi a causa di DDL
I comandi Data Definition Language (DDL), come ALTER TABLE e CREATE INDEX, possono causare un ritardo di replica nella replica a causa di blocchi esclusivi. Per evitare la contesa dei blocchi, ti consigliamo di pianificare l'esecuzione di DDL nei momenti in cui il carico delle query è inferiore sulle repliche.
Replica con sovraccarico
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 ognuna.
Per evitare picchi di query, valuta la possibilità di limitare le query di lettura delle repliche nella logica dell'applicazione o in un livello proxy, se ne utilizzi uno.
In caso di picchi di attività sull'istanza principale, valuta la possibilità di distribuire gli aggiornamenti.
Database primario monolitico
Valuta la possibilità di partizionare in orizzontale il database principale in verticale (o orizzontalmente) per evitare che una o più tabelle in ritardo contengano tutte le altre.
Monitora il ritardo della replica
Puoi utilizzare le metriche replica_lag e network_lag per monitorare il ritardo di replica e identificare se la causa del ritardo risiede 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 allo stato dell'istanza principale. Si tratta della differenza tra l'ora attuale e il timestamp originale in cui il database 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. Questa metrica indica il valore di |
| Numero di errore dell'ultimo thread I/O ( cloudsql.googleapis.com) |
Indica l'ultimo errore che ha causato la mancata riuscita del thread di I/O. Se il valore è diverso da zero, la replica viene interrotta. È raro, ma potrebbe succedere. Consulta la documentazione di MySQL per comprendere 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 si interrompe.
Questa metrica |
| Numero di errore dell'ultimo thread SQL ( cloudsql.googleapis.com) |
Indica l'ultimo errore che ha causato l'esito negativo del thread SQL. Se il valore è diverso da zero, la replica viene interrotta. È raro, ma potrebbe succedere. Consulta la documentazione di MySQL per comprendere cosa indica il codice di errore.
In genere Cloud SQL ricrea automaticamente la replica se la replica si interrompe.
Questa metrica |
| Tempo di rete ( cloudsql.googleapis.com) |
Il tempo, in secondi, necessario dalla scrittura del binlog nel database principale al raggiungimento del thread di IO nella replica. Se |
Verifica replica
Per verificare che la replica funzioni, esegui la seguente istruzione sulla 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)
In caso di replica, la 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, la colonna Slave_IO_State indica lo stato Connecting to master, mentre la colonna Last_IO_Error indica lo stato error connecting to master cloudsqlreplica@x.x.x.x:3306.
Secondo la documentazione MySQL, alcuni 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 di I/O sta leggendo attualmente. |
Read_Master_Log_Pos |
La posizione nel file di log binario di origine corrente fino alla lettura del thread I/O. |
Relay_Log_File |
Il nome del file di log di inoltro da cui il thread SQL sta leggendo ed eseguendo attualmente. |
Relay_Log_Pos |
La posizione nel file di log di inoltro corrente fino a cui 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 sopra, Relay_Master_Log_File ha il valore mysql-bin.199898.
Master_Log_File ha il valore mysql-bin.199927. Il suffisso numerico 199898 è inferiore a 199927. Ciò significa che, anche se la replica ha ricevuto un file di log mysql-bin.199927 più recente, continua ad applicare il precedente mysql-bin.199898.
In questo caso, il thread SQL è in 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 principale è più recente del Master_Log_File nella replica, significa che il thread di I/O è in ritardo. La replica sta ancora leggendo un file di log binario meno recente dal database principale.
Quando il thread I/O è in ritardo, anche la metrica network_lag è alta. Quando il thread SQL
è in ritardo, ma il thread I/O non lo è, la metrica network_lag non è così elevata, mentre replica_lag è alto.
I comandi precedenti ti consentono di osservare i dettagli del ritardo mentre si verifica,
ma le metriche network_lag e replica_lag ti consentono di
individuare le occorrenze passate di questo ritardo.