{"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\/hu\/blog\/administrirovanie\/tonkoe-rezervirovanie-fajlovyh-sistem-linux-kak-sozdavat-rabochie-kopii-trehterabajtnoj-subd-mysql-za-20-sekund","title":{"rendered":"V\u00e9kony lemezalap\u00fa Linux f\u00e1jlok biztons\u00e1gi ment\u00e9se. Hogyan k\u00e9sz\u00edthet\u00fcnk m\u00e1solatokat egy h\u00e1rom terab\u00e1jtos MySQL adatb\u00e1zisb\u00f3l 20 m\u00e1sodperc alatt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"V\u00e9kony lemezalap\u00fa Linux f\u00e1jlok biztons\u00e1gi ment\u00e9se. Hogyan k\u00e9sz\u00edthet\u00fcnk m\u00e1solatokat egy h\u00e1rom terab\u00e1jtos MySQL adatb\u00e1zisb\u00f3l 20 m\u00e1sodperc alatt\" src=\"\/wp-content\/uploads\/2020\/03\/7502785a78bd6f069913e97829ff2f63.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>A nevem Juri, a Sitimobil rendszergazd\u00e1lkod\u00e1si csoport vezet\u0151je vagyok. Ma megosztom tapasztalataimat a v\u00e9kony lemezalap\u00fa (thin provisioning) Linux f\u00e1jlrendszerek technol\u00f3gi\u00e1j\u00e1val kapcsolatban, \u00e9s elmondom, hogyan alkalmazhat\u00f3k ezek a v\u00e1llalat CI\/CD folyamataiban. Megvizsg\u00e1ljuk azt a helyzetet, amikor a k\u00f3d automatikus tesztel\u00e9s\u00e9hez a termel\u00e9sbe val\u00f3 telep\u00edt\u00e9s sor\u00e1n min\u00e9l gyorsabban sz\u00fcks\u00e9g\u00fcnk van MySQL adatb\u00e1zis m\u00e1solatokra, amelyek a lehet\u0151 legk\u00f6zelebb \u00e1llnak a \"\u00e9les\" verzi\u00f3hoz, el\u00e9rhet\u0151ek olvas\u00e1sra \u00e9s \u00edr\u00e1sra.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3 id=\"vvedenie-zachem-davat-vrednye-sovety\">Bevezet\u00e9s: Mi\u00e9rt \u00e9rdemes k\u00e1ros tan\u00e1csokat adni?<\/h3>\n<p><\/p>\n<p>Logikus k\u00e9rd\u00e9s, hiszen l\u00e9teznek bev\u00e1lt mechanizmusok az adatb\u00e1zis s\u00e9m\u00e1k migr\u00e1l\u00e1s\u00e1ra tesztk\u00f6rnyezetekbe. Mi\u00e9rt is kellene egy alapvet\u0151en nem shardolt adatb\u00e1zist ilyen m\u00e9retekig feln\u00f6velni? R\u00e1ad\u00e1sul a tesztel\u00e9shez nem is sz\u00fcks\u00e9ges minden adat. Megpr\u00f3b\u00e1lom elmagyar\u00e1zni.<\/p>\n<p><\/p>\n<p>K\u00f6r\u00fclbel\u00fcl egy \u00e9vvel ezel\u0151tt, a taxiaggreg\u00e1torunk gyors n\u00f6veked\u00e9se k\u00f6zepette (2018-ban a befejezett utaz\u00e1sok sz\u00e1ma k\u00f6r\u00fclbel\u00fcl 15-sz\u00f6r\u00f6s\u00e9re n\u0151tt), a adataink mennyis\u00e9ge is megn\u0151tt, a szerverekre nehezed\u0151 teher \u00e9s a kiad\u00e1sok gyakoris\u00e1ga is emelkedett. A k\u00f6vetkez\u0151 helyzetben tal\u00e1ltuk magunkat:<\/p>\n<p><\/p>\n<ul>\n<li>Az alap MySQL adatb\u00e1zis k\u00f6r\u00fclbel\u00fcl 1000 t\u00e1bl\u00e1ra n\u0151tt, \u00f6sszesen 2,5 TB terjedelemmel, \u00e9s tov\u00e1bbra is n\u00f6vekedett.<\/li>\n<li>Nem volt lehet\u0151s\u00e9g\u00fcnk gyorsan sharda-ra v\u00e1ltani \u00e9s az adatb\u00e1zist sz\u00e9tszedni. Az a r\u00e9gi megk\u00f6zel\u00edt\u00e9s, hogy \"b\u00e1rmilyen adatot \u00edrok az adatb\u00e1zisba, ahogyan csak akarok\" sok JOIN \u00e9s bels\u0151 t\u00e1blasorozat miatt lehetetlenn\u00e9 tette ezt.<\/li>\n<li>Nem volt mechanizmus az adatb\u00e1zis s\u00e9ma migr\u00e1l\u00e1s\u00e1ra tesztk\u00f6rnyezetekbe.<\/li>\n<li>Nem volt automatikus k\u00f3dtesztel\u00e9s a telep\u00edt\u00e9s sor\u00e1n.<\/li>\n<\/ul>\n<p><\/p>\n<p>Az utols\u00f3 probl\u00e9m\u00e1t a lehet\u0151 leggyorsabban szerett\u00fck volna megoldani. M\u00e1r \u00edrtunk teszteket Postman-ben a f\u0151 PHP-monolith tesztel\u00e9s\u00e9re, de nem volt elegend\u0151 aktu\u00e1lis adatb\u00e1zisunk. Ugyanakkor nem tudtunk \u00e9jszaka replik\u00e1t l\u00e9trehozni, mesterr\u00e9 tenni azt, \u00e9s napk\u00f6zben el\u00e9rhet\u0151v\u00e9 tenni: a t\u00fal sok kiad\u00e1s \u00e9s v\u00e1ltoztat\u00e1s, p\u00e9ld\u00e1ul az adatok \u00e9s az adatb\u00e1zis s\u00e9m\u00e1iban, nem tette volna m\u0171k\u00f6d\u0151k\u00e9pess\u00e9 a k\u00f6rnyezetet m\u00e1r a nap k\u00f6zep\u00e9re. R\u00e1ad\u00e1sul a kiad\u00e1sokat csak a munkanapra korl\u00e1tozni nem lett volna hat\u00e9kony. <\/p>\n<p><\/p>\n<p>Ennek ellen\u00e9re a feladatot elv\u00e9gezt\u00fck: az els\u0151 m\u0171k\u00f6d\u0151 k\u00f6rnyezet\u00fcnket m\u00e1r k\u00e9t h\u00e9t eltelt\u00e9vel megkaptuk. Az\u00f3ta sok v\u00e1ltoz\u00e1son ment kereszt\u00fcl, \u00e9s tov\u00e1bbra is haszn\u00e1latban van.<\/p>\n<p><\/p>\n<p>Ezut\u00e1n r\u00e9szletesen ismertetem a megold\u00e1sunk fejleszt\u00e9s\u00e9nek minden l\u00e9p\u00e9s\u00e9t \u00e9s szakasz\u00e1t. Meg fog gy\u0151z\u0151dni arr\u00f3l, hogy ez a m\u00f3dszer meg\u00e9rdemli a l\u00e9tez\u00e9st.<\/p>\n<p><\/p>\n<p><strong>Mi az a \u201ev\u00e9kony rezerv\u00e1l\u00e1s\u201d?<\/strong><br \/>\nEz egy hardveres vagy szoftveres technol\u00f3gia (m\u00e1s n\u00e9ven sparse volumes), amely lehet\u0151v\u00e9 teszi, hogy t\u00f6bb er\u0151forr\u00e1st allok\u00e1ljunk, mint amennyi fizikailag rendelkez\u00e9sre \u00e1ll. Az allok\u00e1lt t\u00e9rfogatnak meg kell felelnie a just-enough (\u00e9ppen annyi, amennyi sz\u00fcks\u00e9ges) \u00e9s just-in-time (a sz\u00fcks\u00e9ges id\u0151ben) krit\u00e9riumoknak. F\u0151k\u00e9nt k\u00fcl\u00f6nb\u00f6z\u0151 t\u00e1rol\u00f3rendszerekben haszn\u00e1lj\u00e1k, hogy elegend\u0151 mennyis\u00e9g\u0171 lemezter\u00fcletet biztos\u00edtsanak, amely meghaladja a t\u00e9nylegesen el\u00e9rhet\u0151 kapacit\u00e1st. A technol\u00f3gi\u00e1t k\u00fcl\u00f6nb\u00f6z\u0151 f\u00e1jlrendszerek t\u00e1mogatj\u00e1k, p\u00e9ld\u00e1ul LVM2, ZFS, BTRFS. Sz\u00e9lesk\u00f6r\u0171en alkalmazz\u00e1k virtualiz\u00e1ci\u00f3s hyperv\u00edzorokban. A v\u00e9kony rezerv\u00e1l\u00e1s lehet\u0151v\u00e9 tette sz\u00e1munkra, hogy gyorsan hozzunk l\u00e9tre annyi m\u00e1solatot az adatokat tartalmaz\u00f3 f\u0151 part\u00edci\u00f3 pillanatk\u00e9peib\u0151l, amennyire sz\u00fcks\u00e9g\u00fcnk volt (MySQL adatb\u00e1zis data k\u00f6nyvt\u00e1ra).<\/p>\n<p><\/p>\n<h3 id=\"pervyy-stend-tehnologiya-thin-lvm\">Els\u0151 stand, Thin LVM technol\u00f3gia<\/h3>\n<p><\/p>\n<p>Ezt a fejezetet m\u00e9g \u00edgy is elnevezhetj\u00fck: \u201eHogyan k\u00e9sz\u00edts\u00fcnk maxim\u00e1lisan gyors pillanatk\u00e9peket nagy adatmennyis\u00e9gekr\u0151l <noindex><a rel=\"nofollow\" href=\"http:\/\/man7.org\/linux\/man-pages\/man7\/lvmthin.7.html\">Thin LVM<\/a><\/noindex>, cs\u00f6kkentve a f\u00e1jlrendszer \u00e9s a MySQL adatb\u00e1zis stabilit\u00e1s\u00e1t elfogadhatatlan szintre.\u201d <\/p>\n<p><\/p>\n<p>Mivel m\u00e1r haszn\u00e1ltuk az LVM-et az oper\u00e1ci\u00f3s rendszerek f\u0151 part\u00edci\u00f3inak kialak\u00edt\u00e1s\u00e1hoz, ez\u00e9rt d\u00f6nt\u00f6tt\u00fcnk azzal, hogy ezzel kezdj\u00fck. El\u0151sz\u00f6r sz\u00fcks\u00e9g\u00fcnk volt egy k\u00fcl\u00f6n fizikai g\u00e9pre \u2013 a MySQL f\u0151 adatb\u00e1zisunk replik\u00e1j\u00e1ra, ahol k\u00e9r\u00e9sre l\u00e9trehozhatunk egy pillanatk\u00e9pet a replik\u00e1r\u00f3l, \u00e9s felmerhetj\u00fck azt egy k\u00fcl\u00f6n MySQL p\u00e9ld\u00e1nyban. A tesztel\u00e9s ideje alatt megengedt\u00fck, hogy ezen a p\u00e9ld\u00e1nyon m\u00f3dos\u00edt\u00f3 m\u0171veleteket hajtsanak v\u00e9gre, \u00e9s a tesztek befejez\u00e9se ut\u00e1n sikeresen t\u00f6r\u00f6lt\u00fck azt. A szerver konfigur\u00e1ci\u00f3ja a k\u00f6vetkez\u0151 volt:<\/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 RAID vez\u00e9rl\u0151vel az Adaptec RAID-10 form\u00e1tumban<\/li>\n<\/ul>\n<p><\/p>\n<p>A RAID vez\u00e9rl\u0151 \u00e9s a szoftveres RAID MD k\u00f6z\u00f6tti v\u00e1laszt\u00e1sr\u00f3l k\u00fcl\u00f6n cikket is lehetne \u00edrni. Csak annyit mondhatok, hogy k\u00e9t t\u00e9nyez\u0151 befoly\u00e1solta a v\u00e1laszt\u00e1sunkat:<\/p>\n<p><\/p>\n<ul>\n<li>A feladat felvet\u00e9s\u00e9nek idej\u00e9n minden adatb\u00e1zist RAID vez\u00e9rl\u0151kre telep\u00edtett\u00fcnk, ez\u00e9rt mondhatjuk, hogy t\u00f6rt\u00e9nelmileg \u00edgy alakult. <\/li>\n<li>A f\u00e1jlrendszer szintetikus tesztjein \u00e9s a MySQL k\u00fcl\u00f6nb\u00f6z\u0151 m\u0171veleteivel v\u00e9gzett tesztek teljes\u00edtm\u00e9nyk\u00fcl\u00f6nbs\u00e9ge minim\u00e1lis volt. <\/li>\n<\/ul>\n<p><\/p>\n<p>A RAID-10 array was created: we set up a single Volume Group (VG) for the entire volume (with overhead of about 6.7 GB) and created a logical partition (Logical Volume, LV) for the system of 50 GB. In a typical situation, the remaining space would be allocated for the MySQL partition. However, we needed thin provisioning, so we first created a pool within which we set aside a partition for \/var\/lib\/mysql of 3.5 TB (based on expected DB sizes):<\/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>We formatted the partition in ext4, mounted it, wrote a replica, and established the initial setup. Then we created an API wrapper that should create snapshots, launch a MySQL database instance on a specified port, and remove the created instance. Since only system calls are used in this process, we chose the standard bash scripting language, and for the API binding, we implemented an open-source solution using HTTP \u2192 bash. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/phonkee\/goexpose\">goexpose<\/a><\/noindex>, written in Go. <\/p>\n<p><\/p>\n<p>One day we will release our bash scripts as open source, but for now, I will simply describe the main algorithm:<\/p>\n<p><\/p>\n<p>Creating the main snapshot snapmain:<\/p>\n<p><\/p>\n<ol>\n<li>We stop the main replica.<\/li>\n<li>We impose a lock on operations with the snapshot snapmain.<\/li>\n<li>We create a new snapshot snapmain.<\/li>\n<li>We start MySQL and remove the lock.<\/li>\n<\/ol>\n<p><\/p>\n<p>Creating a DB on an arbitrary port from snapmain:<\/p>\n<p><\/p>\n<ol>\n<li>We impose a lock on the specific DB instance (port).<\/li>\n<li>We check for the existence of the lock on creating the main snapshot. If it exists, we wait and recheck every 5 seconds.<\/li>\n<li>We check if there is an old LV partition of the instance.<br \/>\n3.1 If it exists, we stop the MySQL instance with kill -9 and remove the LV partition.<\/li>\n<li>We create a new instance from snapmain.<\/li>\n<li>We prepare and mount directories for this instance.<\/li>\n<li>We remove slave indicators (files) and start the MySQL instance.<\/li>\n<li>We promote it to master.<\/li>\n<li>We remove the lock.<\/li>\n<\/ol>\n<p><\/p>\n<p>Deleting a DB on an arbitrary port:<\/p>\n<p><\/p>\n<ol>\n<li>We impose a lock on the specific DB instance (port).<\/li>\n<li>We kill the MySQL instance using kill -9.<\/li>\n<li>We unmount the directories.<\/li>\n<li>We remove the LV partition and lift the lock.<\/li>\n<\/ol>\n<p><\/p>\n<p>Example commands for cloning partitions of the new DB instance:<\/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>Mostrazzuk a f\u0151 probl\u00e9m\u00e1t, amellyel a v\u00e9konyan virtualiz\u00e1lt t\u00e1rol\u00e1s sor\u00e1n szembes\u00fclt\u00fcnk. A SSD-meghajt\u00f3k teljes\u00edtm\u00e9ny\u00e9be \u00fctk\u00f6zt\u00fcnk. Ez a Thin LVM saj\u00e1tos m\u0171k\u00f6d\u00e9s\u00e9b\u0151l ad\u00f3dott, amely alapvet\u0151en alacsony szint\u0171, 4 MB m\u00e9ret\u0171 blokkokkal dolgozik. \u00cdgy n\u00e9zett ki ez:<\/p>\n<p><\/p>\n<ol>\n<li>K\u00e9sz\u00edt\u00fcnk egy pillanatfelv\u00e9telt a f\u0151 part\u00edci\u00f3r\u00f3l \/var\/lib\/mysql.<\/li>\n<li>Elind\u00edtjuk a replik\u00e1ci\u00f3t, hogy utol\u00e9rj\u00fck a mestert.<\/li>\n<li>B\u00e1rmilyen v\u00e1ltoztat\u00e1s a replik\u00e1k t\u00e1bl\u00e1iban r\u00e9gi, v\u00e1ltozatlan adatok blokkjait t\u00e1rolja a pillanatfelv\u00e9teli part\u00edci\u00f3n.<\/li>\n<li>B\u00e1rmely v\u00e1ltoz\u00e1s a tesztp\u00e9ld\u00e1nyban r\u00e9gi, v\u00e1ltozatlan adatok blokkjait t\u00e1rolja a kl\u00f3nozott pillanatfelv\u00e9tel part\u00edci\u00f3j\u00e1n ennek a p\u00e9ld\u00e1nynak.<\/li>\n<li>100%-os bemeneti\/kimeneti terhelts\u00e9get kapunk a k\u00e9sz\u00fcl\u00e9ken, minden m\u0171velet lelassul, \u00e9s a replik\u00e1ci\u00f3 fokozatosan elmarad.<\/li>\n<li>A munkanap v\u00e9g\u00e9re n\u00e9h\u00e1ny \u00f3r\u00e1s lemarad\u00e1st tapasztalunk.<\/li>\n<\/ol>\n<p><\/p>\n<p>Hogyan k\u00fczd\u00f6tt\u00fcnk ezzel, hogy \u00e9sszer\u0171bb eredm\u00e9nyt kapjunk (alapvet\u0151 pontok):<\/p>\n<p><\/p>\n<p>RAID vez\u00e9rl\u0151:<\/p>\n<p><\/p>\n<ul>\n<li>Alap\u00e9rtelmez\u00e9s szerint letiltottunk mindenf\u00e9le gyors\u00edt\u00e1st. <\/li>\n<li>\u00cdrjon vissza (amikor az adatok a pufferbe ker\u00fclnek, a felv\u00e9tel befejez\u0151dik, miel\u0151tt a t\u00e9nyleges ment\u00e9s megt\u00f6rt\u00e9nik a lemezen).<\/li>\n<\/ul>\n<p><\/p>\n<p>F\u00e1jlrendszer:<\/p>\n<p><\/p>\n<ul>\n<li>A \/var\/lib\/mysql csatlakoz\u00e1si pontn\u00e1l be\u00edrtuk <em>noatime,nodiratime,data=writeback<\/em><\/li>\n<li>Az ext4 napl\u00f3z\u00e1st a tune2fs seg\u00edts\u00e9g\u00e9vel letiltottuk.<\/li>\n<\/ul>\n<p><\/p>\n<p>MySQL:<\/p>\n<p><\/p>\n<ul>\n<li>Be\u00edrtuk <em>innodb_flush_method = O_DSYNC<\/em> (n\u00f6velt\u00fck a felv\u00e9tel sebess\u00e9g\u00e9t, cs\u00f6kkentve ez\u00e1ltal a megb\u00edzhat\u00f3s\u00e1got).<\/li>\n<li>Letiltottuk a napl\u00f3z\u00e1st, a napl\u00f3kra nincs sz\u00fcks\u00e9g\u00fcnk.<\/li>\n<li>Be\u00edrtuk <em>innodb_buffer_pool_size = 4G<\/em> (min\u00e9l kisebb az InnoDB pool m\u00e9rete, ann\u00e1l gyorsabban le\u00e1ll a MySQL, \u00e9s ann\u00e1l gyorsabban k\u00e9sz\u00edt\u00fcnk pillanatfelv\u00e9telt).<\/li>\n<\/ul>\n<p><\/p>\n<p>Ez messze nem teljes lista, k\u00fcl\u00f6n\u00f6sen a MySQL eset\u00e9ben. M\u00e1s v\u00e1ltoztat\u00e1sok \u00e1ltal\u00e1ban kisebb jelent\u0151s\u00e9g\u0171ek, \u00e9s nem mindig \u00e9s eg\u00e9sz pontosan alkalmazhat\u00f3k. P\u00e9ld\u00e1ul annak \u00e9rdek\u00e9ben, hogy cs\u00f6kkents\u00fck a lemezek terhel\u00e9s\u00e9t, m\u00e9g a <em>innodb_parallel_doublewrite_path<\/em> -ot is \u00e1thelyezt\u00fck a \/dev\/shm-be, ami egyes esetekben ak\u00e1r 5 m\u00e1sodpercet is sp\u00f3rolt nek\u00fcnk egy nem megfelel\u0151en le\u00e1ll\u00edtott p\u00e9ld\u00e1ny ind\u00edt\u00e1s\u00e1n\u00e1l.<\/p>\n<p><\/p>\n<p>Mi\u00e9rt \u00e1ll\u00edtjuk le a MySQL-t, miel\u0151tt pillanatfelv\u00e9telt k\u00e9sz\u00edt\u00fcnk? Hiszen k\u00e9sz\u00edthetj\u00fck azt egy m\u0171k\u00f6d\u0151 replik\u00e1b\u00f3l is. Ez igaz, csak hogy az \u00faj DB p\u00e9ld\u00e1ny a pillanatfelv\u00e9tel alapj\u00e1n alap\u00e9rtelmez\u00e9s szerint s\u00e9r\u00fcltnek sz\u00e1m\u00edt, \u00e9s teljes \u00e1tvizsg\u00e1l\u00e1st ig\u00e9nyel az ind\u00edt\u00e1skor. A replik\u00e1t le\u00e1ll\u00edtani egy\u00e9rtelm\u0171en gyorsabb, b\u00e1r ez v\u00e9g\u00fcl a legid\u0151ig\u00e9nyesebb m\u0171velet az eg\u00e9sz folyamatban.<\/p>\n<p><\/p>\n<p>Ennek eredm\u00e9nyek\u00e9nt sokkal elfogadhat\u00f3bb id\u0151z\u00edt\u00e9seket \u00e9s m\u0171k\u00f6d\u00e9sre k\u00e9sz standot kaptunk. B\u00e1r, ahogy a f\u0151 replik\u00e1nak a replik\u00e1ci\u00f3s k\u00e9sedelm\u00e9t bemutat\u00f3 grafikon is mutatja, a helyzet m\u00e9g mindig messze van az ide\u00e1lt\u00f3l:<br \/>\n<img decoding=\"async\" alt=\"V\u00e9kony lemezalap\u00fa Linux f\u00e1jlok biztons\u00e1gi ment\u00e9se. Hogyan k\u00e9sz\u00edthet\u00fcnk m\u00e1solatokat egy h\u00e1rom terab\u00e1jtos MySQL adatb\u00e1zisb\u00f3l 20 m\u00e1sodperc alatt\" src=\"\/wp-content\/uploads\/2020\/03\/9bb7bb7d9abfea124a75616deec57f05.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>M\u00e1s h\u00e1tr\u00e1nyok k\u00f6z\u00f6tt eml\u00edt\u00e9st \u00e9rdemel a Thin LVM medence megfigyel\u00e9s\u00e9nek gyakorlatilag lehetetlens\u00e9ge: a rendszeres standard iostat funkci\u00f3k mellett p\u00e9ld\u00e1ul nem lehet meg\u00e9rteni, hogy a medence melyik eleme termel a legnagyobb terhel\u00e9st a f\u00e1jlrendszeren.<\/p>\n<p><\/p>\n<p>K\u00fcl\u00f6n eml\u00edt\u00e9st \u00e9rdemel egy nagy h\u00e1tr\u00e1ny, amely a fentebb eml\u00edtett optimaliz\u00e1l\u00e1ssal kapcsolatos: YOLO standot kaptunk. K\u00f6r\u00fclbel\u00fcl havonta egyszer vagy k\u00e9tszer az ext4 nem b\u00edrta el az ilyen m\u00e9rt\u00e9k\u0171 megterhel\u00e9st, \u00e9s visszaford\u00edthatatlanul megs\u00e9r\u00fclt, \u00fajraform\u00e1z\u00e1st \u00e9s a replikasor meg\u00faj\u00edt\u00e1s\u00e1t ig\u00e9nyelve. Sebess\u00e9get nyerve, rem\u00e9nytelen\u00fcl t\u00f6nkretett\u00fck a stabilit\u00e1st.<\/p>\n<p><\/p>\n<p>Milyen metrik\u00e1kra \u00e9rdemes figyelni a Thin LVM \u00fczemeltet\u00e9se sor\u00e1n:<\/p>\n<p><\/p>\n<ul>\n<li>Thin pool adath\u00e1nyad %<\/li>\n<li>Thin pool metadath\u00e1nyad %<\/li>\n<\/ul>\n<p><\/p>\n<p>Ha a megd\u00f6bbent\u0151 adathely hi\u00e1ny\u00e1t a standunk t\u00fal\u00e9li (el\u00e9g, ha megtiszt\u00edtjuk a lemezeket), akkor a metadath\u00e1nyad hi\u00e1nya a medence teljes \u00f6sszeoml\u00e1s\u00e1hoz \u00e9s annak null\u00e1r\u00f3l val\u00f3 \u00fajral\u00e9trehoz\u00e1s\u00e1hoz vezet.<\/p>\n<p><\/p>\n<p>A f\u00e1jlrendszer a medenc\u00e9ben id\u0151vel nagyon er\u0151sen t\u00f6redezik. Javaslom, hogy napi egyszer ind\u00edtsuk el a kr\u00f3nikus parancsot: <em>fstrim -v \/var\/lib\/mysql<\/em>.<\/p>\n<p><\/p>\n<p>K\u00f6zbens\u0151 k\u00f6vetkeztet\u00e9sek:<\/p>\n<p><\/p>\n<ul>\n<li>A technol\u00f3gia k\u00f6nnyen alkalmazhat\u00f3, ak\u00e1rcsak maga az LVM, \u00e9s nem ig\u00e9nyel k\u00fcl\u00f6n\u00f6sebb szaktud\u00e1st a m\u00e9rn\u00f6kt\u0151l.<\/li>\n<li>Kiv\u00e1l\u00f3an alkalmas kis m\u00e9ret\u0171 \u00e9s nem t\u00fal leterhelt adatb\u00e1zisokhoz. Min\u00e9l kisebb az adatb\u00e1zis, ann\u00e1l kevesebb chunk mozog a f\u00e1jlrendszeren bel\u00fcl a medenc\u00e9ben, \u00e9s ann\u00e1l alacsonyabb a lemezek terhel\u00e9se.<\/li>\n<li>Feladatunkhoz m\u00e1s megold\u00e1sokat kezdt\u00fcnk keresni, amir\u0151l a k\u00f6vetkez\u0151 szakasz sz\u00f3l.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"vtoroy-stend-tehnologiya-zfs\">A m\u00e1sodik stand, a ZFS technol\u00f3gia<\/h3>\n<p><\/p>\n<p>R\u00e9gen foglalkoztam a ZFS f\u00e1jlrendszerrel, de akkor a ZFS k\u00e9ts\u00e9gtelen\u00fcl j\u00f3l m\u0171k\u00f6d\u00f6tt saj\u00e1t nat\u00edv oper\u00e1ci\u00f3s rendszer csal\u00e1dj\u00e1ban, a Solarisban. Volt egy FreeBSD-re portolt verzi\u00f3, amely el\u00e9g j\u00f3 szint\u0171 megval\u00f3s\u00edt\u00e1ssal rendelkezett. Ezen k\u00edv\u00fcl l\u00e9tezett egy befejezetlen port Linuxra, amit alig haszn\u00e1ltak. Az adatszerkezet B-f\u00e1jl (am\u00fagy ugyan\u00fagy, mint az InnoDB MySQL eset\u00e9ben) miatt a ZFS nem teljes\u00edtett j\u00f3l olyan telep\u00edt\u00e9seken, ahol nagyon sok f\u00e1jl volt. Mindez egy\u00fctt azzal, hogy el\u0151zetesen tanulm\u00e1nyozni kellett a technikai r\u00e9szleteket, hossz\u00fa id\u0151re kiz\u00e1rta ezt a f\u00e1jlrendszert a gyakorlatomb\u00f3l. Megjelentek az ext4 \u00e9s xfs f\u00e1jlrendszerek, amelyek standardd\u00e1 v\u00e1ltak. De figyelembe v\u00e9ve, hogy a ZFS b\u0151ven megfelel a feladatunkhoz, \u00e9s a Linux verzi\u00f3ja, a visszajelz\u00e9sek szerint, egy teljesen megfelel\u0151 term\u00e9kk\u00e9 fejl\u0151d\u00f6tt (b\u00e1r nem teljes t\u00e1mogatotts\u00e1ggal, ez\u00e9rt a ZFS-re teljesen az elej\u00e9t\u0151l rendszert telep\u00edteni csak k\u00fcl\u00f6nf\u00e9le tr\u00fckk\u00f6kkel lehet), \u00fagy d\u00f6nt\u00f6tt\u00fcnk, hogy kipr\u00f3b\u00e1ljuk.<\/p>\n<p><\/p>\n<p>Nyilv\u00e1nval\u00f3 okokb\u00f3l egy hasonl\u00f3 konfigur\u00e1ci\u00f3j\u00fa \u00e1llom\u00e1st v\u00e1lasztottunk (kiv\u00e9ve a RAID vez\u00e9rl\u0151t). Nyolc 1920 GB-os SSD-t telep\u00edtett\u00fcnk. Nem volt kedv\u00fcnk saj\u00e1t h\u00e1l\u00f3zati k\u00e9pet k\u00e9sz\u00edteni a ZFS gy\u00e1mr\u00f3l, ez\u00e9rt az \u00f6sszes lemezb\u0151l lev\u00e1gtunk 50 GB-ot \u00e9s ebb\u0151l MD RAID-10 rendszert k\u00e9sz\u00edtett\u00fcnk. A marad\u00e9k 1950 GB-ot minden lemezen a ZFS RAID-10 anal\u00f3gj\u00e1v\u00e1 egyes\u00edtett\u00fck:<\/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>K\u00e9sz\u00edtett\u00fcnk part\u00edci\u00f3kat a MySQL sz\u00e1m\u00e1ra:<\/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>Figyelj\u00fcnk arra, hogy bekapcsoltuk a hivatalos gzip adats\u0171r\u00edt\u00e9st. Sok processzoreforr\u00e1ssal rendelkez\u00fcnk a szerveren, \u00e9s azok nincsenek teljesen kihaszn\u00e1lva. Ennek eredm\u00e9nyek\u00e9nt a 3 TB-os adatb\u00e1zisunk 1,6 TB-ra zsugorodott, \u00e9s mivel a gyenge l\u00e1ncszem, ahogy a m\u00faltban is, a lemezek maxim\u00e1lis teljes\u00edtm\u00e9nye, min\u00e9l kevesebb adatunk van, ann\u00e1l jobb; az elej\u00e9t\u0151l egy remek b\u00f3nuszt kapunk a ZFS-t\u0151l! Cs\u00facsid\u0151ben, teljes terhel\u00e9s mellett a gzip fenntart\u00e1sa ak\u00e1r 4 magot is ig\u00e9nyel, de nek\u00fcnk ez nem okoz gondot.<\/p>\n<p><\/p>\n<p>A tov\u00e1bbiakban a bevezet\u00e9s gyorsabban haladt. Az LVM \u00e1llom\u00e1sr\u00f3l m\u00e1soltuk a MySQL replik\u00e1ci\u00f3s be\u00e1ll\u00edt\u00e1sokat. K\u00f6lt\u00f6tt\u00fcnk egy kis id\u0151t a ZFS parancsokra val\u00f3 \u00e1t\u00edr\u00e1sra, de alapvet\u0151en az algoritmusok ugyanazok maradtak. P\u00e9lda egy pillanatk\u00e9p l\u00e9trehoz\u00e1s\u00e1ra:<\/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>A tov\u00e1bbi finomhangol\u00e1s keret\u00e9ben: a ZFS sz\u00e9tv\u00e1lasztottuk a metadat\u00e1kat \u00e9s a napl\u00f3kat az l2arc \u00e9s zil mem\u00f3ri\u00e1j\u00e1ba. A feladatunkhoz ez, mint k\u00e9s\u0151bb kider\u00fclt, felesleges volt, de egyel\u0151re fenntartottuk ezt az optimaliz\u00e1l\u00e1st, mert sz\u00fcks\u00e9g eset\u00e9n k\u00f6nnyen m\u00f3dos\u00edthat\u00f3. A negat\u00edv hat\u00e1sok k\u00f6z\u00e9 tartozik, hogy a szerver \u00fajraind\u00edt\u00e1sa ut\u00e1n \u00fajra l\u00e9tre kell hozni a megfelel\u0151 mem\u00f3riater\u00fcleteket. Az al\u00e1bbiakban a zpool status kiv\u00e1g\u00e1sa:<\/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>Ebben a konfigur\u00e1ci\u00f3ban elkezdt\u00fck tesztelni a standot, \u00e9s nagyszer\u0171 eredm\u00e9nyeket kaptunk: k\u00e9t egyidej\u0171leg m\u0171k\u00f6d\u0151 adatb\u00e1zis p\u00e9ld\u00e1nnyal (\u00e9s akt\u00edv f\u0151 replik\u00e1val) a snapshotokon a lemezterhel\u00e9s 50-60% volt.<\/p>\n<p><\/p>\n<p>Megszabadultunk a legfontosabb probl\u00e9m\u00e1nkt\u00f3l, amit a replik\u00e1l\u00e1s k\u00e9sleltet\u00e9s\u00e9nek grafikonja is mutat (hasonl\u00edtsa \u00f6ssze a kor\u00e1bbi grafikonokkal a Thin LVM szekci\u00f3ban):<br \/>\n<img decoding=\"async\" alt=\"V\u00e9kony lemezalap\u00fa Linux f\u00e1jlok biztons\u00e1gi ment\u00e9se. Hogyan k\u00e9sz\u00edthet\u00fcnk m\u00e1solatokat egy h\u00e1rom terab\u00e1jtos MySQL adatb\u00e1zisb\u00f3l 20 m\u00e1sodperc alatt\" src=\"\/wp-content\/uploads\/2020\/03\/15df9283838a4662ff0f68accfde4089.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ezen k\u00edv\u00fcl, ennek k\u00f6sz\u00f6nhet\u0151en, minden m\u0171veletben jelent\u0151sen felgyorsultunk: egy teljes snapshot l\u00e9trehoz\u00e1sa a replik\u00e1l\u00e1s le\u00e1ll\u00edt\u00e1s\u00e1val \u00e9s ind\u00edt\u00e1s\u00e1val legfeljebb 40 m\u00e1sodpercet vesz ig\u00e9nybe, m\u00edg egy \u00faj MySQL p\u00e9ld\u00e1ny telep\u00edt\u00e9se a snapshotb\u00f3l legfeljebb 20 m\u00e1sodpercig tarthat. Ez mindkett\u0151nket \u00e9s a k\u00f3d tesztjeinket is teljes m\u00e9rt\u00e9kben kiel\u00e9g\u00edti.<\/p>\n<p><\/p>\n<p>K\u00f6zbens\u0151 k\u00f6vetkeztet\u00e9sek:<\/p>\n<p><\/p>\n<ul>\n<li>Az eredm\u00e9nyek teljes m\u00e9rt\u00e9kben kiel\u00e9g\u00edtett\u00e9k a sz\u00fcks\u00e9glet\u00fcnket egy \u00e9les adatb\u00e1zis m\u00e1solat\u00e1nak megszerz\u00e9s\u00e9re a k\u00f3d tesztel\u00e9s\u00e9hez.<\/li>\n<li>A technol\u00f3gia meg\u00e9rt\u00e9st ig\u00e9nyel: tudnia kell, mi az a ZFS \u00e9s hogyan kell vele dolgozni.<\/li>\n<li>Nem ellen\u0151rizt\u00fck a ZFS aktu\u00e1lis m\u0171k\u00f6d\u00e9si \u00e1llapot\u00e1t nagy mennyis\u00e9g\u0171 (1 milli\u00f3t\u00f3l) kis f\u00e1jlokn\u00e1l. De felt\u00e9telezz\u00fck, hogy a probl\u00e9ma fenn\u00e1ll, ez\u00e9rt nem javasoln\u00e1m ezt a f\u00e1jlrendszert semmilyen f\u00e1jlt\u00e1rol\u00f3hoz.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"chto-dalshe\">Mi k\u00f6vetkezik?<\/h3>\n<p><\/p>\n<p>A stand-alone setup does not require further adjustments; we are satisfied with the result. In the future, we may add table exclusions for replication settings that are unnecessary for testing, which will further reduce the database size. We have not tested the BTRFS system and its implementation of thin provisioning. However, that task is not a priority anymore since the main goal has been achieved. Overall, we want to move away from the previously described approach\u2014implementing working database migrations into the test environment, creating a separate database testing circuit, and addressing the sharding of the main database. Many of these initiatives are already in progress, and we will definitely share updates in forthcoming articles. <\/p>\n<p><\/p>\n<h3 id=\"itogi\">\u00d6sszegz\u00e9s<\/h3>\n<p><\/p>\n<p>The initial task was accomplished, albeit in an unconventional manner. The intermediate results outlined the advantages and disadvantages of each technology employed, so let\u2019s decide which technology can be used and when:<\/p>\n<p><\/p>\n<ul>\n<li>Thin LVM \u2014 suitable for small databases and when there is neither the desire nor the time to study ZFS.<\/li>\n<li>ZFS \u2014 if there is experience working with it or the ability to dedicate time to learning in any situation. <\/li>\n<\/ul>\n<p><\/p>\n<p>At a higher level, this article is not just a comparison of the two file system technologies. The main idea I\u2019d like to convey and emphasize is that one should not be afraid to think outside the box in business-critical situations and rely solely on ready-made solutions. There was a time when our entire technical department could shake their heads and declare that creating three-terabyte database backups in under a minute was impossible, and that we don\u2019t need risky technologies; let\u2019s just do it the right way. That could have been feasible, but we would have lost around six months to a year and many client trips (travel being our primary business metric) without testing and during deployment. By taking an unconventional approach, we did not spend as much time on implementation, gained experience in both new and previously neglected technologies, and provided testing precisely when we needed it most. Undoubtedly, this positively impacted all our metrics. The choice is always yours, and we, from our side, will continue to share interesting current and future achievements in our blog.<\/p>\n<p>Forr\u00e1s: <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\/hu\/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=\"hu_HU\" \/>\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\/hu\/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\udd47Finom f\u00e1jlrendszer-fenntart\u00e1s Linuxon. Hogyan k\u00e9sz\u00edthet\u00fcnk h\u00e1rom terab\u00e1jtos MySQL adatb\u00e1zisok biztons\u00e1gi m\u00e1solat\u00e1t 20 m\u00e1sodperc alatt | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/hu\/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":"hu_HU","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\/hu\/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\/hu\/wp-json\/wp\/v2\/posts\/74327","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/comments?post=74327"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/74327\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media\/74328"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media?parent=74327"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/categories?post=74327"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/tags?post=74327"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}