Wir l\u00f6schen die LV-Partition und heben die Sperre auf.<\/li>\n<\/ol>\n<\/p>\n
Beispielbefehle zum Klonen der Partitionen einer neuen Datenbankinstanz:<\/p>\n
<\/p>\n
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>\n
Jetzt erz\u00e4hle ich von dem Hauptproblem, mit dem wir bei der Verwendung von Thin Provisioning konfrontiert waren. Wir waren mit der Leistung der SSDs konfrontiert. Das geschah aufgrund der Besonderheiten von Thin LVM: Es arbeitet auf der Ger\u00e4teebene mit low-level Chunks von standardm\u00e4\u00dfig 4 MB. So sah es aus:<\/p>\n
<\/p>\n
\nWir erstellen einen Snapshot aus der Hauptpartition \/var\/lib\/mysql.<\/li>\n Wir starten die Replikation, um den Master einzuholen.<\/li>\n Jede \u00c4nderung in den Tabellen der Replikat zwingt dazu, die alten, unver\u00e4nderten Daten-Chunks im Snapshot-Abschnitt zu speichern.<\/li>\n Jede \u00c4nderung in der getesteten Instanz zwingt dazu, die alten, unver\u00e4nderten Daten-Chunks im Abschnitt des geklonten Snapshots f\u00fcr diese Instanz zu speichern.<\/li>\n Wir erreichen eine IO-Belastung von 100 % auf dem Ger\u00e4t, was alle Operationen verlangsamt und dazu f\u00fchrt, dass die Replikat allm\u00e4hlich hinterherhinkt.<\/li>\n Am Ende des Arbeitstags haben wir ein Stand, das mehrere Stunden hinterherhinkt.<\/li>\n<\/ol>\n<\/p>\n
Wie wir damit umgegangen sind, um ein vern\u00fcnftigeres Ergebnis zu erzielen (die wichtigsten Punkte):<\/p>\n
<\/p>\n
RAID-Controller:<\/p>\n
<\/p>\n
\nWir haben alle Arten der Zwischenspeicherung standardm\u00e4\u00dfig deaktiviert. <\/li>\n Wir haben Writeback eingestellt (wenn Daten in den Puffer gelangen, wird der Schreibvorgang abgeschlossen, bevor die tats\u00e4chliche Speicherung auf der Festplatte erfolgt).<\/li>\n<\/ul>\n<\/p>\n
Dateisystem:<\/p>\n
<\/p>\n
\nIm Einh\u00e4ngepunkt \/var\/lib\/mysql haben wir eingetragen noatime,nodiratime,data=writeback<\/em><\/li>\nWir haben das Journal von ext4 mit tune2fs deaktiviert.<\/li>\n<\/ul>\n<\/p>\n
MySQL:<\/p>\n
<\/p>\n
\nWir haben eingetragen innodb_flush_method = O_DSYNC<\/em> (dadurch wird die Schreibgeschwindigkeit erh\u00f6ht, wodurch die Zuverl\u00e4ssigkeit verringert wird).<\/li>\nWir haben das Journal deaktiviert, Protokolle ben\u00f6tigen wir nicht.<\/li>\n Wir haben eingetragen innodb_buffer_pool_size = 4G<\/em> (je kleiner die Gr\u00f6\u00dfe des InnoDB-Pools, desto schneller wird MySQL beim Herunterfahren abgeschaltet, und desto schneller erstellen wir einen Snapshot).<\/li>\n<\/ul>\n<\/p>\n
Dies ist bei weitem keine vollst\u00e4ndige Liste, insbesondere nicht f\u00fcr MySQL. Die \u00fcbrigen \u00c4nderungen sind jedoch geringf\u00fcgig und oft nicht immer und nicht genau zutreffend. Zum Beispiel haben wir versucht, die Festplatten zu entlasten, und sogar innodb_parallel_doublewrite_path<\/em> in \/dev\/shm verschoben, was in einigen F\u00e4llen beim Start einer nicht korrekt beendeten Instanz bis zu 5 Sekunden einsparen konnte.<\/p>\n<\/p>\n
Warum stoppen wir MySQL, bevor wir einen Snapshot erstellen? Denn wir k\u00f6nnten ihn von einer laufenden Replikat aufnehmen. Das ist richtig, allerdings wird eine neue DB-Instanz auf diesem Snapshot standardm\u00e4\u00dfig als besch\u00e4digt angesehen und ben\u00f6tigt beim Start ein vollst\u00e4ndiges Scannen. Die Replikat zu stoppen, ist eindeutig schneller, auch wenn dies letztendlich die l\u00e4ngste Operation im gesamten Prozess ist.<\/p>\n
<\/p>\n
Infolgedessen haben wir akzeptablere Zeitpl\u00e4ne und einen einsatzbereiten Stand erhalten. Obwohl, wie man anhand des aussagekr\u00e4ftigsten Diagramms zur \u00dcberholzeit der Hauptreplikation sieht, die Situation noch weit vom Ideal entfernt ist:
<\/p>\n
Ein weiterer Nachteil ist die praktische Unm\u00f6glichkeit, den Thin LVM-Pool zu \u00fcberwachen: neben den systemeigenen Standardfunktionen von iostat ist es unm\u00f6glich zu verstehen, welches Element des Pools derzeit die gr\u00f6\u00dfte Last auf das Dateisystem erzeugt.<\/p>\n
<\/p>\n
Ein gro\u00dfer Nachteil, der mit der oben beschriebenen Optimierung verbunden ist, soll gesondert erw\u00e4hnt werden: Wir haben einen YOLO-Stand erhalten. Etwa alle ein bis zwei Monate hielt ext4 solchen Misshandlungen nicht stand und brach unwiderruflich zusammen, was eine Neuformatierung und das Wiederherstellen der Replik erforderte. W\u00e4hrend wir an Geschwindigkeit gewannen, haben wir hoffnungslos die Stabilit\u00e4t ruiniert.<\/p>\n
<\/p>\n
Welche Metriken sollten w\u00e4hrend des Betriebs von Thin LVM \u00fcberwacht werden:<\/p>\n
<\/p>\n
\nThin pool Daten %<\/li>\n Thin pool Metadaten %<\/li>\n<\/ul>\n<\/p>\n
Wenn unser Stand nur ein volles Datenvolumen \u00fcbersteht (es reicht aus, die Festplatten zu reinigen), f\u00fchrt ein volles Metadatenvolumen jedoch zum vollst\u00e4ndigen Zusammenbruch des Pools und der Notwendigkeit, ihn von Grund auf neu zu erstellen.<\/p>\n
<\/p>\n
Das Dateisystem innerhalb des Pools fragmentiert im Laufe der Zeit stark. Ich empfehle, t\u00e4glich \u00fcber cron den Befehl auszuf\u00fchren fstrim -v \/var\/lib\/mysql<\/em>.<\/p>\n<\/p>\n
Zwischenergebnisse:<\/p>\n
<\/p>\n
\nDie Technologie ist einfach anwendbar, ebenso wie LVM selbst, und erfordert keine besondere Qualifikation des Ingenieurs.<\/li>\n Sie eignet sich gut f\u00fcr kleine Datenbanken und moderate Lasten. Je kleiner die Datenbank, desto weniger Chunks bewegen sich im Dateisystem innerhalb des Pools, und desto geringer ist die Belastung der Festplatten.<\/li>\n F\u00fcr unsere Aufgabe begannen wir, nach anderen L\u00f6sungen zu suchen, wor\u00fcber im n\u00e4chsten Abschnitt gesprochen wird.<\/li>\n<\/ul>\n<\/p>\n
Der zweite Stand, die Technologie ZFS<\/h3>\n <\/p>\n
Vor langer Zeit hatte ich mit dem Dateisystem ZFS zu tun, aber damals funktionierte ZFS zuverl\u00e4ssig gut auf seinem eigenen Betriebssystem Solaris. Es gab eine auf FreeBSD portierte Version mit einem akzeptablen Implementierungsgrad. Au\u00dferdem gab es ein unfertiges Port auf Linux, das kaum Verwendung fand. Aufgrund der B-Baum-Datenstruktur (\u00fcbrigens hat auch InnoDB MySQL diese Struktur) zeigte ZFS bei Installationen mit einer sehr gro\u00dfen Anzahl von Dateien schwache Leistungen. All dies zusammen mit der Notwendigkeit, die technischen Grundlagen vor der Nutzung zu lernen, f\u00fchrte dazu, dass ich dieses Dateisystem lange Zeit aus meiner Praxis verbannt habe. Es erschienen ext4 und xfs, die zum Standard wurden. Aber da ZFS nach wie vor perfekt f\u00fcr unsere Anforderungen geeignet ist und die Linux-Version laut Berichten zu einem durchaus brauchbaren Produkt gewachsen ist (auch wenn sie nicht voll unterst\u00fctzt wird, weshalb die Installation eines Systems auf ZFS von Grund auf nur mit verschiedenen Tricks m\u00f6glich ist), haben wir uns entschieden, es auszuprobieren.<\/p>\n
<\/p>\n
Aus verst\u00e4ndlichen Gr\u00fcnden w\u00e4hlten wir einen Stand mit einer \u00e4hnlichen Konfiguration (au\u00dfer dem RAID-Controller). Wir installierten acht SSDs mit jeweils 1920 GB. Da wir keine Lust hatten, ein eigenes Netzwerk-Image f\u00fcr die Installation des Servers auf reinem ZFS zu schreiben, nahmen wir von allen Platten jeweils 50 GB und machten daraus ein MD RAID-10 f\u00fcr das System. Die verbleibenden 1950 GB auf jeder Platte kombinierten wir in einem ZFS-\u00c4quivalent von RAID-10:<\/p>\n
<\/p>\n
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>\n
Wir machten Partitionen f\u00fcr MySQL:<\/p>\n
<\/p>\n
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>\n
Bitte beachten Sie, dass wir die standardm\u00e4\u00dfige Datenkompression gzip aktiviert haben. Unsere Server-Ressourcen sind reichlich vorhanden und nicht vollst\u00e4ndig ausgelastet. Infolgedessen verwandelten sich 3 TB unserer Datenbank in 1,6 TB, und da die maximale Leistung der Platten, wie auch im letzten Fall, das schw\u00e4chste Glied ist, gilt: Je weniger Daten, desto besser. Von Anfang an profitieren wir also gro\u00dfartig von ZFS! Zu Spitzenzeiten beansprucht die vollst\u00e4ndige Auslastung zur Unterst\u00fctzung von gzip bis zu 4 Kerne, aber das ist uns nicht zu viel.<\/p>\n
<\/p>\n
Dann ging die Implementierung schneller voran. Wir \u00fcbertrugen die MySQL-Replikationseinstellungen eins zu eins von dem LVM-Stand. Es war n\u00f6tig, etwas Zeit f\u00fcr die Umschreibung der Skripte in ZFS-Befehle aufzuwenden, aber im Gro\u00dfen und Ganzen blieben die Algorithmen unver\u00e4ndert. Beispiel f\u00fcr die Erstellung eines Snapshots:<\/p>\n
<\/p>\n
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>\n
Von zus\u00e4tzlichem Tuning: Die ZFS-Partitionen mit Metadaten und Logs l2arc und zil wurden in den Speicher ausgelagert. Bei unserer Aufgabe stellte sich sp\u00e4ter heraus, dass dies \u00fcberfl\u00fcssig war, doch vorerst haben wir diese Optimierung beibehalten, eine Anpassung ist bei Bedarf unkompliziert. Zu den negativen Effekten geh\u00f6rt, dass wir nach einem Serverneustart die entsprechenden Speicherbereiche neu erstellen m\u00fcssen. Die Daten gehen dabei nicht verloren. Auszug zpool status:<\/p>\n
<\/p>\n
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>\n
In dieser Konfiguration haben wir begonnen, die Testumgebung zu evaluieren, und erzielten hervorragende Ergebnisse: Mit zwei gleichzeitig betriebenen DB-Instanzen (und einer aktiven Hauptreplik) auf Snapshots hatten wir eine Auslastung der Festplatten von 50-60 %.<\/p>\n
<\/p>\n
Wir haben unser Hauptproblem beseitigt, was im Diagramm der Replikationsverz\u00f6gerung deutlich wird (im Vergleich zur vorherigen Grafik im Abschnitt D\u00fcnnes LVM):
<\/p>\n
Zus\u00e4tzlich und dank dessen haben wir alle Operationen deutlich beschleunigt: Die vollst\u00e4ndige Erstellung eines Snapshots mit Stopp und Neustart der Replik dauert bis zu 40 Sekunden, das Bereitstellen einer neuen MySQL-Instanz aus einem Snapshot ben\u00f6tigt bis zu 20 Sekunden. Dies ist sowohl f\u00fcr uns als auch f\u00fcr unsere Programmcode-Tests mehr als ausreichend.<\/p>\n
<\/p>\n
Zwischenergebnisse:<\/p>\n
<\/p>\n
\nDie Ergebnisse haben unseren Bedarf an einer Kopie der Produktionsdatenbank f\u00fcr die Code-Tests vollst\u00e4ndig erf\u00fcllt.<\/li>\n Die Technologie erfordert ein Einarbeiten: Man muss verstehen, was ZFS ist und wie man damit arbeitet.<\/li>\n Wir haben den aktuellen Status der ZFS-Arbeit mit einer gro\u00dfen Anzahl (ab 1 Million) kleiner Dateien nicht getestet. Wir gehen jedoch davon aus, dass das Problem weiterhin besteht, weshalb ich dieses Dateisystem nicht f\u00fcr irgendwelche Dateispeicher empfehlen w\u00fcrde.<\/li>\n<\/ul>\n<\/p>\n
Was folgt jetzt?<\/h3>\n <\/p>\n
Innerhalb des Standes gibt es nichts weiter zu tun, das Ergebnis ist f\u00fcr uns zufriedenstellend. M\u00f6glicherweise f\u00fcgen wir in Zukunft Ausnahmen f\u00fcr Tabellen, die f\u00fcr Tests nicht erforderlich sind, in die Replikationseinstellungen ein; dies w\u00fcrde das Volumen der Datenbank weiter reduzieren. Wir haben das BTRFS-System und dessen Implementierung f\u00fcr Thin Provisioning nicht getestet. Diese Aufgabe steht jedoch nicht mehr zur Debatte, da das Hauptziel erreicht wurde. Insgesamt w\u00fcnschen wir uns nat\u00fcrlich, von dem oben beschriebenen Ansatz abzugehen \u2014 funktionierende Datenbankmigrationen in die Testumgebung zu realisieren, einen separaten Testkreis f\u00fcr die Datenbank zu schaffen und uns mit Sharding der Hauptdatenbank zu befassen. Vieles davon setzen wir bereits in die Praxis um, wor\u00fcber wir in zuk\u00fcnftigen Artikeln unbedingt berichten werden. <\/p>\n
<\/p>\n
Ergebnisse<\/h3>\n <\/p>\n
Die urspr\u00fcngliche Aufgabe wurde gel\u00f6st, auch wenn auf ungew\u00f6hnliche Weise. In den Zwischenberichten wurden die Vor- und Nachteile jeder eingesetzten Technologie beschrieben, also lassen Sie uns entscheiden, welche Technologie wann verwendet werden kann:<\/p>\n
<\/p>\n
\nThin LVM \u2014 bei kleinen Datenbanken und wenn man ZFS nicht lernen m\u00f6chte oder keine Zeit hat.<\/li>\n ZFS \u2014 wenn man Erfahrung im Umgang damit hat oder bereit ist, in jeder Situation Zeit in das Lernen zu investieren. <\/li>\n<\/ul>\n<\/p>\n
Auf einer h\u00f6heren Ebene betrachtet, ist dieser Artikel nicht nur ein Vergleich von zwei Dateisystemtechnologien. Die Hauptidee, die ich vermitteln und festigen m\u00f6chte, ist, dass man in gesch\u00e4ftskritischen Situationen keine Angst haben sollte, unkonventionell zu denken und sich nicht nur auf fertige Rezepte zu st\u00fctzen. Fr\u00fcher h\u00e4tten wir als gesamtes Technikteam nur den Kopf sch\u00fctteln und sagen k\u00f6nnen, dass die Aufgabe, dreiterabyte gro\u00dfe Datenbankkopien in weniger als einer Minute zu erstellen, unm\u00f6glich sei und wir keine riskanten Technologien brauchen, also lassen Sie es uns richtig machen. Das w\u00e4re m\u00f6glich gewesen, aber wir h\u00e4tten dabei etwa ein halbes Jahr bis ein Jahr und viele Kundenreisen (Reisen sind unser wichtigster Gesch\u00e4ftsfaktor) ohne Tests beim Rollout verloren. Indem wir unkonventionell handelten, verloren wir nicht viel Zeit mit der Implementierung, sammelten Erfahrungen mit neuen und in Vergessenheit geratenen alten Technologien und erm\u00f6glichten Testen genau in dem Moment, als wir es dringend ben\u00f6tigten. Dies hatte zweifellos einen positiven Einfluss auf alle unsere Kennzahlen. Die Wahl liegt immer bei Ihnen, und wir werden unsererseits weiterhin in unserem Blog \u00fcber interessante aktuelle und zuk\u00fcnftige Errungenschaften berichten.<\/p>\n
Quelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\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 […]<\/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\n\t
![\"Feines](\"\/wp-content\/uploads\/2020\/03\/7502785a78bd6f069913e97829ff2f63.png\")
<\/p>\n