{"id":74327,"date":"2020-03-16T08:42:33","date_gmt":"2020-03-16T05:42:33","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/tonkoe-rezervirovanie-fajlovyh-sistem-linux-kak-sozdavat-rabochie-kopii-trehterabajtnoj-subd-mysql-za-20-sekund"},"modified":"2020-03-16T08:42:33","modified_gmt":"2020-03-16T05:42:33","slug":"tonkoe-rezervirovanie-fajlovyh-sistem-linux-kak-sozdavat-rabochie-kopii-trehterabajtnoj-subd-mysql-za-20-sekund","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/tonkoe-rezervirovanie-fajlovyh-sistem-linux-kak-sozdavat-rabochie-kopii-trehterabajtnoj-subd-mysql-za-20-sekund","title":{"rendered":"Riserva sottile dei file system Linux. Come creare copie di lavoro di un database MySQL da tre terabyte in 20 secondi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Riserva sottile dei file system Linux. Come creare copie di lavoro di un database MySQL da tre terabyte in 20 secondi\" src=\"\/wp-content\/uploads\/2020\/03\/7502785a78bd6f069913e97829ff2f63.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Mi chiamo Yuri, sono il responsabile del team di amministrazione di sistema in Citymobil. Oggi condivider\u00f2 la mia esperienza con la tecnologia del thin provisioning dei file system Linux e spiegher\u00f2 come pu\u00f2 essere applicata nei processi CI\/CD aziendali. Analizzeremo la situazione in cui, per i test automatici del codice durante il suo deploy in produzione, abbiamo urgentemente bisogno di copie di database MySQL, il pi\u00f9 simili possibile alla versione \"live\", disponibili sia in lettura che in scrittura.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3 id=\"vvedenie-zachem-davat-vrednye-sovety\">Introduzione: perch\u00e9 dare consigli dannosi?<\/h3>\n<p><\/p>\n<p>Una domanda legittima, dato che esistono meccanismi collaudati per la migrazione degli schemi di database negli ambienti di test. Perch\u00e9 mai portare un database principale non sharded a tali volumi? E per i test non sono necessari tutti i dati. Prover\u00f2 a spiegare.<\/p>\n<p><\/p>\n<p>Circa un anno fa, a seguito della crescita attiva del nostro aggregatore di taxi (nel 2018 siamo cresciuti di circa 15 volte per numero di corse completate), sono aumentati i volumi di dati, il carico sui server e la frequenza dei rollout. Ci siamo trovati nella seguente situazione:<\/p>\n<p><\/p>\n<ul>\n<li>Il database principale MySQL \u00e8 cresciuto fino a circa 1000 tabelle con un volume totale di 2,5 TB e continuava a crescere.<\/li>\n<li>Non c'era la possibilit\u00e0 di sharding rapido e di distribuzione del database. Questo era impedito dal vecchio approccio \"scrivo nel database quello che voglio e come voglio\", con una miriade di JOIN e dipendenze interne delle tabelle.<\/li>\n<li>Non c'era un meccanismo per la migrazione dello schema del database negli ambienti di test.<\/li>\n<li>Non c'era un testing automatico del codice durante il rollout in produzione.<\/li>\n<\/ul>\n<p><\/p>\n<p>Volevamo risolvere quest'ultima problematica nel minor tempo possibile. Erano gi\u00e0 stati scritti test Postman per verificare il principale monolite PHP, ma mancava un database attuale. Inoltre, non potevamo creare una replica di notte, renderla master e metterla a disposizione durante il giorno: il grande numero di rollout e modifiche, incluse quelle ai dati e allo schema del database, avrebbe reso l'ambiente non funzionante gi\u00e0 a met\u00e0 giornata. Inoltre, limitare i rollout solo all'orario lavorativo non sarebbe stato efficace. <\/p>\n<p><\/p>\n<p>Tuttavia, l'obiettivo \u00e8 stato raggiunto: abbiamo ottenuto il primo ambiente di lavoro gi\u00e0 dopo due settimane. Nel corso dell'anno ha subito molte modifiche e continua a essere utilizzato.<\/p>\n<p><\/p>\n<p>Di seguito descriver\u00f2 in dettaglio tutti i passaggi e le fasi di sviluppo della nostra soluzione. Vi assicurer\u00f2 che questo metodo merita di esistere.<\/p>\n<p><\/p>\n<p><strong>Che cos'\u00e8 il 'thin provisioning'?<\/strong><br \/>\nSi tratta di una tecnologia hardware o software (altro nome: sparse volumes), che consente di allocare una quantit\u00e0 di risorse necessarie superiore a quella effettivamente disponibile. La quantit\u00e0 allocata deve soddisfare i criteri di just-enough (tanto quanto serve) e just-in-time (nel tempo necessario). Il thin provisioning \u00e8 principalmente utilizzato in diversi sistemi di archiviazione dati per fornire spazio su disco in volume necessario, superiore a quello effettivamente disponibile. La tecnologia \u00e8 supportata da vari file system, come LVM2, ZFS, BTRFS. \u00c8 ampiamente usata nei hypervisor di virtualizzazione. Per noi, il thin provisioning ha consentito di creare rapidamente, a partire dagli snapshot della partizione principale contenente i dati, cos\u00ec tante copie di questa partizione quante ne avevamo bisogno (la directory dei dati del database MySQL).<\/p>\n<p><\/p>\n<h3 id=\"pervyy-stend-tehnologiya-thin-lvm\">Primo ambiente, tecnologia Thin LVM<\/h3>\n<p><\/p>\n<p>Questo capitolo potrebbe essere intitolato 'Come creare snapshot estremamente veloci di grandi volumi di dati utilizzando <noindex><a rel=\"nofollow\" href=\"http:\/\/man7.org\/linux\/man-pages\/man7\/lvmthin.7.html\">Thin LVM<\/a><\/noindex>, riducendo la stabilit\u00e0 del file system e del database MySQL a livelli inaccettabili'. <\/p>\n<p><\/p>\n<p>Poich\u00e9 avevamo gi\u00e0 utilizzato LVM per costruire le partizioni principali del sistema operativo, abbiamo deciso di partire proprio da essa. Prima di tutto, avevamo bisogno di una macchina fisica dedicata: una replica del nostro database MySQL principale, dalla quale potevamo creare a richiesta uno snapshot della replica e avviarlo come un'istanza separata di MySQL. Durante il periodo di test, abbiamo autorizzato l'uso di operazioni modificative su questa istanza e al termine dei test la abbiamo tranquillamente eliminata. La configurazione del server era la seguente:<\/p>\n<p><\/p>\n<ul>\n<li>2 x Intel Silver 4114 (10\u00d72,2 GHz HT)<\/li>\n<li>8 x 32 GB DDR4 <\/li>\n<li>8 x 1920 GB Intel SSD in RAID con controller Adaptec in RAID-10<\/li>\n<\/ul>\n<p><\/p>\n<p>Si potrebbe scrivere un articolo a parte sulla scelta tra controller RAID e RAID software MD. Posso dire solo che la nostra scelta \u00e8 stata influenzata da due fattori:<\/p>\n<p><\/p>\n<ul>\n<li>Al momento in cui \u00e8 stato posto il problema, avevamo installato tutti i database su controller RAID, quindi si pu\u00f2 dire che sia stata una scelta storica. <\/li>\n<li>La differenza nelle prestazioni nei test sintetici del file system e nei test con diverse operazioni in MySQL era minima. <\/li>\n<\/ul>\n<p><\/p>\n<p>Abbiamo suddiviso il RAID-10 risultante: abbiamo creato un'unica Volume Group (VG) per l'intero spazio (con costi aggiuntivi di circa 6,7 GB) e abbiamo creato una partizione logica (Logical Volume, LV) di 50 GB per il sistema. In una situazione normale, utilizzeremmo il resto dello spazio per la partizione di MySQL. Tuttavia, avevamo bisogno di un backup sottile, quindi inizialmente abbiamo creato quello che viene chiamato un pool, all'interno del quale abbiamo creato una partizione per \/var\/lib\/mysql di 3,5 TB (in base ai volumi previsti del DB):<\/p>\n<p><\/p>\n<pre><code class=\"bash\">lvcreate -l 100%FREE -T vga\/thin\nlvcreate -V 3.5T -T vga\/thin -n mysql<\/code><\/pre>\n<p><\/p>\n<p>Abbiamo formattato la partizione in ext4, l'abbiamo montata, registrato una replica e ottenuto l'ambiente iniziale. Poi abbiamo creato un'API che deve generare snapshot, avviare un'istanza di MySQL su una porta specificata ed eliminare l'istanza creata. Poich\u00e9 utilizziamo esclusivamente chiamate di sistema, abbiamo scelto di scrivere gli script in bash standard, e per l'integrazione API HTTP \u2192 bash abbiamo implementato una soluzione open source <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/phonkee\/goexpose\">goexpose<\/a><\/noindex>, scritta in Go. <\/p>\n<p><\/p>\n<p>Un giorno condivideremo i nostri script bash in open source, ma per ora descriver\u00f2 semplicemente l'algoritmo principale:<\/p>\n<p><\/p>\n<p>Creazione dello snapshot principale snapmain:<\/p>\n<p><\/p>\n<ol>\n<li>Ferma la replica principale.<\/li>\n<li>Imposta un blocco sulle operazioni con lo snapshot snapmain.<\/li>\n<li>Crea un nuovo snapshot snapmain.<\/li>\n<li>Avvia MySQL e rimuovi il blocco.<\/li>\n<\/ol>\n<p><\/p>\n<p>Creazione di un DB su una porta casuale dallo snapmain:<\/p>\n<p><\/p>\n<ol>\n<li>Imposta un blocco su un'istanza specifica di DB (porta).<\/li>\n<li>Controlla la presenza del blocco sulla creazione dello snapshot principale. Se \u00e8 presente, aspetta e ricontrolla ogni 5 secondi.<\/li>\n<li>Verifica se esiste una vecchia partizione LV per l'istanza.<br \/>\n3.1 Se esiste, fermiamo l'istanza MySQL con kill -9 e eliminiamo la partizione LV.<\/li>\n<li>Crea un nuovo istanza dallo snapmain.<\/li>\n<li>Prepara e monta le directory per quest'istanza.<\/li>\n<li>Rimuovi i segni di slave (file) e avvia l'istanza di MySQL.<\/li>\n<li>Trasformala in master.<\/li>\n<li>Rimuovi il blocco.<\/li>\n<\/ol>\n<p><\/p>\n<p>Eliminazione di un DB su una porta casuale:<\/p>\n<p><\/p>\n<ol>\n<li>Imposta un blocco su un'istanza specifica di DB (porta).<\/li>\n<li>Fermiamo l'istanza MySQL usando kill -9.<\/li>\n<li>Smontiamo le directory.<\/li>\n<li>Eliminiamo la partizione LV e rimuoviamo il blocco.<\/li>\n<\/ol>\n<p><\/p>\n<p>Ecco alcuni comandi per clonare le partizioni della nuova istanza di DB:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">lvcreate -n stage_3307 -s vga\/snapmain\nlvchange -ay -K vga\/stage_3307\nmount -o noatime,nodiratime,data=writeback \/dev\/mapper\/vga-stage_3307 \/mnt\/stage_3307<\/code><\/pre>\n<p><\/p>\n<p>Ora parler\u00f2 del principale problema che abbiamo affrontato nell'uso del backup sottile. Ci siamo scontrati con le prestazioni degli SSD. Questo \u00e8 successo a causa delle peculiarit\u00e0 di Thin LVM: opera a livello dispositivo con chunk di basso livello di default di 4 MB. Come si \u00e8 presentato:<\/p>\n<p><\/p>\n<ol>\n<li>Crea uno snapshot dalla partizione principale \/var\/lib\/mysql.<\/li>\n<li>Avvia la replica per raggiungere il master.<\/li>\n<li>Qualsiasi modifica nelle tabelle della replica fa s\u00ec che vengano mantenuti i vecchi chunk di dati invariati nella partizione dello snapshot.<\/li>\n<li>Qualsiasi modifica nell'istanza di test avviata costringe a mantenere i vecchi chunk di dati invariati nella partizione dello snapshot clonata per quest'istanza.<\/li>\n<li>Otteniamo un carico delle operazioni di input-output al 100% sul dispositivo, rallentando qualsiasi operazione e causando il graduale ritardo della replica.<\/li>\n<li>Alla fine della giornata lavorativa, otteniamo un ambiente indietro di alcune ore.<\/li>\n<\/ol>\n<p><\/p>\n<p>Ecco come abbiamo combattuto per ottenere risultati pi\u00f9 ragionevoli (punti principali):<\/p>\n<p><\/p>\n<p>Controller RAID:<\/p>\n<p><\/p>\n<ul>\n<li>Disattivato di default tutti i tipi di caching. <\/li>\n<li>Impostato writeback (quando i dati vengono memorizzati nel buffer, la scrittura termina prima che il salvataggio effettivo su disco sia completato).<\/li>\n<\/ul>\n<p><\/p>\n<p>File system:<\/p>\n<p><\/p>\n<ul>\n<li>Nella directory di montaggio \/var\/lib\/mysql abbiamo specificato <em>noatime,nodiratime,data=writeback<\/em><\/li>\n<li>Disattivato il journaling ext4 usando tune2fs.<\/li>\n<\/ul>\n<p><\/p>\n<p>MySQL:<\/p>\n<p><\/p>\n<ul>\n<li>Impostato <em>innodb_flush_method = O_DSYNC<\/em> (aumentato la velocit\u00e0 di scrittura, riducendo cos\u00ec l'affidabilit\u00e0).<\/li>\n<li>Disattivato il journaling, non ci servono i log.<\/li>\n<li>Impostato <em>innodb_buffer_pool_size = 4G<\/em> (pi\u00f9 \u00e8 piccolo il pool InnoDB, pi\u00f9 velocemente MySQL si spegner\u00e0 durante l'arresto, e pi\u00f9 velocemente creeremo lo snapshot).<\/li>\n<\/ul>\n<p><\/p>\n<p>Questa non \u00e8 affatto una lista completa, soprattutto per MySQL. Tuttavia, le altre modifiche sono minori e spesso non applicabili in modo preciso. Ad esempio, nel tentativo di alleggerire i dischi, abbiamo anche spostato <em>innodb_parallel_doublewrite_path<\/em> in \/dev\/shm, il che in alcuni casi, all'avvio di un'istanza non correttamente terminata, ci ha permesso di risparmiare fino a 5 secondi.<\/p>\n<p><\/p>\n<p>Perch\u00e9 fermiamo MySQL prima di fare uno snapshot? Possiamo anche estrarlo da una replica funzionante. \u00c8 vero, ma la nuova istanza di DB basata su questo snapshot sar\u00e0 considerata danneggiata di default e richieder\u00e0 una scansione completa all'avvio. Fermare la replica \u00e8 sicuramente pi\u00f9 veloce, anche se alla fine rappresenta l'operazione pi\u00f9 lunga dell'intero processo.<\/p>\n<p><\/p>\n<p>Di conseguenza, abbiamo ottenuto tempistiche pi\u00f9 accettabili e un ambiente pronto all'uso. Anche se, come dimostra il grafico pi\u00f9 eloquente del ritardo della replica principale, la situazione \u00e8 ancora lontana dall'essere ideale:<br \/>\n<img decoding=\"async\" alt=\"Riserva sottile dei file system Linux. Come creare copie di lavoro di un database MySQL da tre terabyte in 20 secondi\" src=\"\/wp-content\/uploads\/2020\/03\/9bb7bb7d9abfea124a75616deec57f05.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Tra gli altri svantaggi, va notata la quasi impossibilit\u00e0 di monitorare il pool Thin LVM: oltre alle funzioni standard di sistema come iostat, non \u00e8 possibile capire, ad esempio, quale elemento del pool sta attualmente generando il maggior carico sul file system.<\/p>\n<p><\/p>\n<p>Va sottolineato un grande svantaggio legato all'ottimizzazione descritta sopra: abbiamo ottenuto un ambiente YOLO. Circa una volta ogni uno o due mesi, ext4 non ha retto tali maltrattamenti e si \u00e8 rotta irreparabilmente, richiedendo una riformattazione e un nuovo caricamento della replica. Guadagnando in velocit\u00e0, abbiamo compromesso irrimediabilmente la stabilit\u00e0.<\/p>\n<p><\/p>\n<p>Quali metriche tenere sotto controllo durante l'uso del Thin LVM:<\/p>\n<p><\/p>\n<ul>\n<li>Percentuale di dati del pool sottile<\/li>\n<li>Percentuale di metadati del pool sottile<\/li>\n<\/ul>\n<p><\/p>\n<p>Se lo spazio dati esaurito verr\u00e0 gestito dal nostro stand (basta pulire i dischi), lo spazio esaurito per i metadati porter\u00e0 al completo collasso del pool e alla necessit\u00e0 di ricrearlo da zero.<\/p>\n<p><\/p>\n<p>Il file system all'interno del pool si frammenta notevolmente nel tempo. Consiglio di eseguire quotidianamente il comando tramite cron <em>fstrim -v \/var\/lib\/mysql<\/em>.<\/p>\n<p><\/p>\n<p>Risultati intermedi:<\/p>\n<p><\/p>\n<ul>\n<li>La tecnologia \u00e8 facilmente applicabile, proprio come l'LVM stesso, e non richiede particolare qualificazione dell'ingegnere.<\/li>\n<li>Si adatta bene a database di piccole dimensioni e non eccessivamente carichi. Maggiore \u00e8 la dimensione del database, pi\u00f9 chunk vengono spostati nel file system all'interno del pool, aumentando il carico sui dischi.<\/li>\n<li>Per la nostra esigenza, abbiamo iniziato a cercare altre soluzioni, di cui si parler\u00e0 nel prossimo capitolo.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"vtoroy-stend-tehnologiya-zfs\">Secondo stand, tecnologia ZFS<\/h3>\n<p><\/p>\n<p>Un tempo ebbi a che fare con il file system ZFS, ma allora ZFS funzionava bene solo sul suo sistema operativo nativo Solaris. Esisteva una versione portata su FreeBSD con un livello di implementazione sufficientemente buono. C'era anche un port incompleto su Linux, che pochi usavano. A causa della struttura di archiviazione dei dati B-tree (che \u00e8 la stessa utilizzata anche da InnoDB di MySQL), ZFS mostrava scarse performance su installazioni con un numero elevato di file. Questo, unito alla necessit\u00e0 di studiare la tecnologia prima dell'uso, ha a lungo escluso questa filesystem dalla mia pratica. Sono emersi ext4 e xfs, che sono diventati lo standard. Tuttavia, considerando che per il nostro scopo ZFS si adatta perfettamente, e che la versione per Linux, a giudicare dalle recensioni, \u00e8 diventata un prodotto assolutamente valido (anche se non \u00e8 completamente supportata, motivo per cui installare un sistema su ZFS da zero richiede varie magie), abbiamo deciso di provarla.<\/p>\n<p><\/p>\n<p>Per ovvi motivi, abbiamo scelto uno stand con configurazione analoga (eccetto il controller RAID). Abbiamo installato otto dischi SSD da 1920 GB. Non avevamo voglia di scrivere la nostra immagine di rete per il caricamento del server su una ZFS 'nuda', quindi abbiamo sottratto 50 GB da ogni disco e creato un MD RAID-10 per il sistema. Gli altri 1950 GB di ciascun disco sono stati uniti in un ZFS-analogo di RAID-10:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">zpool create zpool mirror \/dev\/sda2 \/dev\/sdb2 mirror \/dev\/sdc2 \/dev\/sdd2 mirror \/dev\/sde2 \/dev\/sdf2 mirror \/dev\/sdg2 \/dev\/sdh2<\/code><\/pre>\n<p><\/p>\n<p>Abbiamo creato partizioni per MySQL:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">zfs create zpool\/mysql\nzfs set compression=gzip zpool\/mysql\nzfs set recordsize=128k zpool\/mysql\nzfs set atime=off zpool\/mysql\nzfs create zpool\/mysql\/data\nzfs set recordsize=16k zpool\/mysql\/data\nzfs set primarycache=metadata zpool\/mysql\/data\nzfs set mountpoint=\/var\/lib\/mysql zpool\/mysql\/data<\/code><\/pre>\n<p><\/p>\n<p>Nota che abbiamo attivato la compressione dati gzip di default. Abbiamo molte risorse di CPU sul server e non vengono utilizzate completamente. Di conseguenza, 3 TB del nostro database si sono ridotti a 1,6 TB, e poich\u00e9 il collo di bottiglia, come nel caso precedente, \u00e8 rappresentato dalla massima performance dei dischi, meno dati abbiamo \u2014 meglio \u00e8, ottenendo fin dall'inizio un ottimo bonus da ZFS! Durante i picchi di carico, fino a 4 core vengono utilizzati per mantenere in funzione gzip, ma non ce ne preoccupiamo.<\/p>\n<p><\/p>\n<p>Successivamente, l'implementazione \u00e8 proceduta pi\u00f9 rapidamente. Abbiamo replicato le impostazioni della replica MySQL dallo stand LVM. Abbiamo dovuto investire del tempo nella riscrittura degli script tramite comandi ZFS, ma in generale gli algoritmi sono rimasti gli stessi. Ecco un esempio di creazione di uno snapshot:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">zfs set snapdir=visible zpool\/mysql\/data\nzfs create zpool\/stage_3307\nzfs clone zpool\/mysql\/data@snapmain zpool\/stage_3307\/data\nzfs set mountpoint=\/mnt\/stage_3307 zpool\/stage_3307\/data<\/code><\/pre>\n<p><\/p>\n<p>Per un ulteriore tuning: abbiamo spostato in memoria le partizioni ZFS con i metadati e i log l2arc e zil. Per la nostra esigenza, come si \u00e8 rivelato poi, questo era sovrabbondante, ma al momento abbiamo mantenuto questa ottimizzazione, cambiarla in futuro non \u00e8 difficile. Tra gli effetti negativi, occorre ricreare le aree di memoria corrispondenti dopo il riavvio del server. In questo modo, i dati non vengono persi. Estratto dello stato di zpool:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">logs\n      \/dev\/shm\/zil_slog.img  ONLINE       0     0     0\ncache\n      \/dev\/shm\/l2arc.img     ONLINE       0     0     0<\/code><\/pre>\n<p><\/p>\n<p>In questa configurazione abbiamo iniziato a testare lo stand e abbiamo ottenuto risultati eccellenti: con due istanze di database in funzione contemporaneamente (e una replica principale attiva) sugli snapshot abbiamo ottenuto un carico sui dischi del 50-60%.<\/p>\n<p><\/p>\n<p>Abbiamo risolto il nostro problema principale, come evidenziato nel grafico del ritardo di replica (rispetto al precedente grafico nella sezione Thin LVM):<br \/>\n<img decoding=\"async\" alt=\"Riserva sottile dei file system Linux. Come creare copie di lavoro di un database MySQL da tre terabyte in 20 secondi\" src=\"\/wp-content\/uploads\/2020\/03\/15df9283838a4662ff0f68accfde4089.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Oltre a questo, ci siamo notevolmente accelerati in tutte le operazioni: la creazione completa di uno snapshot con l'arresto e il riavvio della replica richiede fino a 40 secondi, mentre il deployment da uno snapshot di una nuova istanza MySQL richiede fino a 20 secondi. Questo soddisfa pi\u00f9 che adeguatamente noi e i nostri test di codice.<\/p>\n<p><\/p>\n<p>Risultati intermedi:<\/p>\n<p><\/p>\n<ul>\n<li>I risultati hanno pienamente soddisfatto la nostra necessit\u00e0 di ottenere una copia del database di produzione per il test del codice.<\/li>\n<li>La tecnologia richiede un apprendimento: \u00e8 necessario comprendere che cos'\u00e8 ZFS e come lavorarci.<\/li>\n<li>Non abbiamo verificato lo stato attuale di ZFS con un gran numero (da 1 milione) di piccoli file. Tuttavia, supponiamo che il problema persista, quindi non consiglierei questo file system per archiviazioni di file.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"chto-dalshe\">E ora?<\/h3>\n<p><\/p>\n<p>Non abbiamo bisogno di fare null'altro nel contesto dell'ambiente di test, il risultato ci soddisfa. Potremmo in futuro aggiungere al setup della replica dell'ambiente delle eccezioni di tabelle non necessarie per il test, riducendo ulteriormente il volume del database. Non abbiamo testato il sistema BTRFS e la sua implementazione della tecnologia thin provisioning. Tuttavia, questo non \u00e8 pi\u00f9 prioritario, poich\u00e9 l'obiettivo principale \u00e8 stato raggiunto. In generale, naturalmente, vogliamo allontanarci dall'approccio descritto sopra: implementare migrazioni funzionanti del database nell'ambiente di test, creare un contorno di test del database separato e occuparci dello sharding del database principale. Molte di queste cose stiamo gi\u00e0 concretizzando, di cui vi parleremo certamente in articoli futuri. <\/p>\n<p><\/p>\n<h3 id=\"itogi\">Risultati<\/h3>\n<p><\/p>\n<p>L'obiettivo iniziale \u00e8 stato raggiunto, sebbene in modo inusuale. Nelle conclusioni intermedie sono stati descritti i vantaggi e gli svantaggi di ciascuna delle tecnologie applicate, quindi decidiamo quale tecnologia utilizzare e quando:<\/p>\n<p><\/p>\n<ul>\n<li>Thin LVM \u2014 su database piccoli e quando non si vuole o non si ha tempo di studiare ZFS.<\/li>\n<li>ZFS \u2014 se si ha esperienza con essa o la possibilit\u00e0 di dedicare tempo allo studio in qualsiasi situazione. <\/li>\n<\/ul>\n<p><\/p>\n<p>A un livello pi\u00f9 alto, questo articolo non \u00e8 solo un confronto tra le tecnologie di due file system. L'idea principale che vorrei trasmettere e consolidare \u00e8 che non bisogna avere paura di pensare in modo non standard in situazioni critiche per il business e di adottare solo ricette pronte. Una volta avremmo potuto scuotere la testa a gran voce nel dipartimento tecnico e dire che l'obiettivo di creare copie di database da tre terabyte in meno di un minuto era impossibile, e che non avevamo bisogno di tecnologie rischiose, facciamo come si deve. Era possibile, ma avremmo perso circa sei mesi - un anno e molte trasferte di clienti (le trasferte sono il nostro principale indicatore di business) senza test e durante l'implementazione. Adottando un approccio non standard, abbiamo perso poco tempo sull'implementazione, acquisito esperienza in tecnologie nuove e dimenticate, e fornito test proprio nel momento in cui ne avevamo molto bisogno. Questo ha senza dubbio avuto un effetto positivo su tutti i nostri indicatori. La scelta \u00e8 sempre vostra, mentre noi continueremo a raccontare nel nostro blog delle attuali e future conquiste interessanti.<\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/492172\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u042e\u0440\u0438\u0439, \u044f \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c \u0433\u0440\u0443\u043f\u043f\u044b \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u043e\u0433\u043e \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 \u0421\u0438\u0442\u0438\u043c\u043e\u0431\u0438\u043b. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043f\u043e\u0434\u0435\u043b\u044e\u0441\u044c \u043e\u043f\u044b\u0442\u043e\u043c \u0440\u0430\u0431\u043e\u0442\u044b \u0441 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0435\u0439 \u0442\u043e\u043d\u043a\u043e\u0433\u043e \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f (thin provisioning) \u0444\u0430\u0439\u043b\u043e\u0432\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c Linux \u0438 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u0435\u0435 \u043c\u043e\u0436\u043d\u043e \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u0442\u044c \u0432 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0447\u0435\u0441\u043a\u0438\u0445 CI\/CD-\u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u0445 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438. \u041c\u044b \u0440\u0430\u0437\u0431\u0435\u0440\u0435\u043c \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u044e, \u043a\u043e\u0433\u0434\u0430 \u0434\u043b\u044f \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043a\u043e\u0434\u0430 \u043f\u0440\u0438 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0435 \u0435\u0433\u043e \u0432 production \u043d\u0430\u043c \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u0441\u0442\u0440\u0435\u0435 \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u044b \u043a\u043e\u043f\u0438\u0438 \u0411\u0414 MySQL, \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":74328,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-74327","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/tonkoe-rezervirovanie-fajlovyh-sistem-linux-kak-sozdavat-rabochie-kopii-trehterabajtnoj-subd-mysql-za-20-sekund\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0422\u043e\u043d\u043a\u043e\u0435 \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0444\u0430\u0439\u043b\u043e\u0432\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c Linux. \u041a\u0430\u043a \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u0440\u0430\u0431\u043e\u0447\u0438\u0435 \u043a\u043e\u043f\u0438\u0438 \u0442\u0440\u0435\u0445\u0442\u0435\u0440\u0430\u0431\u0430\u0439\u0442\u043d\u043e\u0439 \u0421\u0423\u0411\u0414 MySQL \u0437\u0430 20 \u0441\u0435\u043a\u0443\u043d\u0434 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/tonkoe-rezervirovanie-fajlovyh-sistem-linux-kak-sozdavat-rabochie-kopii-trehterabajtnoj-subd-mysql-za-20-sekund\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-03-16T05:42:33+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-03-16T05:42:33+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Thin provisioning dei file system Linux. Come creare copie funzionanti di un DBMS MySQL da tre terabyte in 20 secondi | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/tonkoe-rezervirovanie-fajlovyh-sistem-linux-kak-sozdavat-rabochie-kopii-trehterabajtnoj-subd-mysql-za-20-sekund","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0422\u043e\u043d\u043a\u043e\u0435 \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0444\u0430\u0439\u043b\u043e\u0432\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c Linux. \u041a\u0430\u043a \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u0440\u0430\u0431\u043e\u0447\u0438\u0435 \u043a\u043e\u043f\u0438\u0438 \u0442\u0440\u0435\u0445\u0442\u0435\u0440\u0430\u0431\u0430\u0439\u0442\u043d\u043e\u0439 \u0421\u0423\u0411\u0414 MySQL \u0437\u0430 20 \u0441\u0435\u043a\u0443\u043d\u0434 | ProHoster","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/tonkoe-rezervirovanie-fajlovyh-sistem-linux-kak-sozdavat-rabochie-kopii-trehterabajtnoj-subd-mysql-za-20-sekund","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-16T05:42:33+00:00","article:modified_time":"2020-03-16T05:42:33+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"74327","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:16:23","updated":"2022-10-01 23:42:57","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/74327","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=74327"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/74327\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/74328"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=74327"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=74327"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=74327"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}