{"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":"Backup efficiente 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=\"Backup efficiente 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 gruppo di amministrazione di sistema in SitiMobil. Oggi condivider\u00f2 la mia esperienza con la tecnologia di thin provisioning dei file system Linux e spiegher\u00f2 come pu\u00f2 essere applicata nei processi CI\/CD tecnologici dell'azienda. Analizzeremo la situazione in cui, per il test automatico del codice durante la consegna in produzione, abbiamo bisogno il prima possibile di copie del database MySQL, il pi\u00f9 simili possibile alla versione \"live\", disponibili per la lettura e la 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>\u00c8 una domanda legittima, poich\u00e9 esistono meccanismi collaudati per le migrazioni degli schemi del database negli ambienti di test. Perch\u00e9 portare un database relazionale principale non sharded a tali volumi? E per il testing non sono necessari tutti i dati. Cercher\u00f2 di spiegare.<\/p>\n<p><\/p>\n<p>Circa un anno fa, a causa della rapida crescita del nostro aggregatore taxi (nel 2018 siamo aumentati di circa 15 volte in base alle corse completate), sono aumentati i volumi di dati, il carico sui server e la frequenza dei deploy. Ci siamo trovati nella seguente situazione:<\/p>\n<p><\/p>\n<ul>\n<li>Il database MySQL principale \u00e8 aumentato 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 distribuire il database. Questo non era possibile a causa del vecchio approccio \"scrivo nel database quello che voglio e come voglio\", con un sacco di JOIN e dipendenze interne tra le tabelle.<\/li>\n<li>Non c'era un meccanismo per migrare lo schema del database negli ambienti di test.<\/li>\n<li>Non c'era testing automatico del codice durante il deploy in produzione.<\/li>\n<\/ul>\n<p><\/p>\n<p>L'ultimo problema volevo risolverlo il prima possibile. Erano gi\u00e0 stati scritti test Postman per verificare il principale monolite PHP, ma mancava un database aggiornato. Allo stesso tempo, non potevamo creare di notte una replica, farla diventare master e metterla a disposizione durante il giorno: il numero molto elevato di deploy e modifiche, inclusi i dati e lo schema del database, avrebbe reso l'ambiente non funzionante gi\u00e0 a met\u00e0 giornata. Inoltre, limitare i deploy solo a ore lavorative sarebbe stato inefficace. <\/p>\n<p><\/p>\n<p>Tuttavia, il compito \u00e8 stato svolto: abbiamo ottenuto il primo ambiente di produzione operativo gi\u00e0 dopo due settimane. Nel corso dell'anno passato ha subito molte modifiche e continua ad essere utilizzato.<\/p>\n<p><\/p>\n<p>Di seguito descriver\u00f2 nei dettagli tutti i passaggi e le fasi di sviluppo della nostra soluzione. Vi renderete conto che questo metodo merita di esistere.<\/p>\n<p><\/p>\n<p><strong>Che cos'\u00e8 il \"thin provisioning\"?<\/strong><br \/>\nQuesta \u00e8 una tecnologia hardware o software (altra denominazione \u2014 volumi sparsi), che permette di allocare una maggiore quantit\u00e0 di risorse richieste rispetto a quelle disponibili. L'allocazione deve soddisfare i criteri just-enough (quanto basta) e just-in-time (nel tempo necessario). Fondamentalmente, il thin provisioning \u00e8 utilizzato in vari sistemi di archiviazione, al fine di fornire spazio su disco in volumi necessari che superano quelli effettivamente disponibili. La tecnologia \u00e8 supportata da vari file system, ad esempio, LVM2, ZFS, BTRFS. \u00c8 ampiamente utilizzata negli hypervisor di virtualizzazione. Il thin provisioning ci ha permesso di creare rapidamente quante pi\u00f9 copie di una partizione principale dati dal suo snapshot, quanto necessario (directory dati del DBMS MySQL).<\/p>\n<p><\/p>\n<h3 id=\"pervyy-stend-tehnologiya-thin-lvm\">Primo stand, tecnologia Thin LVM<\/h3>\n<p><\/p>\n<p>Questa sezione pu\u00f2 essere anche intitolata \"Come realizzare snapshot estremamente veloci di grandi volumi di dati usando <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 DBMS 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. Per iniziare, avevamo bisogno di una macchina fisica separata \u2014 una replica del nostro database MySQL principale, su cui potevamo creare snapshot della replica su richiesta e avviarlo come una istanza separata di MySQL. Durante il periodo di test, abbiamo consentito operazioni modificanti su questa istanza, e al termine dei test l'abbiamo eliminata con successo. 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-controller Adaptec in RAID-10<\/li>\n<\/ul>\n<p><\/p>\n<p>Potremmo scrivere un articolo separato sulla scelta tra un controller RAID e un RAID software MD. Dico solo che la nostra scelta \u00e8 stata influenzata da due fattori:<\/p>\n<p><\/p>\n<ul>\n<li>All'epoca in cui abbiamo posto la questione, installavamo tutti i DBMS su controller RAID, quindi si pu\u00f2 dire che \u00e8 stata una scelta storica. <\/li>\n<li>La differenza di performance nei test sintetici del file system e nei test con varie operazioni in MySQL era minima. <\/li>\n<\/ul>\n<p><\/p>\n<p>Abbiamo suddiviso il RAID-10 ottenuto: abbiamo creato un'unica Volume Group (VG) per l'intero volume (con costi aggiuntivi di circa 6,7 GB) e abbiamo creato una partizione logica (Logical Volume, LV) per il sistema di 50 GB. In una situazione normale, riserviamo il resto dello spazio per la partizione con MySQL. Ma avevamo bisogno di un'allocazione fine, quindi inizialmente abbiamo creato un pool, all'interno del quale abbiamo creato una partizione per \/var\/lib\/mysql di 3,5 TB (basata sulle dimensioni previste 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, abbiamo scritto una replica e ottenuto l'ambiente iniziale. Poi abbiamo creato un'API che deve generare snapshot, avviare un'istanza di MySQL su una porta specifica e rimuovere l'istanza creata. Poich\u00e9 utilizziamo esclusivamente chiamate di sistema, abbiamo scelto come linguaggio per la scrittura degli script il bash ordinario, e per la connessione 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 pubblicheremo 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>Fermiamo la replica principale.<\/li>\n<li>Imponiamo un blocco sulle operazioni con lo snapshot snapmain.<\/li>\n<li>Creiamo un nuovo snapshot snapmain.<\/li>\n<li>Avviamo MySQL e rimuoviamo il blocco.<\/li>\n<\/ol>\n<p><\/p>\n<p>Creazione di un DB su una porta arbitraria da snapmain:<\/p>\n<p><\/p>\n<ol>\n<li>Imponiamo un blocco su un'istanza specifica di DB (porta).<\/li>\n<li>Controlliamo se esiste un blocco per la creazione dello snapshot principale. Se esiste, attendiamo e ricontrolliamo ogni 5 secondi.<\/li>\n<li>Controlliamo se esiste una vecchia partizione LV dell'istanza.<br \/>\n3.1 Se esiste, fermiamo l'istanza di MySQL usando kill -9 e rimuoviamo la partizione LV.<\/li>\n<li>Creiamo una nuova istanza da snapmain.<\/li>\n<li>Prepariamo e montiamo le directory per questa istanza.<\/li>\n<li>Rimuoviamo i segni di slave (file) e avviamo l'istanza di MySQL.<\/li>\n<li>La rendiamo master.<\/li>\n<li>Rimuoviamo il blocco.<\/li>\n<\/ol>\n<p><\/p>\n<p>Cancellazione del DB su una porta arbitraria:<\/p>\n<p><\/p>\n<ol>\n<li>Imponiamo un blocco su un'istanza specifica di DB (porta).<\/li>\n<li>Terminare l'istanza di MySQL usando kill -9.<\/li>\n<li>Smontiamo le directory.<\/li>\n<li>Rimuoviamo la partizione LV e rimuoviamo il blocco.<\/li>\n<\/ol>\n<p><\/p>\n<p>Esempio di 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 vi parler\u00f2 del problema principale che abbiamo incontrato utilizzando il thin provisioning. Ci siamo scontrati con le prestazioni degli SSD. Questo \u00e8 successo a causa delle caratteristiche del Thin LVM: funziona fondamentalmente a livello di dispositivo con chunk a basso livello di default da 4 MB. Ecco come si presentava:<\/p>\n<p><\/p>\n<ol>\n<li>Creiamo uno snapshot dalla partizione principale \/var\/lib\/mysql.<\/li>\n<li>Avviamo la replica per recuperare il master.<\/li>\n<li>Qualsiasi modifica nelle tabelle della replica costringe a mantenere i vecchi chunk di dati invariati nella sezione dello snapshot.<\/li>\n<li>Qualsiasi modifica nell'esemplare di test attivo costringe a mantenere i vecchi chunk di dati invariati nella sezione dello snapshot clonato per questo esemplare.<\/li>\n<li>Otteniamo un carico di operazioni di input-output al 100% sul dispositivo, un rallentamento di qualsiasi operazione e un progressivo distacco della replica.<\/li>\n<li>Alla fine della giornata lavorativa abbiamo un'istanza in ritardo di diverse ore.<\/li>\n<\/ol>\n<p><\/p>\n<p>Come abbiamo affrontato questo per ottenere un risultato pi\u00f9 ragionevole (punti principali):<\/p>\n<p><\/p>\n<p>Controller RAID:<\/p>\n<p><\/p>\n<ul>\n<li>Abbiamo disattivato tutte le forme di caching di default. <\/li>\n<li>Abbiamo impostato il writeback (quando i dati vengono memorizzati nel buffer, la scrittura termina prima che il salvataggio effettivo su disco venga eseguito).<\/li>\n<\/ul>\n<p><\/p>\n<p>File system:<\/p>\n<p><\/p>\n<ul>\n<li>Nel punto di montaggio \/var\/lib\/mysql abbiamo indicato <em>noatime,nodiratime,data=writeback<\/em><\/li>\n<li>Abbiamo disattivato il journaling ext4 con tune2fs.<\/li>\n<\/ul>\n<p><\/p>\n<p>MySQL:<\/p>\n<p><\/p>\n<ul>\n<li>Abbiamo specificato <em>innodb_flush_method = O_DSYNC<\/em> (aumentando la velocit\u00e0 di scrittura, aumentando cos\u00ec l'affidabilit\u00e0).<\/li>\n<li>Abbiamo disattivato il journaling, non ci servono i log.<\/li>\n<li>Abbiamo specificato <em>innodb_buffer_pool_size = 4G<\/em> (minore \u00e8 la dimensione del pool InnoDB, pi\u00f9 velocemente MySQL si fermer\u00e0 al momento dell'arresto e pi\u00f9 rapidamente creeremo lo snapshot).<\/li>\n<\/ul>\n<p><\/p>\n<p>Questa non \u00e8 affatto una lista completa, specialmente per MySQL. Tuttavia, le altre modifiche sono minori e spesso non applicabili sempre e in modo preciso. Ad esempio, nel tentativo di alleggerire i dischi, abbiamo persino spostato <em>innodb_parallel_doublewrite_path<\/em> in \/dev\/shm, il che in alcuni casi, in fase di avvio di un'istanza non terminata correttamente, ci ha fatto risparmiare fino a 5 secondi.<\/p>\n<p><\/p>\n<p>Perch\u00e9 fermiamo MySQL prima di fare uno snapshot? Infatti, possiamo scattarlo da una replica in esecuzione. \u00c8 vero, solo che il nuovo esemplare del DB su questo snapshot sar\u00e0 considerato danneggiato di default e richieder\u00e0 una scansione completa all'avvio. Fermare la replica \u00e8 sicuramente pi\u00f9 veloce, anche se alla fine risulta essere l'operazione pi\u00f9 lunga dell'intero processo.<\/p>\n<p><\/p>\n<p>Di conseguenza, abbiamo ottenuto tempistiche pi\u00f9 accettabili e uno stand pronto all'uso. Tuttavia, come si pu\u00f2 vedere dall'eloquente grafico dei ritardi di replicazione della replica principale, la situazione \u00e8 ancora lontana dall'ideale:<br \/>\n<img decoding=\"async\" alt=\"Backup efficiente 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 segnalata la quasi impossibilit\u00e0 di monitorare il pool Thin LVM: oltre alle funzioni standard di sistema come iostat, \u00e8 impossibile capire, ad esempio, quale elemento del pool sta attualmente causando il maggiore carico sul file system.<\/p>\n<p><\/p>\n<p>Vale la pena evidenziare un grande svantaggio legato all'ottimizzazione sopra descritta: abbiamo ottenuto uno stand YOLO. Circa una volta ogni uno-due mesi, ext4 non riusciva a sopportare tali maltrattamenti e si guastava in modo irreversibile, 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 di Thin LVM:<\/p>\n<p><\/p>\n<ul>\n<li>Percentuale di dati del pool thin<\/li>\n<li>Percentuale di metadati del pool thin<\/li>\n<\/ul>\n<p><\/p>\n<p>Se il nostro stand riesce a sopravvivere all'esaurimento dello spazio per i dati (\u00e8 sufficiente pulire i dischi), l'esaurimento dello spazio per i metadati porter\u00e0 a un 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. Raccomando di eseguire quotidianamente il comando tramite cron <em>fstrim -v \/var\/lib\/mysql<\/em>.<\/p>\n<p><\/p>\n<p>Resoconto intermedio:<\/p>\n<p><\/p>\n<ul>\n<li>La tecnologia \u00e8 facilmente applicabile, cos\u00ec come l'LVM stesso, e non richiede competenze particolari da parte dell'ingegnere.<\/li>\n<li>\u00c8 adatta a database di piccole dimensioni e non eccessivamente caricati. Pi\u00f9 il database \u00e8 piccolo, meno chunk vengono spostati nel file system all'interno del pool, e minore \u00e8 il carico sui dischi.<\/li>\n<li>Per il nostro compito abbiamo iniziato a cercare altre soluzioni, di cui parleremo 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>Molto tempo fa ho avuto a che fare con il file system ZFS, ma all'epoca ZFS funzionava bene sul suo sistema operativo nativo Solaris. Esisteva una versione portata su FreeBSD con un livello di implementazione abbastanza buono. C'era anche un port incompleto su Linux, che era poco utilizzato. A causa della struttura di archiviazione dei dati B-tree (che \u00e8 anche la stessa struttura utilizzata da InnoDB MySQL) ZFS ha mostrato prestazioni scarse in installazioni con un numero molto elevato di file. Tutto ci\u00f2, insieme alla necessit\u00e0 di approfondire la materia prima di utilizzarlo, ha fatto s\u00ec che questo file system fosse escluso dalla mia pratica per lungo tempo. Sono emersi ext4 e xfs, che sono diventati lo standard. Tuttavia, considerando che ZFS si adatta perfettamente al nostro compito e dato che la versione Linux, secondo le recensioni, \u00e8 cresciuta in un prodotto del tutto ragionevole (anche se non completamente supportato, il che significa che \u00e8 possibile installare ZFS da zero solo con vari rituali), abbiamo deciso di provarlo.<\/p>\n<p><\/p>\n<p>Per motivi comprensibili, abbiamo scelto un banco di prova con una configurazione analoga (eccetto il controller RAID). Abbiamo installato otto dischi SSD da 1920 GB. Non c'era voglia di scrivere la propria immagine di rete per caricare il server su ZFS puro, quindi abbiamo tolto 50 GB da ogni disco e creato un MD RAID-10 per il sistema. I restanti 1950 GB di ogni disco sono stati uniti in un equivalente ZFS 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 dei dati gzip standard. Abbiamo molte risorse di elaborazione sul server e non sono completamente utilizzate. Di conseguenza, 3 TB del nostro DB si sono trasformati in 1,6 TB e poich\u00e9 il collo di bottiglia, come nel caso precedente, \u00e8 la massima prestazione dei dischi, meno dati abbiamo, meglio \u00e8; fin dall'inizio otteniamo un ottimo vantaggio da ZFS! Durante i picchi, il mantenimento del gzip richiede fino a 4 core, ma non ci dispiace.<\/p>\n<p><\/p>\n<p>Successivamente, l'implementazione \u00e8 andata pi\u00f9 velocemente. Abbiamo trasferito in modo identico le impostazioni della replica MySQL dal banco di prova LVM. Abbiamo dovuto spendere un po' di tempo per riscrivere gli script con i 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>Dalla messa a punto aggiuntiva: abbiamo trasferito in memoria le partizioni ZFS con i metadati e i log l2arc e zil. Per il nostro compito, come si \u00e8 rivelato successivamente, era superfluo, ma per ora abbiamo mantenuto questa ottimizzazione; cambiarla in futuro non \u00e8 difficile. Tra gli effetti negativi c'\u00e8 il fatto che dopo il riavvio del server \u00e8 necessario ricreare le aree di memoria corrispondenti. I dati non vengono persi. Estratto di zpool status:<\/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 il banco e abbiamo ottenuto risultati eccellenti: con due istanze di DB funzionanti simultaneamente (e una replica principale attiva) sui snapshot, abbiamo ottenuto un utilizzo dei dischi del 50-60%.<\/p>\n<p><\/p>\n<p>Abbiamo risolto il nostro problema principale, come si pu\u00f2 vedere nel grafico del ritardo della replicazione (confronta con il grafico precedente nella sezione Thin LVM):<br \/>\n<img decoding=\"async\" alt=\"Backup efficiente 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, grazie a ci\u00f2, abbiamo notevolmente accelerato tutte le operazioni: la creazione completa di uno snapshot con fermo e avvio della replica richiede fino a 40 secondi, mentre il deployment di una nuova istanza MySQL dallo snapshot richiede fino a 20 secondi. Questo soddisfa ampiamente sia le nostre esigenze che i nostri test del codice.<\/p>\n<p><\/p>\n<p>Resoconto intermedio:<\/p>\n<p><\/p>\n<ul>\n<li>I risultati hanno completamente soddisfatto la nostra necessit\u00e0 di ottenere una copia del DB di produzione per testare il codice.<\/li>\n<li>La tecnologia richiede un'introduzione: \u00e8 necessario comprendere cos'\u00e8 ZFS e come lavorarci.<\/li>\n<li>Non abbiamo verificato lo stato attuale del funzionamento di ZFS con un gran numero (da 1 milione) di piccoli file. Ma supponiamo che il problema persista, quindi non consiglierei questo file system per alcun tipo di storage di file.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"chto-dalshe\">Cosa succede dopo?<\/h3>\n<p><\/p>\n<p>All'interno dello stand non faremo altro, il risultato ci soddisfa. Potremmo, in futuro, aggiungere nelle impostazioni di replica dello stand delle eccezioni per le tabelle non necessarie ai test, questo ridurrebbe ulteriormente il volume del database. Non abbiamo testato il sistema BTRFS e la sua implementazione della tecnologia del salvataggio sottile. Tuttavia, non \u00e8 pi\u00f9 una priorit\u00e0, poich\u00e9 l'obiettivo principale \u00e8 stato raggiunto. In generale, vorremmo allontanarci dall'approccio descritto sopra: implementare migrazioni funzionanti del database nell'ambiente di test, creare un circuito di test del database separato e occuparci del partizionamento del database principale. Molti di questi aspetti li stiamo gi\u00e0 realizzando, di cui parleremo sicuramente nei prossimi articoli. <\/p>\n<p><\/p>\n<h3 id=\"itogi\">Conclusioni<\/h3>\n<p><\/p>\n<p>Il compito iniziale \u00e8 stato risolto, anche se in modo insolito. Nei risultati intermedi sono stati descritti i pregi e i difetti di ciascuna delle tecnologie applicate, quindi vediamo di decidere quale tecnologia e quando utilizzare:<\/p>\n<p><\/p>\n<ul>\n<li>Thin LVM \u2014 per piccoli database e quando non si desidera o non si ha tempo di studiare ZFS.<\/li>\n<li>ZFS \u2014 se si ha esperienza con essa o se si ha la possibilit\u00e0 di dedicare tempo all'apprendimento 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 desidero trasmettere e consolidare \u00e8 che non bisogna avere paura di pensare in modo non convenzionale in situazioni critiche per il business e di utilizzare solo ricette gi\u00e0 pronte. Una volta avremmo potuto scuotere la testa con tutto il dipartimento tecnico e dire che creare copie del database da tre terabyte in meno di un minuto era impossibile, e che non avevamo bisogno di tecnologie rischiose, basta fare come si deve. Era possibile, ma avremmo perso circa sei mesi o un anno e molte visite dei clienti (le visite sono il nostro principale indicatore di business) senza test e durante l'implementazione. Pensando fuori dagli schemi, abbiamo perso meno tempo nell'implementazione, guadagnato esperienza in nuove e dimenticate tecnologie, e fornito test esattamente nel momento in cui ne avevamo molto bisogno. Questo ha avuto sicuramente un impatto positivo su tutti i nostri indicatori. La scelta \u00e8 sempre vostra, e noi continueremo a raccontare nel nostro blog le attuali e future realizzazioni 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.2 - 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.2\" \/>\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\udd47Riserva fine dei file system Linux. Come creare copie di backup di un database 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}]}}