Ritardo della replica

Questa pagina descrive come risolvere i problemi e correggere il ritardo di replica per le repliche di lettura Cloud SQL.

Panoramica

Il ritardo nella replica può verificarsi in alcuni scenari, ad esempio:

• L'istanza principale non riesce a inviare le modifiche alla replica abbastanza velocemente.
• La replica non può ricevere le modifiche abbastanza rapidamente.
• La replica non riesce ad applicare 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 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:

• Replicazione parallela
• Svuotamento ad alte prestazioni

Replicazione 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'utilizzo della replica parallela, consulta Configurare la 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. Lo svuotamento ad alte prestazioni riduce la frequenza con cui i log di ripetizione vengono svuotati sul disco a una volta al secondo, migliorando le prestazioni di scrittura.

Imposta il flag innodb_flush_log_at_trx_commit sulla replica di lettura su 2. Inoltre, devi impostare il flag sync_binlog su un valore superiore affinché il flag innodb_flush_log_at_trx_commit sia efficace.

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 riscontrato un arresto anomalo, Cloud SQL ricrea automaticamente la replica.

Ottimizza le query e lo schema

Questa sezione suggerisce alcune ottimizzazioni comuni di query e schema 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 in una singola transazione viene aggiornato un numero elevato di righe, puoi causare un picco improvviso nel numero di modifiche da applicare all'istanza principale e poi inviare alla replica. Questo vale per gli aggiornamenti o le eliminazioni con una singola istruzione che interessano molte righe contemporaneamente. Le modifiche vengono inviate alla replica dopo essere state committate. L'applicazione di un picco improvviso di modifiche nella replica può aumentare la possibilità di competizione per i blocchi nella replica se anche il carico delle query sulla replica è elevato, causando un ritardo nella replica.

Valuta la possibilità di suddividere le transazioni di grandi dimensioni in più transazioni più piccole.

Chiavi principali mancanti

Le repliche di lettura Cloud SQL utilizzano la replica basata su riga, che ha un rendimento scadente se le tabelle MySQL che vengono replicate non hanno chiavi principali. Ti consigliamo di avere chiavi primarie per tutte le tabelle replicate.

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 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à nell'istanza principale, valuta la possibilità di suddividere gli 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.

Monitorare 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.

Verifica la 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)

Se la replica è in corso, la prima colonna, Slave_IO_State, 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 di MySQL, alcuni altri campi interessanti relativi al ritardo nella replica includono quanto segue:

Nell'esempio precedente, 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 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 del log binario del database principale è più recente del file Master_Log_File nella replica, significa che il thread I/O è in ritardo. La replica sta ancora leggendo un file di log binario precedente dal database principale.

Quando il thread 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 mentre si verifica, ma le metriche network_lag e replica_lag ti consentono di esaminare le occorrenze passate del ritardo.

Ricrea la replica in ritardo

Ricrea una replica in ritardo quando la replica non è aggiornata da un periodo di tempo accettabile.

Con Cloud SQL, puoi configurare la replica di lettura in modo che si ricree se la replica è in ritardo (o è ritardata) oltre un periodo di tempo accettabile e il ritardo persiste per almeno cinque minuti.

Se definisci un ritardo di replica accettabile inferiore a 360 secondi (sei minuti) e un ritardo di replica di almeno 361 secondi persiste per più di cinque minuti, dopo cinque minuti l'istanza principale crea un nuovo snapshot di se stessa e la replica di lettura viene ricreata utilizzando questo snapshot.

La ricreazione di una replica di lettura in ritardo offre i seguenti vantaggi:

• Sei tu a stabilire quale sia un intervallo accettabile per il ritardo nella replica.
• Puoi ridurre il tempo necessario per la risoluzione dei problemi relativi al ritardo nella replica di ore o persino di giorni.

Si applicano ulteriori dettagli sulle funzionalità:

• Compatibile con le seguenti versioni:
  • MySQL 5.7
  • MySQL 8.0
  • MySQL 8.4
• È necessario definire un intervallo accettabile per il ritardo o il tempo di latenza della replica in secondi.
• Il valore minimo accettabile è 300 secondi o cinque minuti.
• Il valore massimo accettabile è 31.536.000 secondi o un anno.
  • Se attivi la reimpostazione della replica in ritardo per un'istanza, ma non imposti il ritardo massimo accettabile della replica, Cloud SQL utilizza il valore predefinito di un anno.
• Tipi di istanze supportati:
  • Replica in lettura
  • Replica di lettura tra regioni
  • Replica a cascata
• Il valore impostato per il campo replicationLagMaxSeconds è specifico per ogni istanza della replica. Se un'istanza principale ha più istanze di replica, puoi impostare ogni replica con un valore diverso.
• Quando viene ricreata una replica, gli utenti possono aspettarsi un certo tempo di riposo durante il completamento delle seguenti operazioni:
  • La replica è interrotta.
  • La replica viene eliminata.
  • Viene creato uno snapshot dell'istanza principale.
  • La replica viene ricreata da questo snapshot più recente. La nuova replica utilizza lo stesso nome e lo stesso indirizzo IP della replica precedente. Di conseguenza, MySQL deve essere interrotta e riavviata.
  • La nuova replica inizia a replicare i dati.
• replicationLagMaxSeconds è un campo a livello di istanza. Ogni istanza ha il suo valore.

• Se hai più repliche di lettura per la stessa istanza principale, puoi impostare un valore univoco per il campo replicationLagMaxSeconds per ogni replica.

  Definire soglie di tempo diverse per repliche diverse può aiutarti a evitare un'interruzione simultanea di tutte le repliche.

Attivare la reimpostazione della replica in ritardo

La funzionalità di ricreazione della replica in ritardo è disattivata per impostazione predefinita. Per attivarlo quando crei un'istanza, utilizza uno dei seguenti metodi:

gcloud beta sql instances create REPLICA_INSTANCE_NAME \
  --master-instance-name=PRIMARY_INSTANCE_NAME \
  --database-version=DATABASE_VERSION \
  --tier=TIER \
  --edition=EDITION \
  --region=REGION \
  --root-password=PASSWORD \
  --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS

{
  "settings": {
  "replicationLagMaxSeconds" :REPLICATION_LAG_MAX_SECONDS,
  }
  ...
}

Aggiornare il periodo di tempo per la ricreazione per il ritardo nella replica

Per visualizzare le impostazioni di un'istanza, utilizza uno dei metodi descritti in Visualizzare le informazioni di riepilogo dell'istanza.

Con queste informazioni, puoi scegliere se aggiornare o meno il periodo di tempo del ritardo nella replica specificato come accettabile prima della ricostituzione della replica.

gcloud beta sql instances patch INSTANCE_NAME \
  --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS

Limitazioni

Alla ricreazione delle repliche in ritardo si applicano le seguenti limitazioni:

• I valori per replicationLagMaxSeconds possono essere impostati solo in secondi.
• Gli indici creati sulla replica di lettura prima di un'operazione di ricreazione non verranno mantenuti. Se esiste un indice, crea un indice secondario dopo aver ricreato la replica.
• Per evitare frequenti tempi di riposo nelle repliche di lettura, le ricostruzioni sono limitate a una al giorno per istanza.
• Le repliche dei server esterni non sono supportate con questa funzionalità.
• Se attivi la ricreazione delle repliche in ritardo su una replica a cascata, Cloud SQL ricrea prima le repliche foglie per mantenere la coerenza della replica.
• La ricreazione di una replica tra regioni comporta un costo aggiuntivo.
• Non puoi attivare la ricreazione delle repliche in ritardo nella Google Cloud console.

Qual è il passaggio successivo?

• Promuovere le repliche per la migrazione a livello di area geografica o il ripristino di emergenza