Panoramica degli indici delle repliche di lettura

Questo documento descrive i concetti e i meccanismi per la gestione degli indici secondari sulle repliche di lettura di Cloud SQL sia in Cloud SQL Enterprise edition che in Cloud SQL Enterprise Plus edition. In MySQL, puoi creare due tipi principali di indici su una tabella:

  • Indice cluster: l'indice principale di una tabella MySQL che ordina fisicamente le righe sul disco. Quando definisci una chiave primaria su una tabella, MySQL la utilizza come indice cluster. Una tabella può avere un solo indice cluster.

  • Indice secondario: un indice aggiuntivo su una tabella MySQL che ottimizza le prestazioni delle query.

    Sebbene una replica sia normalmente di sola lettura, puoi creare indici secondari sulle tabelle per scopi di reporting. Cloud SQL supporta due metodi per creare indici secondari di replica:

    • Indici di replica gestiti (consigliato): Cloud SQL archivia le definizioni degli indici nell'istanza principale e ricrea automaticamente gli indici secondari dopo l'arresto anomalo o la ricreazione della replica. Google consiglia di utilizzare indici gestiti anziché indici autogestiti per evitare la perdita di indici e il ripristino manuale degli indici.
    • Indici di replica autogestiti: consentono di aggiungere ed eliminare indici secondari direttamente su una replica, ma questi indici non vengono mantenuti dopo l'arresto anomalo o la nuova creazione della replica. Se utilizzi indici autogestiti, puoi eseguire la migrazione all'utilizzo di indici di replica gestiti.

Confronta i metodi di indicizzazione delle repliche

La tabella seguente mette a confronto gli indici delle repliche gestite e gli indici delle repliche autogestite in Cloud SQL:

Funzionalità Indici delle repliche gestite Indici di replica autogestiti
Persistenza durante la ricreazione della replica Ricostruito automaticamente Eliminato (è richiesta la ricostruzione manuale)
Modello di configurazione Metadati centralizzati sull'istanza principale DDL diretto sulla replica di lettura di destinazione
Meccanismo di esecuzione Processo in background periodico
(circa ogni cinque minuti)		 Esecuzione immediata
Guardrail per il ritardo della replica Mette automaticamente in pausa la creazione dell'indice se il ritardo di replica supera i 20 minuti Nessuna (gestita dall'utente)
Versioni supportate Cloud SQL Enterprise e Cloud SQL Enterprise Plus Cloud SQL Enterprise e Cloud SQL Enterprise Plus
Versioni del database supportate Cloud SQL per MySQL
(versione di manutenzione R20260726.00_05 o successiva)		 Cloud SQL per MySQL
(tutte le versioni supportate)
Supporto delle repliche del server esterno Non supportata Supportato

Indici delle repliche gestite

Per evitare la perdita di indici dopo la nuova creazione della replica, Cloud SQL supporta gli indici delle repliche gestite. Google consiglia questo metodo di creazione e conservazione degli indici. Cloud SQL attiva questo metodo per impostazione predefinita.

Gli indici delle repliche gestite richiedono la versione di manutenzione di Cloud SQL R20260726.00_05 o successive.

Le sezioni seguenti descrivono il modo in cui Cloud SQL gestisce gli indici delle repliche, i loro vantaggi e il loro comportamento durante gli eventi del ciclo di vita.

Come Cloud SQL gestisce gli indici delle repliche gestite

Con questo metodo, definisci gli indici secondari delle repliche, li raggruppi e designi quali repliche possono gestire questi gruppi di indici. Cloud SQL esegue un processo in background sulla replica per creare ed eliminare automaticamente gli indici richiesti e mantenerli nel tempo. Quando Cloud SQL crea un indice di replica gestita, antepone un tag [SIC_X_Y] al commento dell'indice, dove X e Y sono numeri interi. Questo tag viene utilizzato esclusivamente per la gestione interna e non ha alcuna funzionalità.

Cloud SQL esegue la manutenzione degli indici delle repliche gestite, ad esempio la creazione e l'eliminazione degli indici, in batch. Dopo che il processo di manutenzione dell'indice Cloud SQL ha selezionato un gruppo di azioni CREATE o DROP, crea una voce di stato PENDING per ogni indice secondario. Quindi esegue in serie ogni istruzione DDL (Data Definition Language). Un errore in un indice non blocca l'esecuzione degli indici successivi nella coda. Cloud SQL preleva quindi il batch successivo dopo circa cinque minuti.

Vantaggi e casi d'uso

Gli indici di replica gestita offrono i seguenti vantaggi:

  • Conservazione automatica degli indici: quando Cloud SQL ricrea una replica di lettura (ad esempio dopo un arresto anomalo dell'istanza), Cloud SQL ricrea automaticamente gli indici secondari mappati a quella replica. Non è necessario eseguire stored procedure manuali o gestire script di monitoraggio dello schema esterni per ripristinare gli indici mancanti.
  • Prestazioni delle query coerenti: ricostruendo automaticamente gli indici secondari dopo il recupero della replica, Cloud SQL mantiene il throughput delle query e previene i picchi di latenza delle query e l'utilizzo elevato della CPU causati da query non indicizzate.
  • Configurazione basata su gruppi: definisci gli indici secondari una volta nell'istanza principale e li organizzi in gruppi di repliche denominati. Puoi quindi assegnare un gruppo di indici contenente centinaia di indici a una replica di lettura impostando un singolo flag di database (cloudsql_index_recreate_replica_group). In questo modo, non è necessario eseguire singole stored procedure su più repliche.
  • Assegnazione selettiva degli indici in base al ruolo della replica: puoi assegnare gruppi di indici specificamente alle repliche di lettura di report e analisi per accelerare le query di lettura, mantenendo le repliche di lettura di ripristino di emergenza (RE) non indicizzate e identiche allo schema dell'istanza principale. In questo modo si evita l'overhead delle transazioni di scrittura e il ritardo di replica sulle istanze di RE.
  • Isolamento delle prestazioni dell'istanza principale: gli indici secondari sulle repliche di lettura ottimizzano le query di lettura e di generazione di report senza consumare spazio di archiviazione o aggiungere latenza delle transazioni di scrittura all'istanza principale.
  • Osservabilità integrata: le stored procedure dedicate consentono di monitorare l'avanzamento della creazione degli indici, la durata dell'esecuzione e i log degli errori sulla replica di lettura.
  • Migrazione e coesistenza senza interruzioni: gli indici delle repliche gestite coesistono in sicurezza con gli indici delle repliche autogestite esistenti sulla stessa istanza e tabella. Puoi adottare gli indici di replica gestiti in modo incrementale senza tempi di inattività o interruzioni dei workload di query di lettura attivi.

Promozione della replica

Cloud SQL gestisce gli indici delle repliche gestite solo sulle istanze di replica di lettura. Se promuovi una replica di lettura a un'istanza principale, Cloud SQL elimina automaticamente tutti gli indici secondari creati come indici di replica gestiti. Potrebbe verificarsi un ritardo di circa cinque minuti prima che Cloud SQL esegua l'eliminazione.

Sebbene Cloud SQL elimini gli indici secondari e rimuova i flag di database dall'istanza promossa, l'istanza principale conserva le definizioni degli indici secondari e le mappature dei gruppi.

Switchover del disaster recovery (RE)

Durante un cambio di RE, quando promuovi la replica di RE alla nuova istanza principale, Cloud SQL elimina automaticamente tutti gli indici secondari creati nella replica di RE. Cloud SQL non crea automaticamente questi indici secondari nell'istanza principale precedente quando diventa una replica.

Per creare indici secondari sulla vecchia istanza principale dopo lo switchover, imposta il flag di database cloudsql_index_recreate_replica_group su quell'istanza.

Ritardo della replica

Cloud SQL mette in pausa le operazioni di creazione degli indici secondari se il ritardo di replica supera i 20 minuti. Se la creazione dell'indice della replica gestita è già in corso quando il ritardo supera i 20 minuti, Cloud SQL consente il completamento dell'operazione. Il ritardo di replica non mette in pausa le operazioni di eliminazione degli indici delle repliche gestite.

Limitazioni

Quando utilizzi gli indici di replica gestiti, si applicano le seguenti limitazioni:

  • Non puoi creare indici di replica gestiti su repliche di server esterni: Cloud SQL non supporta la creazione di indici di replica gestiti per le repliche di server esterni.
  • Massimo di 1000 indici per gruppo di repliche: puoi assegnare un massimo di 1000 indici secondari a un gruppo di repliche.
  • L'aggiornamento o la modifica dei metadati dell'indice non sono supportati: non puoi aggiornare o modificare i metadati dell'indice esistenti. Per modificare un indice, devi eliminare la definizione dell'indice esistente e crearne una nuova.

Indici di replica autogestiti

Gli indici delle repliche autogestite sono indici secondari che crei ed elimini direttamente sulle singole repliche di lettura di Cloud SQL. Come gli indici delle repliche gestite, ottimizzano le prestazioni delle query di lettura, ad esempio per i workload di reporting e analisi, senza consumare spazio di archiviazione o influire sulla latenza di scrittura nell'istanza principale.

Gestione degli indici autogestita

Puoi gestire gli indici delle repliche con gestione indipendente direttamente sulla replica di lettura utilizzando le seguenti stored procedure nello schema mysql:

  • mysql.addSecondaryIdxOnReplica: aggiunge un indice secondario su una tabella specificata nella replica di lettura. Questa stored procedure è un wrapper per l'istruzione DDL CREATE INDEX.
  • mysql.dropSecondaryIdxOnReplica: elimina un indice secondario creato in precedenza dalla replica di lettura. Questa stored procedure è un wrapper per l'istruzione DDL DROP INDEX.

L'esecuzione di queste stored procedure richiede il ruolo cloudsqlsuperuser.

Quando crei un indice autogestito, Cloud SQL registra i metadati di base nella tabella mysql.cloudsql_replica_index della replica, inclusi il nome del database, il nome della tabella e il nome dell'indice. A differenza degli indici di replica gestiti, gli indici autogestiti non sono registrati nell'istanza principale e non vengono gestiti dal processo di replica in background di Cloud SQL.

Per i dettagli sulla sintassi e gli esempi di utilizzo, consulta Indici di replica autogestiti.

Vantaggi e casi d'uso

Gli indici di replica autogestiti offrono i seguenti vantaggi per flussi di lavoro specifici:

  • Isolamento delle prestazioni dell'istanza principale: gli indici secondari sulle repliche di lettura ottimizzano le query di lettura e di generazione di report senza consumare spazio di archiviazione o aggiungere latenza delle transazioni di scrittura all'istanza principale.
  • Esecuzione immediata: le chiamate alle stored procedure vengono eseguite immediatamente come istruzioni DDL sulla replica, senza attendere il ciclo di manutenzione periodica in background (circa ogni cinque minuti) richiesto dagli indici delle repliche gestite.
  • Test e sperimentazione isolati: puoi testare le prestazioni delle query e convalidare le ottimizzazioni degli indici su una singola replica di lettura prima di creare indici di replica gestiti in un gruppo di repliche.

Limitazioni

Gli indici di replica autogestiti presentano limitazioni operative significative:

  • Mancanza di persistenza durante la nuova creazione della replica: se Cloud SQL ricrea una replica di lettura (ad esempio durante il ripristino dell'istanza, la manutenzione o un guasto hardware), tutti gli indici secondari autogestiti su quella replica vengono eliminati e non vengono ripristinati automaticamente.
  • Overhead di ripristino manuale: Cloud SQL non può ricostruire e ricreare gli indici. Devi ricreare manualmente gli indici eseguendo nuovamente mysql.addSecondaryIdxOnReplica.
  • Degrado delle prestazioni delle query: le query di lettura potrebbero subire un degrado delle prestazioni dopo la nuova creazione della replica fino a quando non ricrei manualmente gli indici mancanti.

Poiché gli indici delle repliche gestite vengono mantenuti e ricostruiti automaticamente durante gli eventi di nuova creazione delle repliche, Google consiglia di utilizzare gli indici delle repliche gestite per i workload di produzione. Se hai indici autogestiti esistenti, esegui la migrazione agli indici di replica gestiti.

Coesistenza di tipi di indice di replica

Gli indici di replica autogestiti (creati utilizzando mysql.addSecondaryIdxOnReplica) e gli indici di replica gestiti possono coesistere nella stessa istanza di replica di lettura di Cloud SQL e nella stessa tabella. In questo modo puoi adottare gli indici di replica gestiti in modo incrementale senza interrompere i workload del database esistenti.

Quando utilizzi entrambi i metodi di gestione degli indici, tieni presente i seguenti comportamenti:

  • Funzionamento indipendente: gli indici autogestiti che crei direttamente sulla replica di lettura continuano a funzionare insieme agli indici della replica gestita.
  • Valutazione periodica: il processo di manutenzione in background di Cloud SQL valuta periodicamente (circa ogni cinque minuti) le definizioni degli indici mappate al gruppo di repliche che assegni alla replica.
  • Gestione dei conflitti di nomi: se registri una definizione di indice di replica gestita con lo stesso nome di un indice autogestito esistente nella replica di lettura, il processo in background rileva che esiste già un indice con quel nome. Il processo registra uno stato FAILED nella tabella mysql.cloudsql_replica_idx_status. Questo errore non influisce sul traffico del database, non crea blocchi delle tabelle e non influisce sull'indice autogestito esistente.
  • Risoluzione automatica al momento della nuova creazione: quando la replica di lettura viene creata di nuovo, Cloud SQL elimina l'indice autogestito esistente nell'ambito della nuova creazione dell'istanza e crea automaticamente l'indice della replica gestita dalla definizione registrata.

Passaggi successivi