Configura MySQL su Compute Engine

Compute Engine offre una gamma di diversi tipi di istanze e opzioni di archiviazione per la lettura e la scrittura di dati dai tuoi database MySQL. Per garantire le migliori prestazioni e il miglior costo per i carichi di lavoro del database, ti consigliamo di eseguire i prodotti di infrastruttura come servizio (IaaS) di nuova generazione.

I seguenti consigli di configurazione tengono conto del fatto che i carichi di lavoro MySQL vengono spesso utilizzati in sistemi con molte operazioni di lettura, come l'elaborazione delle transazioni online (OLTP) o il database che supporta una tipica applicazione web. Tengono inoltre conto delle scelte di configurazione comuni, come l'utilizzo della versione 8.0 o successive di MySQL e l'utilizzo del motore di archiviazione InnoDB. Per i carichi di lavoro sensibili alle prestazioni, potrebbe essere necessario modificare le configurazioni per adattarle. Ti consigliamo di utilizzare questa guida come punto di partenza per l'implementazione e poi 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 le famiglie di macchine C e N di ultima generazione, 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 post del blog:Google Cloud . Queste famiglie di macchine utilizzano Titanium e sono basate su generazioni recenti di processori Intel, AMD e Axion.

Concentrati sul rendimento

Per i workload sensibili al rendimento, come i database MySQL business-critical, consigliamo le istanze C4 e C4A se sono disponibili nella tua regione. Se non riesci ad accedervi, le istanze C3 e C3D offrono un focus simile sul rendimento.

Queste istanze offrono la latenza più bassa e più coerente per le operazioni vincolate 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 del potenziamento turbo su un singolo core per una maggiore coerenza delle prestazioni
  • Networking Tier_1 per una larghezza di banda di rete più elevata

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

Ottimizzare per i costi

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 dinamica delle risorse di Compute Engine di nuova generazione per ottimizzare il costo totale mantenendo prestazioni solide, senza le solide garanzie offerte da C4, C4A, C3 e C3D. Per maggiori dettagli, consulta la sezione Gestione delle risorse dinamiche di nuova generazione.

Configura le dimensioni della VM

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

Se miri a un elevato rendimento delle transazioni di scrittura al secondo (TPS), il fattore principale da considerare è l'archiviazione a blocchi. Per maggiori dettagli, vedi Configurare l'archiviazione a blocchi, più avanti in questa pagina.

Se vuoi ottenere prestazioni elevate per le query di lettura al secondo (QPS), ti consigliamo vivamente di utilizzare il pool di buffer basato sulla RAM di MySQL per memorizzare nella cache i dati attivi e ridurre gli accessi al disco. Per massimizzare questi vantaggi, segui questi passaggi:

  • Scegli una dimensione della VM che garantisca che il set di lavoro, ovvero la quantità totale di dati che il database elabora contemporaneamente, rientri nel pool di buffer.
  • Dimensiona il pool del buffer in modo che utilizzi la maggior parte della RAM della VM.

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

Per un equilibrio ideale per la maggior parte dei carichi di lavoro MySQL, determina il working set del tuo carico di lavoro, quindi scegli la forma dell'istanza highmem più piccola che si adatti a questo working set nella RAM. Le forme di istanza highmem hanno circa 8 GB di RAM per vCPU. In questo modo hai memoria sufficiente per memorizzare nella cache un ampio set di lavoro, mantenendo al contempo 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 bassi, 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 rispettare i limiti di larghezza di banda di rete predefiniti per la tua istanza. Se questa soluzione soddisfa le tue esigenze, non devi eseguire l'upgrade al networking Tier_1.

Configura l'archiviazione a blocchi

Google Cloud Hyperdisk è l'unica generazione di archiviazione a blocchi durevole disponibile per le recenti famiglie di VM Compute Engine. Riteniamo che Hyperdisk Balanced sia la soluzione migliore per la stragrande maggioranza dei workload MySQL. Per saperne di più su Hyperdisk, consulta la documentazione di Hyperdisk.

Google Cloud Hyperdisk

Hyperdisk Balanced 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 proteggere dal rischio di guasto hardware e danneggiamento silenzioso dei dati a livello di settore
  • Crittografia di tutti i dati Hyperdisk at-rest con chiavi di crittografia gestite da Google o dal cliente

Seleziona il tuo livello di rendimento

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

Per selezionare un livello di prestazioni per il volume Hyperdisk, considera il tuo workload di scrittura MySQL, con particolare attenzione a quanto segue:

  • Accesso ai InnoDB redo log
  • Aggiornamenti successivi a file di dati e indici InnoDB

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

Dimensionare il disco

Esistono tre strategie comuni per dimensionare i limiti di rendimento del disco:

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

Aumentare le prestazioni del disco

Puoi aumentare le prestazioni di ogni disco Hyperdisk Balanced fino a un massimo di 160.000 IOPS e 2400 MBps di throughput. Le dimensioni della VM contribuiscono a determinare i limiti massimi di prestazioni di Hyperdisk, quindi 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 del disco superiori a quelle che può fornire un singolo disco Hyperdisk bilanciato, puoi utilizzare uno dei seguenti metodi per combinare più dischi Hyperdisk bilanciato:

  • Esegui l'upgrade a Hyperdisk Extreme
  • Utilizza un meccanismo software RAID (Redundant Array of Independent Disks) diverso, ad esempio mdadm.

Man mano che aumenti le dimensioni dei tuoi database MySQL, puoi aumentare dinamicamente la capacità e le prestazioni dei tuoi dischi senza tempi di inattività. Ciò contribuisce a migliorare le prestazioni dei workload di elaborazione analitica online (OLAP) che eseguono unioni complesse di grandi dimensioni che non possono essere caricate nella RAM e vengono memorizzate su disco. In rari casi, i carichi di lavoro MySQL che richiedono una latenza di archiviazione estremamente bassa e possono tollerare la perdita di dati possono archiviare l'intero set di dati sull'unità SSD locale. Puoi anche utilizzare le seguenti soluzioni ibride per migliorare la latenza di lettura e limitare le riduzioni della durabilità:

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

Sfruttare le funzionalità aggiuntive di Hyperdisk

Hyperdisk offre anche le seguenti funzionalità, che possono aumentare o semplificare i flussi di lavoro di alta affidabilità eripristino di emergenzay on-premise:

Per ulteriori informazioni sulla configurazione di queste funzionalità con MySQL per Compute Engine, consulta la sezione Alta disponibilità riportata di seguito in questa pagina.

SSD locali

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

Per informazioni sull'utilizzo degli SSD locali per scalare i database MySQL, consulta Ridimensionamento dinamico del disco, che segue in questa pagina.

Funzionalità aggiuntive di Compute Engine

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

Cloud Monitoring

Per monitorare le prestazioni e l'utilizzo dei servizi di infrastruttura della VM, utilizza la consoleGoogle Cloud . Nella pagina Istanze VM, nella scheda Osservabilità, puoi monitorare le metriche correlate al rendimento, come l'utilizzo di CPU e memoria, la larghezza di banda di rete e il rendimento di provisioning delle tue istanze. Analogamente, nella pagina Dischi, nella scheda Osservabilità, puoi monitorare il throughput e le IOPS dei volumi del disco.

Per personalizzare le metriche sul rendimento visualizzate, utilizza Cloud Monitoring per creare query. Puoi selezionare le metriche di rendimento specifiche che vuoi visualizzare per i tuoi servizi di infrastruttura. Per le metriche specifiche di MySQL, Compute Engine offre un plug-in del workload 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 è adatta all'uso con MySQL.
  • Disattiva le huge page trasparenti (THP) nella configurazione del sistema operativo di base. Per i passaggi per disattivare 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 sovraccarichi di prestazioni associati all'aggiornamento dei valori atime, mtime e ctime nei file quando vengono letti, modificati o quando i relativi metadati vengono modificati.

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 versione 8.0 e successive.

  • Aumenta le dimensioni del buffer pool. MySQL utilizza il pool di buffer per migliorare le prestazioni di lettura memorizzando nella cache i dati nella RAM, 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, consiste nei seguenti passaggi:

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

  • Attiva il buffer di doppia scrittura. MySQL dispone di un buffer doublewrite� che aiuta a proteggere dalle scritture incomplete�, una modalità di errore in cui una scrittura che copre più blocchi sul disco potrebbe essere eseguita solo parzialmente se si verifica un errore hardware o di alimentazione durante la 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 durevoli sul disco quando vengono eseguite.

  • Per ridurre il sovraccarico delle prestazioni, specifica un valore per innodb_flush_method. Per MySQL versione 8.0.14 e 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 del database principale su 1. MySQL utilizza il log binario per comunicare le modifiche dal database primario al database 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 l'obiettivo del punto di ripristino (RPO) più bassi possibili tra i database.

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

Quando disattivare il buffer di doppia scrittura

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

Tuttavia, affinché la protezione da scrittura interrotta 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 interrotte sopra il livello del disco. Il seguente elenco fornisce esempi di configurazioni che potrebbero introdurre scritture incomplete sopra il livello Hyperdisk:

  • Esecuzione dell'istanza MySQL all'interno di container, come Google Kubernetes Engine o Kubernetes self-hosted.
  • Memorizzazione 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 in una configurazione RAID (Redundant Array of Independent Disks) che causa lo striping del disco, ad esempio mdadm per Linux o Storage Spaces e Storage Spaces Direct per Windows.
  • Memorizza i file MySQL su un gestore di volumi, ad esempio Logical Volume Manager (LVM) per Linux o Storage Spaces e Storage Spaces Direct per Windows.

  • Archivia i 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 Spazi di archiviazione per Windows.

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

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

(Facoltativo) Disattivare il buffer di doppia scrittura

Per disattivare il buffer di doppia scrittura, completa i seguenti passaggi:

  1. Nel file system ext4, devi attivare la funzionalità bigalloc e configurare le dimensioni del cluster del file system su 16 KiB o un multiplo di 16 KiB maggiore di una potenza di 2. In questo modo, le scritture di MySQL non verranno suddivise in operazioni di I/O separate dal file system prima di essere inviate a Hyperdisk. Se non aumenti il limite o utilizzi un valore inferiore a 16 KiB, non sarai protetto dalle scritture incomplete. Ad esempio, con una dimensione del cluster di 16 KiB, questa viene configurata 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 descritto sopra).

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

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

Le soluzioni HA in genere mirano a 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 di calcolo per garantire che il database MySQL abbia tempi di inattività ridotti in caso di guasto o interruzione 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 database primario riconosce le transazioni di scrittura non appena vengono eseguite localmente, quindi se si verifica un'interruzione sul database primario, una piccola quantità di dati scritti di recente potrebbe andare persa durante il failover, poiché l'RPO è vicino a zero, ma non effettivamente zero.
  • Modalità semisincrona. In modalità semisincrona, il database primario attende di confermare la transazione finché un numero configurabile di repliche non ha confermato la ricezione della transazione. In questo modo aumenta notevolmente la probabilità che non si verifichi alcuna perdita di dati durante un failover non pianificato, poiché l'RPO è effettivamente pari a zero.

Per entrambe le modalità, l'RTO è determinato dalla velocità con cui i controlli di integrità eseguono le seguenti operazioni:

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

In entrambe le modalità di replica, devi disporre di un'istanza di failover a cui eseguire la replica. Puoi trovare l'istanza in una delle seguenti posizioni:

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

Per mantenere l'alta affidabilità anche durante le interruzioni a livello di zona, consigliamo la seguente configurazione:

  • Individua le istanze primaria 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'individuazione delle istanze principale e di failover in zone separate può causare una latenza elevata per i commit delle transazioni di scrittura.
  • Se hai bisogno di un RPO pari a zero, utilizza Hyperdisk Balanced ad alta affidabilità, che ti consente di replicare in modo sincrono un disco in due zone nella stessa regione. Per maggiori dettagli, consulta la guida di Google alla fornitura di servizi HA utilizzando Hyperdisk ad alta affidabilità. Quando configuri Hyperdisk bilanciato ad alta affidabilità, ti consigliamo di eseguire l'integrazione con i gruppi di istanze gestite stateful per diagnosticare i problemi di integrità delle istanze e automatizzare le azioni di ripristino.

Configurare un piano di backup e resilienza dei dati

I piani di backup e resilienza dei dati aiutano a prevenire la perdita di dati durante errori come l'eliminazione accidentale dei dati, gli attacchi ransomware e le calamità naturali. Puoi utilizzarli anche come cold storage per i requisiti di conformità e audit. Per MySQL, esistono molte metodologie di backup tra cui scegliere, 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, valuta la possibilità di utilizzare le seguenti opzioni fornite da MySQL:

  • Backup incrementali basati sulla registrazione binaria,che creano dump logici dei dati. Questi includono:
  • Strumenti che gestiscono il processo di backup per te,ad esempio MySQL Enterprise Backup.

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

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

Utilizza Hyperdisk per creare snapshot e cloni a livello di spazio di archiviazione

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

Se il ripristino rapido è importante per te e hai bisogno della copertura del backup solo all'interno di una zona, ti consigliamo di utilizzare gli snapshot istantanei di Hyperdisk. Gli snapshot istantanei acquisiscono i dati in un momento specifico in modo incrementale e possono ripristinarli rapidamente in un nuovo volume Hyperdisk tramite la clonazione del disco, fornendo un RTO di pochi minuti. 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ù, vedi Informazioni sugli snapshot istantanei

Per gli scenari di ripristino di emergenza, in cui i dati devono essere archiviati con una ridondanza superiore a quella del disco originale e in una posizione separata per garantire che un singolo disastro non influisca su tutte le repliche dei dati, ti consigliamo di utilizzare gli snapshot di dischi standard e di archiviazione di Hyperdisk. Gli snapshot di archiviazione e standard del disco creano una copia dei dati nel disco in un determinato momento e la archiviano con elevata ridondanza in un formato immutabile. Quando crei più snapshot di un disco, ad esempio con una pianificazione di snapshot, Hyperdisk memorizza solo le modifiche incrementali. Gli snapshot di archiviazione e standard del disco sono una buona soluzione se puoi tollerare un RTO più elevato, perché la copia dei dati dall'archiviazione degli snapshot all'archiviazione della VM può richiedere più tempo per il ripristino. Per saperne di più, vedi Crea snapshot del disco standard e di archiviazione.

Gli snapshot istantanei di Hyperdisk e gli snapshot di archiviazione e standard sono coerenti in caso di arresto anomalo 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 ripristino di InnoDB per riportare i log e i file di dati a uno stato coerente. A seconda della configurazione del log di ripristino InnoDB, questo può allungare l'RTO. I seguenti pattern possono complicare ulteriormente i tuoi sforzi per creare uno snapshot coerente del database:

  • I file del database MySQL sono distribuiti su più volumi.
  • Stai utilizzando utilità RAID software Linux, ad esempio mdadm.
  • Hai separato le posizioni di archiviazione configurate di MySQL nei file system su dischi diversi.

Per creare uno snapshot che non richiede il recupero dopo il ripristino di uno snapshot, completa i seguenti passaggi:

  1. Blocca temporaneamente l'accesso in scrittura al database MySQL.
  2. Svuota 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 snapshot.

  4. Per gli scenari con più dischi, dopo aver svuotato la cache a livello di MySQL, esegui i comandi sync e fsfreeze sul server per svuotare la cache di 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 devi continuare a bloccare il disco, perché Hyperdisk acquisisce rapidamente la visualizzazione point-in-time e poi può elaborare in modo asincrono tutti i passaggi successivi di copia dello spazio di archiviazione. Se hai bisogno di questi passaggi per la coerenza degli snapshot e vuoi rimuovere questo impatto di scrittura sul database primario, puoi anche eseguire il backup su una replica del database anziché sul database primario.

Passaggi successivi