{"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\/da\/blog\/administrirovanie\/tonkoe-rezervirovanie-fajlovyh-sistem-linux-kak-sozdavat-rabochie-kopii-trehterabajtnoj-subd-mysql-za-20-sekund","title":{"rendered":"Tynd backup af filsystemer i Linux. S\u00e5dan opretter man arbejdsbackups af en tre terabyte MySQL-database p\u00e5 20 sekunder","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Tynd backup af filsystemer i Linux. S\u00e5dan opretter man arbejdsbackups af en tre terabyte MySQL-database p\u00e5 20 sekunder\" src=\"\/wp-content\/uploads\/2020\/03\/7502785a78bd6f069913e97829ff2f63.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Jeg hedder Yuriy, jeg er leder af systemadministrationsgruppen hos Citymobil. I dag vil jeg dele erfaringer med teknologien for tynd provisionering (thin provisioning) af Linux-filsystemer og fort\u00e6lle, hvordan den kan anvendes i virksomhedens CI\/CD-processer. Vi vil gennemg\u00e5 en situation, hvor vi hurtigst muligt har brug for MySQL-databasekopier, der er s\u00e5 t\u00e6t som muligt p\u00e5 \"produktion\"-versionen, og som er tilg\u00e6ngelige til l\u00e6sning og skrivning.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3 id=\"vvedenie-zachem-davat-vrednye-sovety\">Introduktion: Hvorfor give d\u00e5rlige r\u00e5d?<\/h3>\n<p><\/p>\n<p>Et logisk sp\u00f8rgsm\u00e5l, for der findes velafpr\u00f8vede mekanismer til migrering af DB-schemas til testmilj\u00f8er. Hvorfor overhovedet lade den prim\u00e6re, ikke-shardede DB vokse til s\u00e5danne dimensioner? Og for testning er ikke alle data n\u00f8dvendige. Jeg vil fors\u00f8ge at forklare.<\/p>\n<p><\/p>\n<p>For cirka et \u00e5r siden, midt i den aktive v\u00e6kst af vores tax aggregator (i 2018 voksede vi omtrent 15 gange i afsluttede ture), voksede datam\u00e6ngden, belastningen p\u00e5 serverne og frekvensen af udrulninger. Vi befandt os i f\u00f8lgende situation:<\/p>\n<p><\/p>\n<ul>\n<li>Den prim\u00e6re MySQL-database voksede til omkring 1000 tabeller med en samlet st\u00f8rrelse p\u00e5 2,5 TB og fortsatte med at vokse.<\/li>\n<li>Der var ikke mulighed for hurtigt at shard'e og sprede databasen. Den gamle tilgang med \"jeg skriver i databasen, hvad jeg vil, og som jeg vil\" samt mange JOINs og interne tabelafh\u00e6ngigheder tillod ikke dette.<\/li>\n<li>Der var ikke nogen mekanisme til at migrere DB-schemaet til testmilj\u00f8er.<\/li>\n<li>Der var ikke automatisk tests af koden ved udrulning til produktion.<\/li>\n<\/ul>\n<p><\/p>\n<p>Den sidste problemstilling \u00f8nskede vi at l\u00f8se s\u00e5 hurtigt som muligt. Der var allerede skrevet Postman-tests for at tjekke den prim\u00e6re PHP-mono, men en aktuel database manglede. Vi kunne ikke skabe en replik om natten, g\u00f8re den til master og give den til r\u00e5dighed om dagen: et meget stort antal udrulninger og \u00e6ndringer, b\u00e5de i dataene og i DB-schemat, ville g\u00f8re standen ugyldig allerede ved middagstid. Og at begr\u00e6nse udrulninger til kun arbejdsdage ville v\u00e6re ineffektivt. <\/p>\n<p><\/p>\n<p>Alligevel blev opgaven l\u00f8st: den f\u00f8rste fungerende stand fik vi allerede efter to uger. I det forl\u00f8bne \u00e5r har den underg\u00e5et mange \u00e6ndringer og bliver stadig brugt.<\/p>\n<p><\/p>\n<p>Herefter vil jeg detaljeret beskrive alle trin og faser af udviklingen af vores l\u00f8sning. Du vil se, at denne metode fortjener at eksistere.<\/p>\n<p><\/p>\n<p><strong>Hvad er \"tynd provisionering\"?<\/strong><br \/>\nDet er en hardware- eller softwareteknologi (ogs\u00e5 kendt som sparse volumes), der g\u00f8r det muligt at allokere flere kr\u00e6vede ressourcer, end der faktisk er tilg\u00e6ngelige. Den allokerede kapacitet skal opfylde kriterierne just-enough (s\u00e5 meget som n\u00f8dvendigt) og just-in-time (i den n\u00f8dvendige tid). Prim\u00e6rt anvendes thin provisioning i forskellige SAN-l\u00f8sninger for at tilbyde diskplads i n\u00f8dvendige m\u00e6ngder, der overstiger den faktiske tilg\u00e6ngelighed. Teknologien underst\u00f8ttes af forskellige filsystemer, som f.eks. LVM2, ZFS, BTRFS. Den bruges bredt i virtualiseringshypervisorer. Thin provisioning gjorde det muligt for os hurtigt at skabe s\u00e5 mange kopier af hovedpartitionen med data (data-mappen for MySQL-databasen) som vi havde brug for, direkte fra snapshots.<\/p>\n<p><\/p>\n<h3 id=\"pervyy-stend-tehnologiya-thin-lvm\">F\u00f8rste stand, Thin LVM-teknologi<\/h3>\n<p><\/p>\n<p>Dette kapitel kan ogs\u00e5 kaldes \"S\u00e5dan laver du maksimal hurtige snapshots af store datam\u00e6ngder ved hj\u00e6lp af <noindex><a rel=\"nofollow\" href=\"http:\/\/man7.org\/linux\/man-pages\/man7\/lvmthin.7.html\">Thin LVM<\/a><\/noindex>\", hvilket reducerer stabiliteten af filsystemet og MySQL-databasen til urimelige niveauer.\" <\/p>\n<p><\/p>\n<p>Da vi allerede havde brugt LVM til at oprette hovedpartitionerne til OS, besluttede vi at starte netop med det. F\u00f8rst havde vi brug for en separat fysisk maskine \u2014 en kopi af vores hoved-MySQL-database, hvor vi kunne oprette snapshots af replikaen efter behov og k\u00f8re den ved siden af en separat MySQL-instans. I testperioden tillod vi at udf\u00f8re \u00e6ndrende operationer p\u00e5 denne instans, og n\u00e5r testene var afsluttet, blev den med succes slettet. Serverkonfigurationen var som f\u00f8lger:<\/p>\n<p><\/p>\n<ul>\n<li>2 x Intel Silver 4114 (10&#215;2,2 GHz HT)<\/li>\n<li>8 x 32 GB DDR4 <\/li>\n<li>8 x 1920 GB Intel SSD i Adaptec RAID-controller i RAID-10<\/li>\n<\/ul>\n<p><\/p>\n<p>Emnet om valget mellem RAID-controller og software-RAID MD kunne fylde en egen artikel. Jeg vil kun sige, at vores valg blev p\u00e5virket af to faktorer:<\/p>\n<p><\/p>\n<ul>\n<li>P\u00e5 det tidspunkt, hvor opgaven blev stillet, installerede vi alle databaser p\u00e5 RAID-controllere, s\u00e5 man kan sige, at det er blevet historisk. <\/li>\n<li>Forskellen i ydeevne ved syntetiske tests af filsystemet og tests med forskellige operationer i MySQL var minimal. <\/li>\n<\/ul>\n<p><\/p>\n<p>Vi har opdelt den resulterende RAID-10: vi har lavet en samlet Volume Group (VG) p\u00e5 hele kapaciteten (med overhead p\u00e5 cirka 6,7 GB) og oprettet et logisk volumen (Logical Volume, LV) til systemet p\u00e5 50 GB. Under normale omst\u00e6ndigheder ville vi tildele resten af pladserne til MySQL-partitionen. Men vi havde brug for fleksibel backup, s\u00e5 vi oprettede f\u00f8rst en s\u00e5kaldt pool, inden vi oprettede en partition til \/var\/lib\/mysql p\u00e5 3,5 TB (baseret p\u00e5 de forventede database st\u00f8rrelser):<\/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>Vi formaterede partitionen til ext4, monterede den, indspillede en kopi og fik det oprindelige milj\u00f8. Derefter lavede vi et API, der skal oprette snapshots, starte en MySQL-databaseinstans p\u00e5 den angivne port og slette den oprettede instans. Da der kun anvendes systemopkald, valgte vi at skrive scriptet i almindelig bash, og som API-forbindelse HTTP \u2192 bash implementerede vi en open source-l\u00f8sning <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/phonkee\/goexpose\">goexpose<\/a><\/noindex>, skrevet i Go. <\/p>\n<p><\/p>\n<p>En dag vil vi give vores bash-scripts til open source, men indtil da vil jeg blot beskrive den grundl\u00e6ggende algoritme:<\/p>\n<p><\/p>\n<p>Oprettelse af det prim\u00e6re snapshot snapmain:<\/p>\n<p><\/p>\n<ol>\n<li>Vi stopper den prim\u00e6re kopi.<\/li>\n<li>Vi s\u00e6tter l\u00e5s p\u00e5 operationer med snapshot snapmain.<\/li>\n<li>Vi opretter et nyt snapshot snapmain.<\/li>\n<li>Vi starter MySQL og fjerner l\u00e5sen.<\/li>\n<\/ol>\n<p><\/p>\n<p>Oprettelse af en database p\u00e5 en vilk\u00e5rlig port fra snapmain:<\/p>\n<p><\/p>\n<ol>\n<li>Vi s\u00e6tter l\u00e5s p\u00e5 den specifikke databaseinstans (port).<\/li>\n<li>Vi kontrollerer, om der er en l\u00e5s til oprettelsen af det prim\u00e6re snapshot. Hvis det er tilf\u00e6ldet, venter vi og tjekker igen hvert 5. sekund.<\/li>\n<li>Vi tjekker, om der er et gammelt LV-volumen til instansen.<br \/>\n3.1 Hvis der er, stopper vi MySQL-instansen med kill -9 og sletter LV-volumenet.<\/li>\n<li>Vi opretter en ny instans fra snapmain.<\/li>\n<li>Vi forbereder og monterer mapperne til denne instans.<\/li>\n<li>Vi fjerner tegn p\u00e5 slaver (filer) og starter MySQL-instansen.<\/li>\n<li>Vi g\u00f8r den til master.<\/li>\n<li>Vi fjerner l\u00e5sen.<\/li>\n<\/ol>\n<p><\/p>\n<p>Sletning af databasen p\u00e5 en vilk\u00e5rlig port:<\/p>\n<p><\/p>\n<ol>\n<li>Vi s\u00e6tter l\u00e5s p\u00e5 den specifikke databaseinstans (port).<\/li>\n<li>Vi dr\u00e6ber MySQL-instansen med kill -9.<\/li>\n<li>Vi afmonterer mapperne.<\/li>\n<li>Vi sletter LV-volumen og fjerner l\u00e5sen.<\/li>\n<\/ol>\n<p><\/p>\n<p>Eksempelkommandoer til kloning af partitioner til den nye databaseinstans:<\/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>Lad os nu tale om det prim\u00e6re problem, vi st\u00f8dte p\u00e5 ved brug af thin provisioning. Vi ramte ydeevnegr\u00e6nsen p\u00e5 SSD-diske. Dette skete p\u00e5 grund af egenskaberne ved Thin LVM: det fungerer grundl\u00e6ggende p\u00e5 en lavere enhedsniveau med chunks, der som standard er 4 MB store. S\u00e5dan s\u00e5 det ud:<\/p>\n<p><\/p>\n<ol>\n<li>Vi opretter et snapshot fra hovedpartitionen \/var\/lib\/mysql.<\/li>\n<li>Vi starter replikationen for at indhente masteren.<\/li>\n<li>Enhver \u00e6ndring i tabellerne p\u00e5 replikationen tvinger os til at gemme gamle, u\u00e6ndrede datachunks i snapshot-partitionen.<\/li>\n<li>Enhver \u00e6ndring i den oprettede testinstans tvinger os til at gemme gamle, u\u00e6ndrede datachunks i partitionen af det klonede snapshot for denne instans.<\/li>\n<li>Vi oplever 100% I\/O-belastning p\u00e5 enheden, hvilket medf\u00f8rer, at alle operationer forsinkes, og replikationen st\u00e5r stille.<\/li>\n<li>Ved dagens udgang har vi et stand, der er forsinket med flere timer.<\/li>\n<\/ol>\n<p><\/p>\n<p>S\u00e5dan k\u00e6mpede vi med det for at f\u00e5 et mere rimeligt resultat (h\u00e6ftninger):<\/p>\n<p><\/p>\n<p>RAID-controller:<\/p>\n<p><\/p>\n<ul>\n<li>Vi har som standard deaktiveret al form for caching. <\/li>\n<li>Vi har indstillet writeback (n\u00e5r dataene kommer i cache, afsluttes skrivningen, f\u00f8r den faktiske gemmelse p\u00e5 disk sker).<\/li>\n<\/ul>\n<p><\/p>\n<p>Filsystem:<\/p>\n<p><\/p>\n<ul>\n<li>Ved monteringspunktet \/var\/lib\/mysql har vi angivet <em>noatime,nodiratime,data=writeback<\/em><\/li>\n<li>Vi har deaktiveret ext4 logning ved hj\u00e6lp af tune2fs.<\/li>\n<\/ul>\n<p><\/p>\n<p>MySQL:<\/p>\n<p><\/p>\n<ul>\n<li>Vi har angivet <em>innodb_flush_method = O_DSYNC<\/em> (vi \u00f8gede skrivehastigheden og dermed s\u00e6nkede p\u00e5lideligheden).<\/li>\n<li>Vi har deaktiveret logning, da vi ikke har brug for logfiler.<\/li>\n<li>Vi har angivet <em>innodb_buffer_pool_size = 4G<\/em> (jo mindre st\u00f8rrelsen p\u00e5 InnoDB-poolen er, jo hurtigere vil MySQL stoppe ved nedlukning, og jo hurtigere kan vi oprette et snapshot).<\/li>\n<\/ul>\n<p><\/p>\n<p>Dette er langt fra en udt\u00f8mmende liste, is\u00e6r hvad ang\u00e5r MySQL. Andre \u00e6ndringer er dog mindre og g\u00e6lder ofte ikke altid og ikke pr\u00e6cist. For eksempel, i fors\u00f8get p\u00e5 at aflaste diske, flyttede vi endda <em>innodb_parallel_doublewrite_path<\/em> til \/dev\/shm, hvilket i nogle tilf\u00e6lde ved opstart af en forkert afsluttet instans sparede os op til 5 sekunder.<\/p>\n<p><\/p>\n<p>Hvorfor stopper vi MySQL, f\u00f8r vi laver et snapshot? Vi kan jo tage et fra den k\u00f8rende replikation. Det er korrekt, men den nye DB-instans p\u00e5 dette snapshot vil som standard blive betragtet som beskadiget og kr\u00e6ver en fuld scanning ved opstart. At stoppe replikationen er bestemt hurtigere, selvom det i sidste ende er den mest tidskr\u00e6vende operation i hele processen.<\/p>\n<p><\/p>\n<p>Som resultat har vi f\u00e5et mere acceptable timings og en klar arbejdsstand. Selvom det, som det fremg\u00e5r af det mest talende diagram over forsinkelsen af replikationen af hovedreplikatet, stadig er langt fra ideelt:<br \/>\n<img decoding=\"async\" alt=\"Tynd backup af filsystemer i Linux. S\u00e5dan opretter man arbejdsbackups af en tre terabyte MySQL-database p\u00e5 20 sekunder\" src=\"\/wp-content\/uploads\/2020\/03\/9bb7bb7d9abfea124a75616deec57f05.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Fra andre ulemper kan n\u00e6vnes den praktiske umulighed af at overv\u00e5ge Thin LVM-poolen: Udover systemets standardfunktioner iostat er det umuligt at forst\u00e5, hvilken del af poolen der i \u00f8jeblikket belaster filsystemet mest.<\/p>\n<p><\/p>\n<p>Det er vigtigt at n\u00e6vne en stor ulempe ved den ovenn\u00e6vnte optimering: Vi fik en YOLO-stand. Cirka en gang hver m\u00e5ned eller to kunne ext4 ikke holde til s\u00e5danne overgreb og br\u00f8d ned uigenkaldeligt, hvilket kr\u00e6vede omformatering og genindl\u00e6sning af replikatet. Selvom vi vandt i hastighed, \u00f8delagde vi h\u00e5bl\u00f8st stabiliteten.<\/p>\n<p><\/p>\n<p>Hvilke m\u00e5linger b\u00f8r man holde \u00f8je med under drift af Thin LVM:<\/p>\n<p><\/p>\n<ul>\n<li>Thin pool data %<\/li>\n<li>Thin pool metadata %<\/li>\n<\/ul>\n<p><\/p>\n<p>Hvis vores stand kan overleve, at der ikke er mere plads til data (det er nok at rydde op p\u00e5 diskene), vil manglende plads til metadata f\u00f8re til en komplet sammenbrud af poolen og behovet for at oprette den fra bunden.<\/p>\n<p><\/p>\n<p>Filsystemet inden for poolen fragmenteres meget over tid. Jeg anbefaler at k\u00f8re kommandoen <em>fstrim -v \/var\/lib\/mysql<\/em>.<\/p>\n<p><\/p>\n<p>Mellemsummer:<\/p>\n<p><\/p>\n<ul>\n<li>Teknologien er let at anvende, ligesom selve LVM, og kr\u00e6ver ikke s\u00e6rlig kvalifikation af ingeni\u00f8ren.<\/li>\n<li>Den vil v\u00e6re velegnet til sm\u00e5 databaser, der ikke er for belastede. Jo mindre databasen er, jo f\u00e6rre chunks bev\u00e6ger sig gennem filsystemet i poolen, og jo lavere belastning p\u00e5 diskene.<\/li>\n<li>Til vores opgave begyndte vi at s\u00f8ge efter alternative l\u00f8sninger, som vil blive diskuteret i n\u00e6ste afsnit.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"vtoroy-stend-tehnologiya-zfs\">Den anden stand, teknologien ZFS<\/h3>\n<p><\/p>\n<p>For a long time, I dealt with the ZFS file system, but back then ZFS operated well only on its native OS family, Solaris. There was a ported version on FreeBSD that had a decent level of implementation. There was also an unfinished port for Linux that few used. Due to the B-tree data storage structure (which, by the way, is the same structure used by InnoDB MySQL), ZFS performed poorly in installations with a very large number of files. All this, combined with the need to learn the technical details before using it, removed this file system from my practice for a long time. Then ext4 and xfs emerged, which became the standard. However, considering that ZFS is more than suitable for our task, and judging by reviews, the Linux version has grown into a quite reasonable product (although not fully supported, which is why setting up a system on ZFS from scratch can only be done with various tricks), we decided to give it a try.<\/p>\n<p><\/p>\n<p>For obvious reasons, we chose a stand with a similar configuration (except for the RAID controller). We installed eight SSDs of 1920 GB each. There was no desire to write our own network image to upload the server to bare ZFS, so we took 50 GB from each disk and created an MD RAID-10 for the system. The remaining 1950 GB on each disk were combined into a ZFS equivalent of 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>We created partitions for 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>Note that we enabled the built-in gzip data compression. We have plenty of CPU resources on the server, and they are not fully utilized. As a result, 3 TB of our database turned into 1.6 TB, and since the weakest link, as before, is the maximum disk performance, the less data there is \u2014 the better. From the very start, we get a great bonus from ZFS! At peak hours, with full load, maintaining gzip consumes up to 4 cores, but we don't mind.<\/p>\n<p><\/p>\n<p>Next, the implementation went faster. We replicated the MySQL settings from the LVM stand. It took some time to rewrite the scripts to ZFS commands, but overall the algorithms remained the same. Here is an example of creating a 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>Fra den ekstra tuning: vi har flyttet ZFS-partitioner med metadata og logs l2arc og zil ind i hukommelsen. For vores opgave var dette, som det viste sig senere, overfl\u00f8digt, men indtil videre har vi beholdt denne optimering, da det er nemt at \u00e6ndre det, hvis n\u00f8dvendigt. De negative effekter \u2014 man skal genskabe de relevante hukommelsesomr\u00e5der efter genstart af serveren. Data g\u00e5r ikke tabt. Uddrag af 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>I denne konfiguration begyndte vi at teste ops\u00e6tningen og fik fremragende resultater: med to samtidig k\u00f8rende databaseinstanser (og en aktiv prim\u00e6r replika) p\u00e5 snapshots havde vi en diskbelastning p\u00e5 50-60 %.<\/p>\n<p><\/p>\n<p>Vi har l\u00f8st vores prim\u00e6re problem, hvilket fremg\u00e5r af grafen for replikeringsefterlag (sammenlign med den tidligere graf i afsnittet Thin LVM):<br \/>\n<img decoding=\"async\" alt=\"Tynd backup af filsystemer i Linux. S\u00e5dan opretter man arbejdsbackups af en tre terabyte MySQL-database p\u00e5 20 sekunder\" src=\"\/wp-content\/uploads\/2020\/03\/15df9283838a4662ff0f68accfde4089.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Udover og takket v\u00e6re dette er vi blevet meget hurtigere i alle operationer: oprettelse af et snapshot med stop og genstart af replikationen tager op til 40 sekunder, udrulning af en ny MySQL instans fra et snapshot tager op til 20 sekunder. Dette tilfredsstiller b\u00e5de os og vores kode-tests.<\/p>\n<p><\/p>\n<p>Mellemsummer:<\/p>\n<p><\/p>\n<ul>\n<li>Resultaterne har fuldt ud tilfredsstillet vores behov for at f\u00e5 en kopi af den operationelle database til test af koden.<\/li>\n<li>Teknologien kr\u00e6ver forst\u00e5else: man skal vide, hvad ZFS er, og hvordan man arbejder med det.<\/li>\n<li>Vi har ikke tjekket den nuv\u00e6rende status p\u00e5 ZFS med et stort antal (over 1 million) sm\u00e5 filer. Men vi antager, at problemet stadig eksisterer, s\u00e5 jeg ville ikke anbefale dette filsystem til nogen filopbevaring.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"chto-dalshe\">Hvad nu?<\/h3>\n<p><\/p>\n<p>Vi har ikke planlagt at g\u00f8re andet med standet; resultatet tilfredsstiller os. M\u00e5ske vil vi fremover tilf\u00f8je undtagelser for tabeller, der ikke er n\u00f8dvendige til testning, i konfigurationen af standets replikation, hvilket yderligere vil reducere st\u00f8rrelsen af databasen. Vi har ikke testet BTRFS-systemet og dets implementering af teknologi til s\u00e5kaldt \u201cthin provisioning\u201d. Men det er heller ikke l\u00e6ngere en opgave, da det prim\u00e6re m\u00e5l er n\u00e5et. Generelt \u00f8nsker vi naturligvis at bev\u00e6ge os v\u00e6k fra den ovenfor beskrevne tilgang \u2014 at implementere arbejdsprocesser for database-migrationer til testmilj\u00f8et, skabe en separat testkontur for databasen og arbejde med sharding af hoveddatabasen. Meget af dette er vi allerede i gang med at realisere, hvilket vi vil dele i kommende artikler. <\/p>\n<p><\/p>\n<h3 id=\"itogi\">Resum\u00e9<\/h3>\n<p><\/p>\n<p>Den oprindelige opgave blev l\u00f8st, om end p\u00e5 en utraditionel m\u00e5de. I de mellemliggende konklusioner blev styrkerne og svaghederne ved hver af de anvendte teknologier beskrevet, s\u00e5 lad os beslutte, hvilken teknologi og hvorn\u00e5r man kan bruge:<\/p>\n<p><\/p>\n<ul>\n<li>Thin LVM \u2014 til sm\u00e5 databaser og n\u00e5r man ikke har lyst til eller ikke har tid til at s\u00e6tte sig ind i ZFS.<\/li>\n<li>ZFS \u2014 hvis der er erfaring med det, eller hvis der er tid til at unders\u00f8ge det under alle omst\u00e6ndigheder. <\/li>\n<\/ul>\n<p><\/p>\n<p>P\u00e5 et h\u00f8jere niveau er denne artikel ikke blot en sammenligning af teknologien mellem to filsystemer. Den grundl\u00e6ggende id\u00e9, jeg gerne vil viderebringe og styrke, er, at man ikke skal v\u00e6re bange for at t\u00e6nke kreativt i situationer, der er kritiske for forretningen, og kun stole p\u00e5 standardl\u00f8sninger. Engang kunne vi som hele den tekniske afdeling ryste p\u00e5 hovedet og sige, at opgaven med at lave tre terabytes databackup p\u00e5 mindre end et minut ikke kunne lade sig g\u00f8re, og vi havde ikke brug for risikable teknologier, lad os g\u00f8re det rigtigt. Det var muligt, men vi ville have tabt omkring et halvt til et \u00e5r og mange kundeprojekter (rejser er vores vigtigste forretningsindikator) uden tests og under implementeringen. Ved at t\u00e6nke anderledes tabte vi ikke s\u00e5 meget tid p\u00e5 implementeringen, fik erfaringer med nye og glemte gamle teknologier, og kunne levere testningen netop p\u00e5 det tidspunkt, hvor vi n\u00f8dvendigvis havde brug for det. Uden tvivl har dette haft en positiv indvirkning p\u00e5 alle vores resultater. Valget er altid jeres, og vi vil forts\u00e6tte med at fort\u00e6lle om interessante aktuelle og fremtidige pr\u00e6stationer i vores blog.<\/p>\n<p>Kilde: <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.3 - 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\/da\/blog\/administrirovanie\/tonkoe-rezervirovanie-fajlovyh-sistem-linux-kak-sozdavat-rabochie-kopii-trehterabajtnoj-subd-mysql-za-20-sekund\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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\udd47Finjustering af Linux filsystemer. S\u00e5dan oprettes sikkerhedskopier af en tre-terabyte MySQL-database p\u00e5 20 sekunder | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/da\/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":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/74327","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=74327"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/74327\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/74328"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=74327"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=74327"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=74327"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}