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 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 per la configurazione tengono conto del fatto che i workload MySQL vengono spesso utilizzati in sistemi con molte letture, 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 workload sensibili alle prestazioni, potrebbe essere necessario modificare le configurazioni in base alle tue esigenze. Ti consigliamo di utilizzare questa guida come punto di partenza per l'implementazione e poi di eseguire test con il tuo workload 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 più recenti, se 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 carichi di lavoro 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 nuova generazione di Compute Engine per ottimizzare il costo totale mantenendo prestazioni solide, senza le solide garanzie offerte da C4, C4A, C3 e C3D. Per maggiori dettagli, consulta Gestione dinamica delle risorse 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 vuoi ottenere un elevato numero di 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 in termini di 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 workload MySQL, determina il working set del tuo workload, quindi scegli la forma di 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 working set di grandi dimensioni, 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 i 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 famiglie di VM Compute Engine recenti. Riteniamo che Hyperdisk bilanciato sia la soluzione 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 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 bilanciato, 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 ai file di dati e agli indici di 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 questa situazione 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 ha almeno 3000 input/output al secondo (IOPS) e 140 MiBps di throughput. Questo è sufficiente per i volumi di avvio di base dei workload MySQL e 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 workload.
  2. Misura l'utilizzo esistente.Se il tuo database è già in esecuzione in un altro ambiente, registra le operazioni di IOPS al secondo 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 ed eventi di manutenzione normali, 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 prestazioni 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 velocità effettiva. 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 Balanced, puoi utilizzare uno dei seguenti metodi per combinare più dischi Hyperdisk Balanced:

  • Esegui l'upgrade a Hyperdisk Extreme
  • Utilizza un altro meccanismo RAID (redundant array of independent disks) software, 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 alle prestazioni dei workload di elaborazione analitica online (OLAP) che eseguono unioni complesse di grandi dimensioni che non possono essere memorizzate nella RAM e vengono salvate 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 dei volumi per configurare l'SSD locale come cache per i dati archiviati su un 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à e ripristino di emergenza on-premise:

Per ulteriori informazioni sulla configurazione di queste funzionalità con MySQL per Compute Engine, consulta la sezione alta affidabilità 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 durevole, ma i carichi di lavoro MySQL spesso li utilizzano per archiviare tablespace temporanei.

Per informazioni sull'utilizzo delle unità SSD locali per scalare i database MySQL, consulta Ridimensionamento dinamico dei dischi, 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 relative alle prestazioni, come l'utilizzo di CPU e memoria, la larghezza di banda di rete e le prestazioni 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 delle 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 pool di buffer.MySQL utilizza il pool di buffer per migliorare le prestazioni di lettura memorizzando i dati nella RAM, riducendo gli accessi al disco. Per impostazione predefinita, le dimensioni del pool di buffer di MySQL sono 128 MiB, troppo piccole 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 working set a cui accede la tua applicazione nel database. In genere, questa operazione prevede i 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 la dimensione del buffer pool sulla VM in modo che occupi la maggior parte della RAM disponibile.

  • Attiva il buffer doublewrite.MySQL ha un buffer doublewrite che aiuta a proteggere dai torn writes, una modalità di errore in cui una scrittura che copre più blocchi sul disco potrebbe essere eseguita solo parzialmente se si verifica un guasto 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 e può aumentare la latenza delle transazioni. Google Cloud Hyperdisk offre una protezione dalla scrittura incompleta integrata. Se utilizzi MySQL per scrivere direttamente in un file system ext4 in esecuzione su Hyperdisk, puoi disattivare il buffer doublewrite, a condizione di aver configurato correttamente il file system e i livelli software intermedi.

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

  • Esecuzione dell'istanza MySQL all'interno di container, inclusi 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.
  • Memorizzare i file MySQL in una configurazione RAID (Redundant Array of Independent Disks) che causa lo striping del disco, inclusi mdadm per Linux o Spazi di archiviazione e Spazi di archiviazione diretta per Windows.
  • Memorizza i file MySQL su un gestore di volumi, incluso Logical Volume Manager (LVM) per Linux o Storage Spaces e Storage Spaces Direct per Windows.

  • Archiviazione dei file MySQL su Hyperdisk con un'unità SSD (Solid State Drive) locale configurata come cache, utilizzando lvmcache, dm-cache o bcache per Linux o Storage Spaces 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 verificare che una determinata configurazione sia sicura.

(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 maggiore di 2 di 16 KiB. In questo modo, le scritture di MySQL non verranno suddivise in I/O separati 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 affidabilità (HA) e una soluzione di backup

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

Le soluzioni HA in genere 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 affidabilità (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 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 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 quella principale, 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 in 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 primaria 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 High Availability, 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 High Availability. Quando configuri Hyperdisk Balanced High Availability, 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 contribuiscono a prevenire la perdita di dati durante errori come l'eliminazione accidentale dei dati, gli attacchi ransomware e i disastri naturali. Puoi anche utilizzarli come archiviazione a freddo per i requisiti di conformità e controllo. 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 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 archiviazione

Per i backup a livello di archiviazione, ti consigliamo di utilizzare i prodotti Hyperdisk per creare snapshot, clonare e acquisire in altro modo una visualizzazione point-in-time 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 del disco standard e di archivio di Hyperdisk. Gli snapshot di dischi standard e di archiviazione 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 ripristino 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 è necessario continuare a bloccare il disco, perché Hyperdisk acquisisce rapidamente la visualizzazione point-in-time e può quindi elaborare in modo asincrono tutti i passaggi di copia dello spazio di archiviazione successivi. Se hai bisogno di questi passaggi per la coerenza dello 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