Ritardo della replica

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 Cloud SQL utilizzano la replica basata su riga di MySQL utilizzando gli identificatori di transazione globale (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 riesce a inviare le modifiche alla replica abbastanza velocemente.
  • La replica non riesce a ricevere le modifiche abbastanza rapidamente.
  • La replica non riesce ad applicare le modifiche abbastanza rapidamente.
Utilizza la metrica network_lag per monitorare i primi due scenari quando l'istanza principale non riesce a inviare le modifiche abbastanza velocemente o la replica non riesce a riceverle 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 di replica abbastanza rapidamente. Queste metriche sono descritte nella sezione Monitorare il ritardo di replica di seguito.

Configurazione più rapida della replica

Esistono due modi per fare in modo che una replica MySQL applichi le modifiche più rapidamente. Gli utenti possono configurare le repliche con le seguenti opzioni:

  • Replica parallela
  • Scarico ad alte prestazioni

Replica parallela

La replica parallela può contribuire a ridurre il ritardo della replica configurando la replica in modo che utilizzi più thread che agiscono in parallelo per applicare le modifiche alla replica. Per informazioni sull'utilizzo della replica parallela, consulta Configurazione della replica parallela.

Quando abiliti la replica parallela impostando il flag replica_parallel_workers (o slave_parallel_workers), tieni presente quanto segue:

  • Ti consigliamo di impostare il valore del flag replica_parallel_workers su un numero che corrisponda al conteggio delle vCPU dell'istanza di replica. L'impostazione di un valore molto alto può causare attese per blocchi, timeout di attesa per blocchi e deadlock. Se osservi picchi di attesa dei blocchi in linea con il ritardo di replica, valuta la possibilità di ridurre il parallelismo.
  • Se la tua versione di MySQL supporta il flag binlog_transaction_dependency_tracking, valuta la possibilità di impostarlo su WRITESET per l'istanza principale. Questo è il comportamento predefinito per la versione 8.4 e successive.

Scarico ad alte prestazioni

Per impostazione predefinita, Cloud SQL per MySQL scarica i log di ripristino su disco dopo ogni transazione per garantire la durabilità. Lo scaricamento ad alte prestazioni riduce la frequenza con cui i log di ripristino vengono scaricati sul disco a una volta al secondo. In questo modo, puoi migliorare le prestazioni di scrittura sulla replica riducendo l'I/O del disco.

Imposta il flag innodb_flush_log_at_trx_commit sulla replica di lettura su 2. Se la registrazione binaria è attivata per la replica, per rendere efficace il flag innodb_flush_log_at_trx_commit, ti consigliamo di impostare il flag sync_binlog su un valore elevato, ad esempio 10.000.

Per saperne di più su questo flag, consulta 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.

Assicurati che la replica sia sottoposta a provisioning adeguato

Un'istanza di replica più piccola dell'istanza principale (ad esempio, con meno vCPU e memoria) può subire un ritardo nella replica. Una replica più piccola potrebbe avere anche flag di configurazione predefiniti diversi rispetto a un'istanza primaria più grande. Ti consigliamo di creare un'istanza di replica almeno delle stesse dimensioni dell'istanza primaria per avere risorse sufficienti a gestire il carico di replica.

Un utilizzo elevato della CPU sulla replica può anche causare un ritardo della replica. Se l'utilizzo della CPU della replica è elevato (ad esempio, superiore al 90%), valuta la possibilità di aumentare la capacità della CPU della replica.

Puoi utilizzare il comando SHOW VARIABLES per visualizzare la configurazione della replica e dell'istanza primaria e confrontarle per individuare le differenze. Ad esempio, una replica più piccola non può configurare innodb_buffer_pool_size con lo stesso valore della replica primaria e ciò potrebbe influire sul rendimento della replica.

Ottimizzare le query e lo schema

Questa sezione suggerisce alcune ottimizzazioni comuni di query e schemi che puoi apportare per migliorare le prestazioni 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 impedire le modifiche di 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

Le transazioni a esecuzione prolungata sull'istanza principale possono causare un ritardo della replica. Il log binario non viene inviato alla replica finché la transazione non viene eseguita.

Se un numero elevato di righe viene aggiornato in una singola transazione, può causare un picco improvviso nel numero di modifiche che devono essere applicate all'istanza principale e poi inviate alla replica. Ciò vale per aggiornamenti o eliminazioni di singole istruzioni 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à di contesa dei blocchi nella replica se anche il carico di query nella replica è elevato, causando un ritardo nella replica.

Valuta la possibilità di suddividere le transazioni di grandi dimensioni in più transazioni più piccole. Puoi monitorare le transazioni a lunga esecuzione controllando la metrica cloudsql.googleapis.com/database/mysql/innodb/active_trx_longest_time sul server primario.

Chiavi primarie mancanti

Le repliche di lettura Cloud SQL utilizzano la replica basata su riga, che ha un rendimento scarso se le tabelle MySQL replicate non hanno chiavi primarie. Ti consigliamo di assicurarti 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 del database abbiano chiavi primarie.

Transazioni a lunga esecuzione nella replica di lettura

Le transazioni a esecuzione prolungata sulla replica, come le istruzioni SELECT, possono bloccare o rallentare la replica. La scansione della tabella è un problema comune. Esamina le query a esecuzione prolungata e valuta la possibilità di ottimizzarle. Queste query possono portare a un aumento delle dimensioni dell'elenco della cronologia di InnoDB.

Lunghezza della cronologia InnoDB eccessiva

Un elenco della cronologia InnoDB molto lungo può causare problemi di prestazioni e rallentare la replica. Puoi monitorare la lunghezza dell'elenco della cronologia utilizzando la metrica cloudsql.googleapis.com/database/mysql/innodb/history_list_length. Questa metrica può essere elevata anche nella risorsa principale e potrebbe già causare problemi di rendimento. Se, dopo l'avvio iniziale, la replica mostra segni di un ritardo elevato, questo potrebbe essere il motivo.

Un elenco della cronologia di grandi dimensioni può essere causato da quanto segue:

  • Transazioni a lunga esecuzione. Le transazioni a lunga esecuzione o inattive impediscono l'eliminazione definitiva delle vecchie voci del log di annullamento.
  • Prestazioni lente del disco. L'eliminazione è un'operazione che richiede un'elevata intensità di I/O.
  • Livello di isolamento REPEATABLE READ. Ciò può contribuire alla crescita dell'elenco della cronologia.
  • Configurazione di eliminazione insufficiente.Il parametro innodb_purge_threads, che controlla il numero di thread dedicati all'eliminazione, potrebbe essere impostato su un valore troppo basso per il workload.

Per risolvere il problema, prova a svolgere questi passaggi:

  • Suddividi le transazioni di grandi dimensioni in transazioni più piccole. Consentire l'eliminazione più rapida dei log meno recenti.
  • Utilizza un'istanza più grande. Le istanze più grandi hanno più CPU e memoria.
  • Regola le impostazioni di eliminazione delle tracce. Aumenta innodb_purge_threads, innodb_io_capacity e innodb_io_capacity_max.
  • Utilizza il livello di isolamento READ COMMITTED.
  • Assicurati che le tabelle abbiano chiavi primarie. Le tabelle senza chiavi primarie possono causare scansioni delle tabelle, che possono rallentare la replica e contribuire alla crescita dell'elenco della cronologia.

Elevato numero di attese di blocco

Un numero elevato di attese di blocco sulla replica può rallentare la replica, soprattutto se è abilitata la replica parallela. Puoi monitorare le attese di blocco e i deadlock utilizzando le seguenti metriche:

  • cloudsql.googleapis.com/database/mysql/innodb/row_lock_waits_count
  • cloudsql.googleapis.com/database/mysql/innodb/row_lock_time
  • cloudsql.googleapis.com/database/mysql/innodb/lock_timeout_count
  • cloudsql.googleapis.com/database/mysql/innodb/deadlocks_count

Se queste metriche di blocco sono troppo elevate e sembrano correlate al ritardo di replica, valuta la possibilità di ridurre il valore del flag replica_parallel_workers. Anche il livello di isolamento potrebbe influire sulle chiusure.

Blocchi esclusivi dovuti al DDL

I comandi Data Definition Language (DDL), come ALTER TABLE e CREATE INDEX, possono causare un ritardo della replica nella replica a causa di blocchi esclusivi. Per evitare conflitti di blocco, valuta la possibilità di pianificare l'esecuzione di DDL durante i periodi in cui il carico di query è inferiore sulle repliche.

Valuta la possibilità di utilizzare la funzionalità DDL online di MySQL 8.0.

Replica sovraccarica

Se una replica di lettura riceve troppe query, la replica potrebbe essere bloccata. Valuta la possibilità di dividere le letture tra più repliche per ridurre il carico su ciascuna.

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.

Se si verificano picchi di attività nell'istanza principale, valuta la possibilità di distribuire gli aggiornamenti.

Database primario monolitico

Valuta la possibilità di partizionare verticalmente (o orizzontalmente) il database principale per evitare che una o più tabelle in ritardo blocchino tutte le altre.

Monitorare 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 si trova nel database principale, nella rete o nella replica.

MetricaDescrizione
Ritardo della replica
(cloudsql.googleapis.com/database/replication/replica_lag)

Il numero di secondi di ritardo dello stato della replica 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 in fase di applicazione sulla 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 riporta il valore di Seconds_Behind_Master quando SHOW SLAVE STATUS viene eseguito sulla replica. Per ulteriori informazioni, consulta Controllo dello stato della replica nel manuale di riferimento di MySQL.
Numero dell'ultimo errore del thread I/O
(cloudsql.googleapis.com/database/mysql/replication/last_io_errno)

Indica l'ultimo errore che ha causato l'interruzione del thread I/O. Se questo valore è diverso da zero, la replica è interrotta. È un caso raro, ma può capitare. Consulta la documentazione di MySQL per capire cosa indica il codice di errore. Ad esempio, i file binlog nell'istanza primaria potrebbero essere stati eliminati prima che la replica li ricevesse. Cloud SQL di solito ricrea automaticamente la replica se la replica è interrotta. Questa metrica last_io_errno potrebbe indicarti il motivo.

Ultimo numero di errore del thread SQL
(cloudsql.googleapis.com/database/mysql/replication/last_sql_errno)

Indica l'ultimo errore che ha causato l'interruzione del thread SQL. Se questo valore è diverso da zero, la replica è interrotta. È un caso raro, ma può capitare. Consulta la documentazione di MySQL per capire cosa indica il codice di errore. Cloud SQL di solito ricrea automaticamente la replica se la replica è interrotta. Questa metrica last_sql_errno può indicarti il motivo.

Ritardo di rete
(cloudsql.googleapis.com/database/replication/network_lag)

Il tempo, in secondi, necessario per scrivere il binlog nel database primario e raggiungere il thread I/O nella replica.

Se network_lag è zero o trascurabile, ma replica_lag è elevato, significa che il thread SQL non è in grado di applicare le modifiche di replica abbastanza rapidamente.

Verifica la replica

Per verificare che la replica funzioni, esegui questa 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, la colonna Slave_IO_State mostra lo stato Connecting to master e la colonna Last_IO_Error mostra lo stato error connecting to master cloudsqlreplica@x.x.x.x:3306.

Secondo la documentazione di MySQL, alcuni altri campi interessanti relativi al ritardo di replica includono i seguenti:

CampoDescrizione
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 relay da cui il thread SQL sta attualmente leggendo ed eseguendo.
Relay_Log_Pos
 La posizione nel file di log di relay corrente che 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 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 di log mysql-bin.199927 più recente, sta ancora applicando il mysql-bin.199898 precedente.

In questo caso, il thread SQL è in ritardo nella replica.

Puoi anche connetterti al database principale ed eseguire:

  SHOW MASTER STATUS;

Questo comando mostra il file binlog in cui vengono scritti i dati nel database primario.

Se il file di log binario del database principale è più recente di 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 è in ritardo, ma il thread I/O non lo è, la metrica network_lag non è elevata, ma la metrica replica_lag è elevata.

I comandi precedenti consentono di osservare i dettagli del ritardo mentre si verifica, ma le metriche network_lag e replica_lag offrono un modo per esaminare le occorrenze passate del ritardo.

Ricrea replica in ritardo

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

Con Cloud SQL, puoi configurare la replica di lettura in modo che si ricrei se la replica è in ritardo 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 (6 minuti) e un ritardo di replica di almeno 361 secondi persiste per più di 5 minuti, dopo 5 minuti l'istanza primaria 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:

  • Controlli ciò che viene considerato un intervallo accettabile per il ritardo di replica.
  • Puoi ridurre il tempo dedicato alla risoluzione dei problemi relativi al ritardo di replica di ore o addirittura 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 di replica in secondi.
  • Il valore minimo accettabile è 300 secondi o 5 minuti.
  • Il valore massimo accettabile è 31.536.000 secondi o un anno.
    • Se attivi la ricreazione della replica in ritardo per un'istanza, ma non imposti il ritardo di replica massimo accettabile, 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 di replica. Se un'istanza primaria ha più istanze di replica, puoi impostare ogni replica con un valore diverso.
  • Quando una replica viene ricreata, gli utenti possono aspettarsi un periodo di inattività mentre vengono completate le seguenti operazioni:
    • La replica è stata interrotta.
    • La replica viene eliminata.
    • Viene creato uno snapshot dell'istanza principale.
    • La replica viene ricreata da questo ultimo snapshot. La nuova replica utilizza lo stesso nome e lo stesso indirizzo IP della precedente. Di conseguenza, MySQL deve arrestarsi e riavviarsi.
    • La nuova replica inizia a replicare i dati.
  • replicationLagMaxSeconds è un campo a livello di istanza. Ogni istanza ha il proprio 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 temporali diverse per repliche diverse può aiutarti a evitare uno scenario in cui tutte le repliche si interrompono contemporaneamente.

Abilita ricreazione della replica in ritardo

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

gcloud

Utilizza il comando gcloud sql instances create per creare una nuova istanza di replica di lettura con il flag
--replication-lag-max-seconds-for-recreate:

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

Dove:

  • REPLICA_INSTANCE_NAME è il nome dell'istanza replica.
  • PRIMARY_INSTANCE_NAME è il nome dell'istanza principale.
  • DATABASE_VERSION è la versione del database dell'istanza. Ad esempio, MYSQL_8_0_31.
  • TIER è il tipo di macchina che vuoi utilizzare per l'istanza di replica. Ad esempio, db-perf-optimized-N-4. Per ulteriori informazioni, consulta Configurazioni personalizzate delle istanze.
  • EDITION è l'edizione che vuoi utilizzare per l'istanza replica. Ad esempio, ENTERPRISE_PLUS. Per saperne di più, vedi Crea un'istanza.
  • REGION è la regione che vuoi utilizzare per l'istanza di replica. Ad esempio, us-central1.
  • PASSWORD è la password root per l'istanza.
  • REPLICATION_LAG_MAX_SECONDS è il ritardo o il ritardo di replica massimo accettabile in secondi. Ad esempio, 600. Il valore minimo accettabile è 300 secondi o 5 minuti. Il valore massimo accettabile è 31.536.000 secondi o un anno.

API REST

Il campo replicationLagMaxSeconds si trova nella risorsa DatabaseInstance. Aggiungi questo campo al corpo della richiesta:

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

Dove:

  • REPLICATION_LAG_MAX_SECONDS è il ritardo o il ritardo di replica massimo accettabile in secondi. Ad esempio, 600.

Aggiorna il periodo di ricreazione per il ritardo di 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 l'intervallo di tempo di ritardo della replica che hai specificato come accettabile prima che la replica venga ricreata.

gcloud

Utilizza il comando gcloud sql instances patch per aggiornare il periodo di tempo per ricreare l'istanza in base al ritardo di replica:

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

Dove:

  • INSTANCE_NAME è il nome dell'istanza.
  • REPLICATION_LAG_MAX_SECONDS è il ritardo o il ritardo di replica massimo accettabile in secondi. Ad esempio, 700. Se vuoi ripristinare il valore predefinito di un anno, inserisci 31536000. Il valore minimo accettabile è 300 secondi o 5 minuti. Il valore massimo accettabile è 31.536.000 secondi o un anno.

API REST

Il criterio può essere aggiornato utilizzando instances.patch e instance.insert.

Per un esempio di come aggiornare l'impostazione utilizzando l'API REST, vedi Modificare un'istanza.

Limitazioni

Si applicano le seguenti limitazioni alla ricreazione delle repliche in ritardo:

  • 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 la ricreazione della replica.
  • Per evitare tempi di inattività frequenti sulle repliche di lettura, le ricreazioni sono limitate a una al giorno per istanza.
  • Le repliche di server esterni non sono supportate da questa funzionalità.
  • Se abiliti la ricreazione delle repliche in ritardo in una replica a cascata, Cloud SQL ricrea prima le repliche foglia per mantenere la coerenza della replica.
  • La ricreazione di una replica tra regioni comporta costi aggiuntivi.
  • Non puoi attivare la ricreazione delle repliche in ritardo nella console Google Cloud .

Qual è il passaggio successivo?