{"id":53966,"date":"2019-12-14T00:00:00","date_gmt":"2019-12-13T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa"},"modified":"2020-02-18T14:01:55","modified_gmt":"2020-02-18T11:01:55","slug":"ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","title":{"rendered":"Verwendung von Partitionierung in MySQL f\u00fcr Zabbix mit einer gro\u00dfen Anzahl von \u00dcberwachungsobjekten","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Zur \u00dcberwachung von Servern und Diensten nutzen wir seit langem und nach wie vor erfolgreich eine kombinierte L\u00f6sung auf der Basis von Nagios und Munin. Diese Kombination hat jedoch einige Nachteile, weshalb wir, wie viele andere, aktiv Zabbix<\/a><\/noindex>. In diesem Artikel berichten wir dar\u00fcber, wie man mit minimalem Aufwand das Leistungsproblem bei einer steigenden Anzahl von abgerufenen Metriken und dem Wachstum von MySQL-Datenbanken l\u00f6sen kann.
\n<\/a><\/noindex><\/p>\n

Probleme bei der Nutzung der MySQL-Datenbank zusammen mit Zabbix<\/h3>\n

\nSolange die Datenbank klein war und die Anzahl der darin gespeicherten Metriken gering, verlief alles hervorragend. Der standardm\u00e4\u00dfige Housekeeper-Prozess, der vom Zabbix-Server gestartet wird, entfernte erfolgreich veraltete Eintr\u00e4ge aus der Datenbank, ohne sie wachsen zu lassen. Doch als die Anzahl der abgerufenen Metriken zunahm und das Volumen der Datenbank eine bestimmte Gr\u00f6\u00dfe erreichte, wurde alles schlechter. Der Housekeeper konnte die Daten nicht mehr innerhalb des ihm zugewiesenen Zeitrahmens l\u00f6schen, sodass alte Daten in der Datenbank blieben. W\u00e4hrend des Betriebs des Housekeepers kam es zu einer erh\u00f6hten Belastung des Zabbix-Servers, die l\u00e4ngere Zeit bestehen blieb. Es wurde klar, dass diese Situation irgendwie gel\u00f6st werden musste.<\/p>\n

Dies ist ein bekanntes Problem, praktisch jeder, der mit gro\u00dfen Mengen an Monitoring in Zabbix gearbeitet hat, ist damit konfrontiert worden. Es gab auch einige L\u00f6sungen: zum Beispiel der Wechsel von MySQL zu PostgreSQL oder sogar Elasticsearch, aber die einfachste und bew\u00e4hrteste L\u00f6sung war der \u00dcbergang zur Partitionierung der Tabellen, die die Metrikdaten in der MySQL-Datenbank speichern. Wir haben uns entschieden, genau diesen Weg zu gehen.<\/p>\n

Der \u00dcbergang von normalen MySQL-Tabellen zu partitionierten Tabellen<\/h3>\n

\nZabbix ist gut dokumentiert und die Tabellen, in denen er die Metriken speichert, sind bekannt. Es handelt sich um die Tabellen: history<\/code>, in denen Float-Werte gespeichert werden, history_str<\/code>, in denen kurze String-Werte gespeichert werden, history_text<\/code>, in denen lange Textwerte gespeichert sind und history_uint<\/code>, in denen ganzzahlige Werte gespeichert werden. Es gibt auch die Tabelle trends<\/code>, die die Dynamik der \u00c4nderungen speichert, aber diese haben wir beschlossen, nicht zu ber\u00fchren, da ihre Gr\u00f6\u00dfe gering ist und wir sp\u00e4ter darauf zur\u00fcckkommen werden.<\/p>\n

Im Allgemeinen war klar, welche Tabellen verarbeitet werden mussten. Wir entschieden uns, Partionen f\u00fcr jede Woche zu erstellen, mit Ausnahme der letzten, basierend auf den Tageszahlen des Monats, d.h. vier Partitionen pro Monat: vom 1. bis zum 7., vom 8. bis zum 14., vom 15. bis zum 21. und vom 22. bis zum 1. (des n\u00e4chsten Monats). Die Schwierigkeit bestand darin, die ben\u00f6tigen Tabellen \u201eon-the-fly\u201c in partitionierte zu verwandeln, ohne den Zabbix-Server und die Metrik-Sammlung zu unterbrechen.<\/p>\n

Komischerweise kam uns dabei die Datenstruktur der Tabellen zugute. Zum Beispiel hat die Tabelle history <\/code>die folgende Struktur:<\/p>\n

`itemid` bigint(20) unsigned NOT NULL,\n`clock` int(11) NOT NULL DEFAULT '0',\n`value` double(16,4) NOT NULL DEFAULT '0.0000',\n`ns` int(11) NOT NULL DEFAULT '0',<\/code><\/pre>\n
\nwobei<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nWie wir sehen k\u00f6nnen, wird jede Metrik letztendlich in einer Tabelle mit zwei sehr wichtigen und f\u00fcr uns praktischen Feldern itemid<\/b> und clock<\/b>eingetragen. Somit k\u00f6nnen wir durchaus eine tempor\u00e4re Tabelle mit dem Namen history_tmp<\/code>, einrichten und daf\u00fcr das Partitionieren konfigurieren und anschlie\u00dfend alle Daten aus der Tabelle history<\/code>dorthin \u00fcbertragen, und dann die Tabelle history<\/code> in history_old<\/code>umbenennen und die Tabelle history_tmp<\/code> in history<\/code>, nach der wir dann die noch nicht \u00fcbertragenen Daten aus history_old<\/code> in history <\/code>nachtragen und history_old<\/code>l\u00f6schen. Das kann vollkommen sicher geschehen, wir verlieren nichts, denn die oben genannten Felder itemid <\/b>und clock <\/b>stellen die Bindung einer bestimmten Metrik an einen bestimmten Zeitpunkt sicher, nicht an eine fortlaufende Nummer.<\/p>\n
Der gesamte \u00dcbergangsprozess<\/h3>\n
<\/p>\n
Achtung! Es ist sehr empfehlenswert, vor Beginn irgendwelcher Ma\u00dfnahmen eine vollst\u00e4ndige Datensicherung der Datenbank zu erstellen. Wir sind schlie\u00dflich alle Menschen und k\u00f6nnen einen Fehler bei der Eingabe der Befehle machen, was zu Datenverlust f\u00fchren k\u00f6nnte. Ja, eine Datensicherung garantiert nicht die maximale Aktualit\u00e4t, aber es ist besser, eine solche zu haben, als gar keine.<\/p><\/blockquote>\n
 Also schalten wir nichts ab und halten nichts an. Wichtig ist, dass auf dem MySQL-Server ausreichend Freiraum auf der Festplatte vorhanden ist, d.h. dass f\u00fcr jede der oben genannten Tabellen history<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>mindestens genug Platz f\u00fcr die Erstellung einer Tabelle mit dem Suffix \u201e_tmp\u201c zur Verf\u00fcgung steht, wobei zu ber\u00fccksichtigen ist, dass diese denselben Umfang wie die urspr\u00fcngliche Tabelle haben wird.<\/p>\n
Wir werden nicht alles mehrmals f\u00fcr jede der oben genannten Tabellen beschreiben und betrachten alles nur am Beispiel einer von ihnen \u2014 der Tabelle history<\/code>.<\/p>\n
Also erstellen wir eine leere Tabelle history_tmp <\/code>basierend auf der Struktur der Tabelle history<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nWir erstellen die ben\u00f6tigten Partitionen. Als Beispiel werden wir dies f\u00fcr einen Monat tun. Jede Partition wird auf der Grundlage einer Partitionierungsregel erstellt, die auf dem Wert des Feldes basiert clock<\/b>, den wir mit dem Zeitstempel vergleichen:<\/p>\n
ALTER TABLE `history_tmp` PARTITION BY RANGE( clock ) (\nPARTITION p20190201 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-02-01 00:00:00\")),\nPARTITION p20190207 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-02-07 00:00:00\")),\nPARTITION p20190214 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-02-14 00:00:00\")),\nPARTITION p20190221 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-02-21 00:00:00\")),\nPARTITION p20190301 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-01 00:00:00\"))\n);<\/code><\/pre>\n
\nDieser Operator f\u00fcgt die Partitionierung f\u00fcr die von uns erstellte Tabelle hinzu history_tmp<\/code>. Lassen Sie uns pr\u00e4zisieren, dass die Daten, bei denen der Wert des Feldes clock <\/b>weniger als \"2019-02-01 00:00:00\" ist, in die Partition p20190201<\/i>, dann die Daten, bei denen der Wert des Feldes clock<\/b> gr\u00f6\u00dfer als \"2019-02-01 00:00:00\" aber weniger als \"2019-02-07 00:00:00\" sind, in die Partition p20190207 <\/i>und so weiter.<\/p>\n
Wichtiger Hinweis:<\/b> Was passiert, wenn wir in der partitionierten Tabelle Daten haben, bei denen der Wert des Feldes clock gr\u00f6\u00dfer oder gleich \"2019-03-01 00:00:00\" ist? Da es f\u00fcr diese Daten keine passende Partition gibt, werden sie nicht in die Tabelle aufgenommen und gehen verloren. Daher m\u00fcssen Sie daran denken, rechtzeitig zus\u00e4tzliche Partitionen zu erstellen, um solche Datenverluste zu vermeiden (wie unten beschrieben).<\/p><\/blockquote>\n
 Nun, die tempor\u00e4re Tabelle ist vorbereitet. Lassen Sie uns die Daten einpflegen. Der Prozess kann eine betr\u00e4chtliche Zeit in Anspruch nehmen, aber gl\u00fccklicherweise blockiert er keine anderen Abfragen, sodass man einfach Geduld haben muss:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nDas Schl\u00fcsselwort IGNORE ist beim ersten Einpflegen nicht zwingend erforderlich, da sich ohnehin keine Daten in der Tabelle befinden, es wird jedoch ben\u00f6tigt, wenn Sie nachtr\u00e4gliche Daten hinzuf\u00fcgen. Au\u00dferdem kann es n\u00fctzlich sein, wenn Sie w\u00e4hrend des Datenimports den Prozess abbrechen und neu starten mussten.<\/p>\n
Also, nach einer gewissen Zeit (vielleicht sogar mehreren Stunden) ist der erste Datenimport erfolgreich abgeschlossen. Wie Sie verstehen, enth\u00e4lt die Tabelle jetzt history_tmp <\/code>nicht alle Daten aus der Tabelle history<\/code>, sondern nur die, die zu dem Zeitpunkt, als die Abfrage ausgef\u00fchrt wurde, vorhanden waren. Hier haben Sie tats\u00e4chlich die Wahl: entweder wir machen einen weiteren Durchgang (wenn der Import lange gedauert hat), oder wir wechseln sofort zur Umbenennung der Tabellen, von der weiter oben die Rede war. Lassen Sie uns zuerst \u00fcber den zweiten Durchgang sprechen. Zun\u00e4chst m\u00fcssen wir den Zeitpunkt des letzten eingef\u00fcgten Datensatzes in history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nAngenommen, Sie haben erhalten: 1551045645<\/b>Jetzt verwenden wir den erhaltenen Wert im zweiten Durchgang der Dateneingabe:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nDieser Durchgang sollte wesentlich schneller abgeschlossen werden. Aber wenn der erste Durchgang Stunden gedauert hat und der zweite ebenfalls lange dauert, k\u00f6nnte es sinnvoll sein, einen dritten Durchgang zu machen, der genau wie der zweite ausgef\u00fchrt wird.<\/p>\n
Am Ende f\u00fchren wir erneut die Abfrage der Zeit der letzten eingef\u00fcgten Datens\u00e4tze in history_tmp<\/code>, durch:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nAngenommen, Sie haben erhalten 1551085645<\/b>. Speichern Sie diesen Wert - wir werden ihn f\u00fcr das Nachf\u00fcllen ben\u00f6tigen.<\/p>\n
Und jetzt, nachdem die erste Dateneingabe in history_tmp <\/code>abgeschlossen ist, beginnen wir mit der Umbenennung der Tabellen:<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nWir haben diesen Block als eine Transaktion gestaltet, um den Moment der Datenaufnahme in eine nicht existierende Tabelle zu vermeiden, da die Tabelle nach der ersten UMBENENNUNG bis zur Ausf\u00fchrung der zweiten UMBENENNUNG history <\/code>nicht existieren wird. Aber selbst wenn zwischen den UMBENENNUNGEN Daten in die Tabelle history <\/code>gelangen, und die Tabelle noch nicht existiert (wegen der Umbenennung), werden wir eine kleine Anzahl von Einf\u00fcgefehlern erhalten, die vernachl\u00e4ssigbar sind (wir haben Monitoring, keinen Bankbetrieb).<\/p>\n
Jetzt haben wir eine neue Tabelle history<\/code> mit Partitionierung, aber es fehlen die Daten, die w\u00e4hrend des letzten Einf\u00fcgens in die Tabelle history_tmp<\/code>erhalten wurden. Aber diese Daten haben wir in der Tabelle history_old <\/code>und wir werden sie jetzt von dort nachf\u00fcllen. Dazu ben\u00f6tigen wir den zuvor gespeicherten Wert 1551085645. Warum wir diesen Wert gespeichert haben und nicht die maximale Einf\u00fcgezeit aus der aktuellen Tabelle verwendet haben history<\/code>? \u041f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u043d\u043e\u0432\u044b\u0435 \u0434\u0430\u043d\u043d\u044b\u0435 \u0443\u0436\u0435 \u0432 \u043d\u0435\u0451 \u043f\u043e\u0441\u0442\u0443\u043f\u0430\u044e\u0442 \u0438 \u043c\u044b \u043f\u043e\u043b\u0443\u0447\u0438\u043c \u043d\u0435\u0432\u0435\u0440\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f. \u0418\u0442\u0430\u043a, \u0434\u043e\u0437\u0430\u043b\u0438\u0432\u0430\u0435\u043c \u0434\u0430\u043d\u043d\u044b\u0435:<\/p>\n
INSERT IGNORE INTO `history` SELECT * FROM history_old WHERE clock>=1551045645;<\/code><\/pre>\n
\nNach Abschluss dieser Operation haben wir in der neuen, partitionierten Tabelle history <\/code>alle Daten, die in der alten waren, plus die, die bereits nach der Umbenennung der Tabelle eingegangen sind. Die Tabelle history_old <\/code>ist nicht mehr n\u00f6tig. Man kann sie sofort l\u00f6schen oder zuvor eine Sicherungskopie erstellen (wenn man paranoid ist).<\/p>\n
Der oben beschriebene Prozess muss f\u00fcr die Tabellen wiederholt werden history_str<\/code>, history_text <\/code>und history_uint<\/code>.<\/p>\n
Was in den Zabbix Server-Einstellungen angepasst werden muss<\/h3>\n
\nJetzt liegt die Wartung der Datenbank in Bezug auf die Datenhistorie in unserer Verantwortung. Das bedeutet, dass Zabbix keine alten Daten mehr l\u00f6schen muss \u2013 das werden wir selbst \u00fcbernehmen. Damit der Zabbix-Server nicht versucht, die Daten selbst zu bereinigen, m\u00fcssen Sie sich in die Weboberfl\u00e4che von Zabbix einloggen, im Men\u00fc \u201eAdministration\u201c w\u00e4hlen, anschlie\u00dfend das Untermen\u00fc \u201eAllgemein\u201c w\u00e4hlen und dann im Dropdown-Men\u00fc rechts \u201eHistorie bereinigen\u201c ausw\u00e4hlen. Auf der erscheinenden Seite m\u00fcssen Sie alle H\u00e4kchen der Gruppe \u201eHistorie\u201c entfernen und auf die Schaltfl\u00e4che \u201eAktualisieren\u201c klicken. Dies verhindert eine unn\u00f6tige Bereinigung der Tabellen. historie*<\/code> \u00fcber den Housekeeper.<\/p>\n
Beachten Sie auf dieser Seite die Gruppe \u201e\u00c4nderungsdynamik\u201c. Das ist genau die Tabelle, trends<\/code>, auf die wir zur\u00fcckkommen wollten. Wenn sie ebenfalls zu gro\u00df geworden ist und partitioniert werden muss, entfernen Sie auch bei dieser Gruppe die H\u00e4kchen und bearbeiten Sie diese Tabelle genauso wie die Tabellen historie*<\/code>.<\/p>\n
Weitere Wartung der Datenbank<\/h3>\n
\nWie zuvor erw\u00e4hnt, ist es f\u00fcr die ordnungsgem\u00e4\u00dfe Funktion von partitionierten Tabellen wichtig, rechtzeitig Partitionen zu erstellen. Das kann so erfolgen:<\/p>\n
ALTER TABLE `historie` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\nDa wir zudem partitionierte Tabellen erstellt und dem Zabbix-Server das Bereinigen untersagt haben, liegt nun auch die L\u00f6schung alter Daten in unserer Verantwortung. Zum Gl\u00fcck gibt es hierbei \u00fcberhaupt keine Probleme. Das geschieht einfach durch das L\u00f6schen der Partition, deren Daten uns nicht mehr ben\u00f6tigt werden. <\/p>\n
Zum Beispiel:<\/p>\n
ALTER TABLE historie DROP PARTITION p20190201;<\/code><\/pre>\n
\nIm Unterschied zu den DELETE FROM-Befehlen mit Angabe eines Datumsbereichs wird das DROP PARTITION in wenigen Sekunden ausgef\u00fchrt, was die Datenbank nicht belastet Server<\/a> und funktioniert ebenso problemlos bei der Verwendung von MySQL-Replikation.<\/p>\n
Fazit<\/h3>\n
\nDie beschriebene L\u00f6sung hat sich bew\u00e4hrt. Das Datenvolumen w\u00e4chst, aber es gibt keine sp\u00fcrbare Verlangsamung der Leistung.
\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0414\u043b\u044f \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438 \u0441\u043b\u0443\u0436\u0431 \u0443 \u043d\u0430\u0441 \u0434\u0430\u0432\u043d\u043e, \u0438 \u0432\u0441\u0435 \u0435\u0449\u0435 \u0443\u0441\u043f\u0435\u0448\u043d\u043e, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u043a\u043e\u043c\u0431\u0438\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u043d\u0430 \u0431\u0430\u0437\u0435 Nagios \u0438 Munin. \u041e\u0434\u043d\u0430\u043a\u043e \u044d\u0442\u0430 \u0441\u0432\u044f\u0437\u043a\u0430 \u0438\u043c\u0435\u0435\u0442 \u0440\u044f\u0434 \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043a\u043e\u0432, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u044b, \u043a\u0430\u043a \u0438 \u043c\u043d\u043e\u0433\u0438\u0435, \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0438\u0440\u0443\u0435\u043c Zabbix. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u0438\u043d\u0438\u043c\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u0443\u0441\u0438\u043b\u0438\u044f\u043c\u0438 \u043c\u043e\u0436\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0441 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c\u044e \u043f\u0440\u0438 \u0443\u0432\u0435\u043b\u0438\u0447\u0435\u043d\u0438\u0438 \u0447\u0438\u0441\u043b\u0430 \u0441\u043d\u0438\u043c\u0430\u0435\u043c\u044b\u0445 \u043c\u0435\u0442\u0440\u0438\u043a \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53966","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Nutzung von Partitionierung in MySQL f\u00fcr Zabbix mit einer gro\u00dfen Anzahl an \u00fcberwachten Objekten | ProHoster","description":"Zur \u00dcberwachung von Servern und Diensten nutzen wir seit langem und weiterhin erfolgreich eine kombinierte L\u00f6sung auf der Basis von Nagios und Munin.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\u0418\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 MySQL \u0434\u043b\u044f Zabbix \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u043e\u0431\u044a\u0435\u043a\u0442\u043e\u0432 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 | ProHoster","og:description":"\u0414\u043b\u044f \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438 \u0441\u043b\u0443\u0436\u0431 \u0443 \u043d\u0430\u0441 \u0434\u0430\u0432\u043d\u043e, \u0438 \u0432\u0441\u0435 \u0435\u0449\u0435 \u0443\u0441\u043f\u0435\u0448\u043d\u043e, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u043a\u043e\u043c\u0431\u0438\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u043d\u0430 \u0431\u0430\u0437\u0435 Nagios \u0438 Munin.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","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":"2019-12-13T21:00:00+00:00","article:modified_time":"2020-02-18T11:01:55+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53966","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":"2026-01-24 09:31:21","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:14:29","updated":"2026-01-24 09:31:21","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/53966","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=53966"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/53966\/revisions"}],"predecessor-version":[{"id":172868,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/53966\/revisions\/172868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=53966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=53966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=53966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}