Configura MySQL su Compute Engine

Compute Engine offre una gamma di diversi tipi di istanze e opzioni di archiviazione per leggere e scrivere dati dai tuoi database MySQL. Per assicurarti di ottenere le migliori prestazioni e il costo migliore per i tuoi carichi di lavoro del database, ti consigliamo di eseguire i prodotti IaaS (Infrastructure as a Service) di nuova generazione.

I seguenti consigli di configurazione tengono conto del fatto che i carichi di lavoro MySQL vengono spesso utilizzati in sistemi con un'elevata percentuale di operazioni di lettura, come l'elaborazione delle transazioni online (OLTP) o il database di supporto di una tipica applicazione web. Inoltre, tengono conto delle scelte di configurazione comuni, come l'utilizzo della versione 8.0 o successive di MySQL e del motore di archiviazione InnoDB. Per i carichi di lavoro sensibili alle prestazioni, potrebbe essere necessario modificare le configurazioni in base alle esigenze. Ti consigliamo di utilizzare questa guida come punto di partenza per il deployment, quindi di eseguire test con il tuo carico di lavoro effettivo per verificare che la configurazione soddisfi le tue esigenze.

Scegli la macchina virtuale (VM)

Per i carichi di lavoro MySQL, ti consigliamo di utilizzare la generazione più recente delle famiglie di macchine C e N, in quanto includono forme che funzionano bene per la maggior parte delle configurazioni MySQL pratiche. Per un'introduzione a queste serie di macchine, consulta il seguente Google Cloud post del blog. Queste famiglie di macchine utilizzano Titanium e si basano su generazioni recenti di processori Intel, AMD e Axion.

Concentrati sul rendimento

Per i workload sensibili alle prestazioni, come i database MySQL critici per l'attività, consigliamo le istanze C4 e C4A più recenti, se disponibili nella tua regione. Se non riesci ad accedervi, le istanze C3 e C3D offrono un approccio simile al rendimento.

Queste istanze offrono la latenza più bassa e più costante per le operazioni legate al calcolo e includono le seguenti funzionalità utili per i carichi di lavoro incentrati sulle prestazioni:

  • Controllo degli eventi di manutenzione dell'host con notifica anticipata
  • Controllo dell'aumento della frequenza turbo a un solo core per una maggiore coerenza delle prestazioni
  • Networking Tier_1 per una maggiore larghezza di banda di rete

Se utilizzi un'istanza C4A, C3 o C3D, puoi anche utilizzare unità a stato solido locali (SSD locali) per soddisfare requisiti di prestazioni specifici.

Ottimizzazione per il costo

Per i workload in cui la priorità principale è l'ottimizzazione dei costi, ad esempio i database MySQL con livelli di traffico da bassi a medi o i database utilizzati in ambienti di test o di sviluppo, ti consigliamo di utilizzare le istanze N4 più recenti. Queste istanze utilizzano la gestione delle risorse dinamica di nuova generazione di Compute Engine per ottimizzare il costo totale mantenendo al contempo un rendimento solido, senza le garanzie offerte da C4, C4A, C3 e C3D. Per maggiori dettagli, consulta Gestione delle risorse dinamiche di nuova generazione.

Configura le dimensioni della VM

Per qualsiasi VM che utilizzi, è importante scegliere le dimensioni giuste per il livello di prestazioni di MySQL che vuoi raggiungere.

Se vuoi ottenere un elevato numero di transazioni di scrittura al secondo (TPS), il principale fattore da considerare è lo spazio di archiviazione a blocchi. Per maggiori dettagli, consulta la sezione Configurare lo spazio di archiviazione a blocchi di seguito in questa pagina.

Se vuoi ottenere un elevato numero di query di lettura al secondo (QPS), ti consigliamo vivamente di utilizzare il pool di buffer basato su RAM di MySQL per memorizzare nella cache i dati più utilizzati e ridurre gli accessi al disco. Per massimizzare questi vantaggi, svolgi i seguenti passaggi:

  • Scegli una dimensione della VM che garantisca che il set di lavoro, ovvero la quantità totale di dati elaborati contemporaneamente dal database, rientri nel pool di buffer.
  • Imposta le dimensioni del pool di buffer in modo da utilizzare la maggior parte della RAM sulla VM.

Per ridurre al minimo il costo del dimensionamento della VM in questo modo, consigliamo di utilizzare una VM con un rapporto elevato tra RAM e CPU virtuali (vCPU), per evitare di pagare le vCPU che non utilizzi.

Per un equilibrio ideale per la maggior parte dei carichi di lavoro MySQL, determina l'insieme di lavoro del tuo carico di lavoro, quindi scegli la forma dell'istanza highmem più piccola che si adatta a quell'insieme di lavoro in RAM. Le istanze highmem hanno circa 8 GB di RAM per vCPU. In questo modo, hai a disposizione memoria sufficiente per memorizzare nella cache un set di lavoro di grandi dimensioni, mantenendo al contempo una CPU sufficiente per gestire un carico di query elevato.

Per i carichi di lavoro con set di lavoro di grandi dimensioni, ma con tassi di query ridotti, utilizzando le istanze N4, puoi ottimizzare ulteriormente il costo totale utilizzando tipi di macchine personalizzate con memoria estesa per aumentare ulteriormente il rapporto RAM/vCPU.

Configura la larghezza di banda di rete della VM

Per la maggior parte dei casi d'uso di MySQL, puoi attenerti ai limiti di larghezza di banda della rete predefiniti per la tua istanza. Se questa soluzione soddisfa le tue esigenze, non è necessario eseguire l'upgrade alla connettività Tier_1.

Configurare l'archiviazione a blocchi

Google Cloud Hyperdisk è l'unica generazione di archiviazione a blocchi durevole disponibile per le famiglie di VM Compute Engine recenti. Riteniamo che Hyperdisk bilanciato sia la scelta migliore per la maggior parte dei carichi di lavoro MySQL. Per saperne di più su Hyperdisk, consulta la documentazione di Hyperdisk.

Google Cloud Hyperdisk

Hyperdisk bilanciato offre le seguenti funzionalità:

  • Latenza dell'unità a stato solido (SSD) a basso costo
  • Configurazioni ad alte prestazioni per le applicazioni che ne hanno bisogno
  • Durabilità superiore al 99,999% per proteggerti dal rischio a livello di settore di guasti hardware e silenziosi corruzioni dei dati
  • Crittografia di tutti i dati at-rest di Hyperdisk con chiavi di crittografia gestite da Google o dal cliente

Seleziona il tuo livello di rendimento

Con Hyperdisk Balanced, puoi selezionare il livello di prestazioni indipendentemente dalle dimensioni dello spazio di archiviazione del disco, in modo da ottimizzare le prestazioni del database pagando solo le risorse di input/output (I/O) necessarie per il tuo carico di lavoro. Se il pool del buffer di un database MySQL è più grande del suo set di lavoro, durante le operazioni in stato stazionario può soddisfare quasi tutte le query di lettura dal pool del buffer, senza toccare il disco.

Per selezionare un livello di prestazioni per il volume Hyperdisk, prendi in considerazione il tuo carico di lavoro di scrittura MySQL, con particolare attenzione a quanto segue:

  • Accesso ai log di reintegrazione InnoDB
  • Aggiornamenti successivi ai file e agli indici di dati InnoDB

Al di fuori delle operazioni in stato stazionario, gli eventi di manutenzione del database possono anche causare un peggioramento delle prestazioni del disco. La frequenza con cui si verifica questo problema tende a crescere con il carico di lavoro di scrittura del database, pertanto è più probabile in situazioni come il recupero post-arresto anomalo mediante i log di reintegrazione o un sistema di backup che si copia leggendo tutte le modifiche al database dall'ultimo backup.

Scegli le dimensioni del disco

Esistono tre strategie comuni per determinare le dimensioni dei limiti di prestazioni del disco:

  1. Utilizza la configurazione predefinita. Ogni disco offre almeno 3000 operazioni di input/output al secondo (IOPS) e 140 MiBps di throughput. Questo è sufficiente per i workload MySQL di base e i volumi di avvio del sistema operativo (OS). Se il tuo caso d'uso supera queste dimensioni, puoi modificare le prestazioni di I/O di cui è stato eseguito il provisioning in base alle tue esigenze senza interrompere il carico di lavoro.
  2. Misura l'utilizzo esistente. Se il database è già in esecuzione in un altro ambiente, registra le IOPS e la velocità effettiva del disco con una granularità di un minuto o meno. Dopo aver raccolto 1-2 settimane di dati, in modo che il set di esempi includa alcune fluttuazioni del carico e degli eventi di manutenzione ordinaria, seleziona un valore percentile alto dal set di dati e aggiungi un piccolo buffer per tenere conto della crescita organica o dell'utilizzo imprevisto.
  3. Stima le tue esigenze e poi modificale in un secondo momento. Se non hai un'origine dati esistente, potresti dover stimare inizialmente le tue esigenze di rendimento, per poi ottimizzarle ulteriormente dopo il deployment. Ti consigliamo di eseguire il provisioning di un valore superiore a quello che pensi di aver bisogno inizialmente, in modo che il tuo carico di lavoro non riscontri colli di bottiglia delle prestazioni, per poi ridurre le prestazioni di cui hai eseguito il provisioning in base al tuo carico di lavoro.

Aumentare le prestazioni del disco

Puoi aumentare le prestazioni di ogni disco Hyperdisk bilanciato fino a un massimo di 160.000 IOPS e 2400 MB/s di throughput. Le dimensioni della VM contribuiscono a determinare i limiti massimi delle prestazioni di Hyperdisk, pertanto, se vuoi prestazioni molto elevate di Hyperdisk, potresti dover aumentare il numero di core della VM. Se i tuoi carichi di lavoro più impegnativi richiedono prestazioni superiori rispetto a quelle che può fornire un singolo disco Hyperdisk bilanciato, puoi utilizzare uno dei seguenti metodi per eseguire lo striping di più dischi Hyperdisk bilanciati:

  • Eseguire l'upgrade a Hyperdisk Extreme
  • Utilizza un altro meccanismo di array ridondante di dischi indipendenti (RAID) software, ad esempio mdadm

Man mano che esegui la scalabilità dei tuoi database MySQL, puoi aumentare dinamicamente la capacità e le prestazioni dei dischi senza tempi di inattività. Ciò migliora le prestazioni dei workload di tipo OLAP (Online Analytical Processing) che eseguono unioni complesse di grandi dimensioni che non possono essere inserite nella RAM e vengono trasferite sul disco. In rari casi, i carichi di lavoro MySQL che richiedono una latenza dello spazio di archiviazione estremamente bassa e possono tollerare la perdita di dati possono memorizzare il set di dati completo su SSD locale. Puoi anche utilizzare le seguenti soluzioni ibride per migliorare la latenza di lettura e limitare le riduzioni della durata:

  • Esegui il mirroring del set di dati tra un Hyperdisk e un'unità SSD locale.
  • Utilizza un gestore dei volumi per configurare l'unità SSD locale come cache per i dati archiviati su un Hyperdisk sottostante.

Sfrutta le funzionalità aggiuntive di Hyperdisk

Hyperdisk offre anche le seguenti funzionalità, che possono migliorare o semplificare i flussi di lavoro di disponibilità elevata e ripristino di emergenza on-premise:

Per ulteriori informazioni sulla configurazione di queste funzionalità con MySQL per Compute Engine, consulta la sezione sull'alta disponibilità che segue in questa pagina.

SSD locali

Alcune famiglie di macchine Compute Engine ti consentono di utilizzare SSD locali anziché Hyperdisk. Non si tratta di spazio di archiviazione permanente, ma i carichi di lavoro MySQL spesso li utilizzano per archiviare spazi tabella temporanei.

Per informazioni sull'utilizzo delle unità SSD locali per scalare i database MySQL, consulta Ridimensionamento dinamico dei dischi, che segue in questa pagina.

Altre funzionalità di Compute Engine

Puoi utilizzare le seguenti funzionalità di Compute Engine per ottimizzare il deployment MySQL.

Cloud Monitoring

Per monitorare le prestazioni della VM e l'utilizzo dei servizi di infrastruttura, utilizza la Google Cloud console. Nella pagina Istanze VM, nella scheda Osservabilità, puoi monitorare le metriche relative al rendimento, come l'utilizzo della CPU e della memoria, la larghezza di banda della rete e il rendimento delle istanze di cui è stato eseguito il provisioning. Analogamente, nella pagina Dischi, nella scheda Osservabilità, puoi monitorare il throughput e le IOPS dei volumi dei dischi.

Per personalizzare le metriche sul rendimento visualizzate, utilizza Cloud Monitoring per elaborare query. Puoi selezionare le metriche sul rendimento specifiche che vuoi visualizzare per i tuoi servizi di infrastruttura. Per le metriche specifiche di MySQL, Compute Engine offre un plug-in per i carichi di lavoro MySQL.

Best practice per la configurazione del sistema operativo

  • Utilizza un file system appropriato. Google si concentra sull'ottimizzazione per i file system ext4 e XFS di Linux. Tuttavia, la maggior parte dei file system è appropriata per l'utilizzo con MySQL.
  • Disattiva le pagine enormi trasparenti (THP) nella configurazione di base del sistema operativo. Per la procedura di disattivazione di THP, consulta la documentazione di THP.
  • Se utilizzi Linux, utilizza i flag relatime e lazytime per la configurazione del montaggio del file system. In questo modo, si riducono i costi aggiuntivi per le prestazioni associati all'aggiornamento dei valori atime, mtime e ctime nei file quando vengono letti, modificati o se ne modificano i metadati.

Best practice per la configurazione di MySQL

Ti consigliamo di utilizzare le seguenti impostazioni di configurazione per MySQL.

  • Utilizza una versione recente di MySQL. Google si concentra sull'ottimizzazione per MySQL nella versione 8.0 e successive.

  • Aumenta le dimensioni del pool di buffer. MySQL utilizza il pool di buffer per migliorare le prestazioni di lettura memorizzando nella cache i dati in RAM e riducendo gli accessi al disco. Per impostazione predefinita, la dimensione del pool di buffer di MySQL è 128 MiB, che è troppo piccola per la maggior parte dei casi d'uso pratici. Ti consigliamo di aumentare le dimensioni di innodb_buffer_pool_size in modo che siano maggiori delle dimensioni del set di lavoro a cui accede la tua applicazione nel database. Di solito, si tratta dei seguenti passaggi:

    1. Misura o stima le dimensioni del set di lavoro su una copia in esecuzione della tua istanza MySQL.
    2. Scegli le dimensioni e la configurazione di una macchina virtuale (VM) con RAM sufficiente per adattarsi al set di lavoro.
    3. Configura la dimensione del pool di buffer sulla VM in modo che occupi la maggior parte della RAM disponibile.

  • Attiva il buffer di scrittura doppia. MySQL dispone di un buffer di scrittura doppia che aiuta a proteggersi dalle scritture incomplete, una modalità di errore in cui una scrittura che copre più blocchi sul disco potrebbe essere confermata solo parzialmente se si verifica un guasto hardware o di alimentazione nel mezzo della scrittura. Per usufruire di questa protezione, attiva innodb_doublewrite.

  • Imposta il valore di innodb_flush_log_at_trx_commit su 1. In questo modo, le transazioni di scrittura sono durature sul disco quando vengono confermate.

  • Per ridurre il sovraccarico delle prestazioni, specifica un valore per innodb_flush_method. Per MySQL 8.0.14 e versioni successive, imposta il valore di innodb_flush_method su O_DIRECT_NO_FSYNC, che è ottimale, ma presente solo in queste versioni. Per le versioni di MySQL precedenti alla 8.0.14, imposta il valore di innodb_flush_method su O_DIRECT.

  • Negli scenari di replica ad alta disponibilità, imposta il valore di sync_binlog dell'istanza di database principale su 1. MySQL utilizza il proprio log binario per comunicare le modifiche dal database principale a quello secondario, in modo da garantire che i log binari vengano sottoposti a commit al momento del commit della transazione, con il ritardo di replica e il punto di ripristino obiettivo (RPO) più basso possibile tra i database.

  • Quando utilizzi MySQL nelle famiglie di macchine della serie C, attiva innodb_numa_interleave. In questo modo, il pool di buffer di MySQL può sfruttare i criteri di accesso alla memoria non uniforme (NUMA).

Quando disattivare il buffer di scrittura doppia

Il buffer di scrittura doppia di MySQL, che protegge dalle scritture non sequenziali, ha un overhead delle prestazioni fino al 25% per le transazioni di scrittura di MySQL, che potrebbe potenzialmente influire sulla latenza delle transazioni. Google Cloud Hyperdisk offre anche protezione da scrittura frammentata, quindi se utilizzi MySQL per scrivere direttamente in un sistema di file ext4 in esecuzione su Hyperdisk, puoi disattivare in sicurezza il buffer di scrittura doppia.

Tuttavia, affinché la protezione delle scritture non complete di Hyperdisk sia efficace, devi configurare il file system e altri livelli software intermedi tra il database e il disco per evitare di introdurre scritture non complete sopra il livello del disco. Il seguente elenco fornisce esempi di configurazioni che potrebbero introdurvi scritture non complete sopra il livello Hyperdisk:

  • Esegui l'istanza MySQL all'interno di container, come Google Kubernetes Engine o Kubernetes autonomo.
  • Archiviazione dei file MySQL su un file system XFS, che non supporta dimensioni dei blocchi sufficientemente grandi nella maggior parte delle configurazioni del kernel Linux.
  • Archiviazione dei file MySQL su una configurazione di array di dischi indipendenti (RAID) redundante che causa lo striping dei dischi, ad esempio mdadm per Linux o Storage Spaces e Storage Spaces Direct per Windows.
  • Archiviazione dei file MySQL su un gestore dei volumi, ad esempio Logical Volume Manager (LVM) per Linux o Storage Spaces e Storage Spaces Direct per Windows.

  • Memorizzazione dei file MySQL su Hyperdisk con unità SSD (solid-state drive) locale configurata come cache, ad esempio utilizzando lvmcache, dm-cache o bcache per Linux o Storage Spaces per Windows.

  • Esegui l'istanza MySQL all'interno di una VM utilizzando la virtualizzazione nidificata.

Sebbene sia possibile configurare le configurazioni precedenti in modo che non introducano scrittura frammentata, sconsigliamo di disattivare il buffer di scrittura doppia quando le utilizzi, a causa della difficoltà di convalidare la sicurezza di una determinata configurazione.

(Facoltativo) Disattivare il buffer di scrittura doppia

Per disattivare il buffer di scrittura doppia:

  1. Sul file system ext4, devi attivare la funzionalità bigalloc e configurare le dimensioni del cluster del file system su 16 KiB o su un valore maggiore potenza di 2 multiplo di 16 KiB. In questo modo, le scritture di MySQL non verranno suddivise in I/O separate dal file system prima di essere emesse su Hyperdisk. Se non aumenti il limite o utilizzi un valore inferiore a 16 KiB, non puoi difenderti dalle scritture non complete. Ad esempio, con una dimensione del cluster di 16 KiB, questo viene configurato al momento della creazione del file system:

    mkfs.ext4 -O bigalloc -C 16384 /dev/<device-name>

  2. Disattiva innodb_doublewrite e imposta innodb_flush_method su O_DIRECT o O_DIRECT_NO_FSYNC (a seconda della versione di MySQL come описано выше).

Configurare l'alta disponibilità (HA) e una soluzione di backup

Ti consigliamo vivamente di proteggere tutti i tuoi carichi di lavoro MySQL critici configurando per loro soluzioni di alta disponibilità (HA) e di backup. Sia per l'HA che per il backup, i fattori più importanti sono i seguenti:

In genere, le soluzioni di alta disponibilità hanno come target RTO e RPO quasi nulli, ma proteggono solo dai guasti dell'infrastruttura. Le soluzioni di backup hanno come target finestre RTO e RPO più lunghe, ma forniscono copertura per un insieme più ampio di scenari di errore, ad esempio:

  • Eliminazione accidentale dei dati
  • Attacchi ransomware
  • Calamità naturali

Configura l'alta disponibilità (HA)

Le funzionalità HA utilizzano la ridondanza di archiviazione e calcolo per garantire che il database MySQL abbia tempi di inattività ridotti in caso di guasto o interruzione del servizio dell'host, consentendo alle applicazioni client di accedere ai dati anche quando un'istanza o una zona non è disponibile.

MySQL consente la replica nelle seguenti modalità:

  • Modalità asincrona. In modalità asincrona, il principale conferma le transazioni di scrittura non appena vengono confermate localmente, pertanto, in caso di interruzione del servizio sul principale, una piccola quantità di dati scritti di recente potrebbe andare persa durante il failover, poiché il RPO è vicino allo zero, ma non è effettivamente zero.
  • Modalità semi sincrona. In modalità semi sincrona, la principale attende di confermare la transazione finché un numero configurabile di repliche non ha confermato la ricezione della transazione. Ciò aumenta notevolmente la probabilità che non si verifichi alcuna perdita di dati durante un failover imprevisto, poiché il RPO è effettivamente pari a zero.

Per entrambe le modalità, il RTO viene determinato dalla rapidità con cui i controlli di integrità eseguono le seguenti operazioni:

  1. Identifica un'istanza non riuscita.
  2. Attiva il failover.
  3. Comunica ai client che l'istanza di failover è ora quella principale utilizzando il sistema DNS (Domain Name System) o un altro modo per identificare il server di database.

In entrambe le modalità di replica, devi disporre di un'istanza di failover di destinazione della replica. Puoi trovare l'istanza in uno dei seguenti punti:

  • Nella stessa zona in cui si trova l'istanza principale
  • Una zona diversa all'interno della regione in cui si trova il cluster principale
  • Si trova in una regione diversa da quella principale

Per mantenere un'alta disponibilità anche durante le interruzioni zonali, consigliamo la seguente configurazione:

  • Posiziona le istanze principali e di failover in zone diverse,indipendentemente dal fatto che si trovino o meno nella stessa regione.
  • Utilizza la replica asincrona. Questo perché, se utilizzi la replica semisincrona, l'ubicazione delle istanze principali e di failover in zone separate può causare una latenza elevata per i commit delle transazioni di scrittura.
  • Se hai bisogno di zero RPO, utilizza Hyperdisk bilanciato ad alta disponibilità, che ti consente di replicare in modo sincrono un disco in due zone della stessa regione. Per maggiori dettagli, consulta la guida di Google sulla fornitura di servizi HA utilizzando l'alta disponibilità di HyperDisk. Quando configuri l'alta disponibilità bilanciata Hyperdisk, ti consigliamo di eseguire l'integrazione con i gruppi di istanze gestite con stato per diagnosticare i problemi di integrità delle istanze e automatizzare le azioni di recupero.

Configurare un piano di backup e resilienza dei dati

I piani di backup e resilienza dei dati aiutano a evitare la perdita di dati durante errori come la cancellazione accidentale dei dati, attacchi di ransomware e calamità naturali. Puoi anche utilizzarli come cold storage per i requisiti di conformità e di controllo. Per MySQL sono disponibili molte metodologie di backup, alcune delle quali agiscono a livello di database e altre a livello di volume di archiviazione. Quando selezioni una metodologia, devi considerare principalmente i requisiti di RTO e RPO.

Eseguire il backup a livello di database

Per i backup a livello di database, ti consigliamo di utilizzare le seguenti opzioni fornite da MySQL:

Per ulteriori informazioni sulle opzioni di backup a livello di database di MySQL, consulta Backup e ripristino nella documentazione di MySQL.

Per qualsiasi di queste opzioni, devi disporre di un sistema di archiviazione secondario in cui copiare i dati di backup. Ti consigliamo i seguenti strumenti:

Utilizzare Hyperdisk per acquisire snapshot e creare cloni a livello di archiviazione

Per i backup a livello di archiviazione, consigliamo di utilizzare i prodotti Hyperdisk per acquisire snapshot, clonare e acquisire in altro modo una vista a un determinato momento del database MySQL. L'RPO per questo approccio dipende dalla frequenza con cui acquisisci gli snapshot del database, mentre l'RTO dipende dalla soluzione specifica che utilizzi.

Se il recupero rapido è importante per te e hai bisogno solo di una copertura di backup all'interno di una zona, ti consigliamo di utilizzare gli snapshot istantanei di Hyperdisk. Gli snapshot istantanei acquisiscono i dati in modo incrementale in un momento specifico e possono ripristinarli rapidamente in un nuovo volume Hyperdisk tramite la clonazione del disco, offrendo un RTO di pochi minuti. Ti consentono di recuperare i dati quando i contenuti di un disco sono stati sovrascritti, eliminati o danneggiati e sono disponibili localmente nella stessa zona o regione del disco di origine. Per saperne di più, consulta Informazioni sugli snapshot istantanei.

Per gli scenari di ripristino di emergenza, in cui i dati devono essere archiviati con una maggiore ridondanza rispetto al disco originale e in una posizione separata per assicurarsi che un singolo disastro non influisca su tutte le repliche dei dati, ti consigliamo di utilizzare gli snapshot di archiviazione e di disco standard di Hyperdisk. Gli snapshot di archiviazione e standard del disco creano una copia dei dati sul disco in un determinato momento e la memorizzano con elevata ridondanza in un formato immutabile. Quando crei più snapshot di un disco, ad esempio con una pianificazione degli snapshot, Hyperdisk memorizza solo le modifiche incrementali. Gli snapshot di archiviazione e standard sono adatti se puoi tollerare un RTO più elevato, perché la copia dei dati dallo spazio di archiviazione degli snapshot allo spazio di archiviazione della VM può richiedere più tempo per il ripristino. Per saperne di più, consulta la pagina Creare snapshot dei dischi standard e di archiviazione.

Gli snapshot istantanei di Hyperdisk e gli snapshot di archiviazione e standard sono entrambi coerenti con gli arresti anomali all'interno di un singolo disco. Ciò significa che quando esegui il ripristino da uno snapshot, il database MySQL deve eseguire i normali passaggi di recupero di InnoDB per ripristinare i log e i file di dati a uno stato coerente. A seconda della configurazione del log di reimpostazione InnoDB, questo può prolungare il RTO. I seguenti schemi possono complicare ulteriormente i tuoi tentativi di creare uno snapshot del database coerente:

  • I file del database MySQL sono distribuiti su più volumi.
  • Utilizzi utilità RAID software Linux, come mdadm.
  • Hai separato le posizioni di archiviazione configurate di MySQL nei filesystem su diversi dischi.

Per creare uno snapshot che non richiede il recupero dopo un ripristino da snapshot, compila i seguenti passaggi:

  1. Blocca temporaneamente l'accesso in scrittura al database MySQL.
  2. Svuotare tutti i buffer in corso sul disco utilizzando i comandi LOCK INSTANCE FOR BACKUP e FLUSH TABLES WITH READ LOCK.
  3. Avvia le operazioni di istantanea.

  4. Per gli scenari con più dischi, dopo aver eseguito il flush a livello di MySQL, esegui i comandi sync e fsfreeze sul server per svuotare tutte le scritture in corso sul disco e mettere in pausa le nuove scritture in entrata a livello di file system.

Dopo aver acquisito lo snapshot iniziale del database, non è necessario continuare a bloccare il disco, perché Hyperdisk acquisisce rapidamente la visualizzazione point-in-time e può elaborare in modo asincrono eventuali passaggi successivi di copia dello spazio di archiviazione. Se hai bisogno di questi passaggi per la coerenza degli snapshot e vuoi rimuovere questo impatto sulle scritture sul database principale, puoi anche eseguire il backup su una replica del database anziché sul database principale.

Passaggi successivi