{"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":"Partitionierung in MySQL f\u00fcr Zabbix mit einer gro\u00dfen Anzahl von zu \u00fcberwachenden Objekten","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

F\u00fcr das Monitoring von Servern und Diensten nutzen wir seit langem erfolgreich eine Kombination aus Nagios und Munin. Dieses Setup hat jedoch einige Nachteile, daher setzen wir, wie viele andere, aktiv auf Zabbix<\/a><\/noindex>. In diesem Artikel zeigen wir Ihnen, wie Sie mit minimalem Aufwand das Leistungsproblem bei einer steigenden Anzahl abgerufener Metriken und dem Wachstum der MySQL-Datenbank l\u00f6sen k\u00f6nnen.
\n<\/a><\/noindex><\/p>\n

Probleme bei der Verwendung von MySQL in Verbindung mit Zabbix<\/h3>\n

\nSolange die Datenbank klein war und die Anzahl der gespeicherten Metriken gering war, lief alles wunderbar. Der eingebaute Housekeeper-Prozess, der vom Zabbix Server selbst gestartet wird, entfernte erfolgreich veraltete Eintr\u00e4ge aus der Datenbank, sodass diese nicht wuchs. Sobald jedoch die Anzahl der abgerufenen Metriken zunahm und das Volumen der Datenbank eine bestimmte Gr\u00f6\u00dfe erreichte, verschlechterte sich die Situation. Der Housekeeper kam nicht mehr mit dem L\u00f6schen der Daten im vorgegebenen Zeitrahmen nach, sodass alte Daten in der Datenbank verblieben. W\u00e4hrend der Arbeitszeit des Housekeepers entstand eine erh\u00f6hte Belastung f\u00fcr den Zabbix Server, die lange andauern konnte. Es wurde klar, dass die Situation irgendwie gel\u00f6st werden musste.<\/p>\n

Dies ist ein bekanntes Problem; fast jeder, der mit gro\u00dfen Monitoring-Umf\u00e4ngen in Zabbix gearbeitet hat, ist auf dasselbe gesto\u00dfen. Es gab auch mehrere L\u00f6sungen: beispielsweise den Wechsel von MySQL zu PostgreSQL oder sogar Elasticsearch, aber die einfachste und bew\u00e4hrte L\u00f6sung war der \u00dcbergang zur Partitionierung der Tabellen, die die Metrikdaten in der MySQL-Datenbank speichern. Wir haben uns entschieden, diesen Weg zu gehen.<\/p>\n

\u00dcbergang von regul\u00e4ren MySQL-Tabellen zu partitionierten Tabellen<\/h3>\n

\nZabbix ist gut dokumentiert und die Tabellen, in denen es Metriken speichert, sind bekannt. Es handelt sich um folgende Tabellen: history<\/code>, wo float-Werte gespeichert werden, history_str<\/code>, wo kurze Zeichenfolgen gespeichert werden, history_text<\/code>, wo lange Textwerte gespeichert werden und history_uint<\/code>, wo ganzzahlige Werte gespeichert werden. Zudem gibt es eine Tabelle trends<\/code>, die die Dynamik der \u00c4nderungen speichert, die wir jedoch nicht anfassen wollten, da ihre Gr\u00f6\u00dfe gering ist, und wir uns sp\u00e4ter noch einmal damit besch\u00e4ftigen werden.<\/p>\n

Insgesamt war klar, welche Tabellen bearbeitet werden mussten. Wir haben beschlossen, Partitionen f\u00fcr jede Woche zu erstellen, mit Ausnahme der letzten, basierend auf den Zahlen des Monats, also vier Partitionen pro Monat: vom 1. bis 7., vom 8. bis 14., vom 15. bis 21. und vom 22. bis zum 1. (des folgenden Monats). Die Herausforderung bestand darin, die ben\u00f6tigten Tabellen \u201eon-the-fly\u201c in partitionierte Tabellen umzuwandeln, ohne den Betrieb des Zabbix Servers und die Datensammlung zu unterbrechen.<\/p>\n

Seltsamerweise kam uns bei dieser Aufgabe die Struktur der Tabellendaten selbst zu Hilfe. Beispielsweise 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, wird jede Metrik schlie\u00dflich in eine Tabelle mit zwei sehr wichtigen und uns n\u00fctzlichen Feldern eingetragen: itemid<\/b> und clock<\/b>. So k\u00f6nnen wir ganz einfach eine tempor\u00e4re Tabelle erstellen, zum Beispiel mit dem Namen history_tmp<\/code>, f\u00fcr die wir dann die Partitionierung einrichten und alle Daten aus der Tabelle dorthin \u00fcbertragen history<\/code>, um anschlie\u00dfend die Tabelle umzubenennen history<\/code> in history_old<\/code>, w\u00e4hrend die Tabelle history_tmp<\/code> in history<\/code>, danach die noch fehlenden Daten aus history_old<\/code> in history <\/code>hinzuf\u00fcgen und history_old<\/code>. Dies kann v\u00f6llig sicher durchgef\u00fchrt werden, wir verlieren nichts, denn die oben genannten Felder itemid <\/b>und clock <\/b>stellen die Bindung einer bestimmten Metrik an einen bestimmten Zeitpunkt sicher, anstatt an eine einfache fortlaufende Nummer.<\/p>\n
Der \u00dcbergangsprozess selbst<\/h3>\n
<\/p>\n
Achtung! Es wird dringend empfohlen, vor Beginn irgendeiner Aktion eine vollst\u00e4ndige Sicherung der Datenbank zu erstellen. Wir sind schlie\u00dflich Menschen und k\u00f6nnen Fehler bei der Eingabe von Befehlen machen, was zu Datenverlust f\u00fchren kann. Ja, eine Sicherung garantiert nicht die maximale Aktualit\u00e4t, aber es ist besser, eine zu haben, als keine.<\/p><\/blockquote>\n
 Also schalten wir nichts aus und stoppen nichts. Wichtig ist, dass auf dem MySQL-Server ausreichend Speicherplatz vorhanden ist, d.h. dass f\u00fcr jede der oben genannten Tabellen history<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, dass mindestens ausreichend Platz zur Verf\u00fcgung steht, um eine Tabelle mit dem Suffix \u201e_tmp\u201c zu erstellen, wobei diese die gleiche Gr\u00f6\u00dfe wie die urspr\u00fcngliche Tabelle haben wird.<\/p>\n
Wir werden nicht alles mehrfach f\u00fcr jede der oben genannten Tabellen beschreiben und betrachten dies am Beispiel nur einer von ihnen \u2013 der Tabelle history<\/code>.<\/p>\n
Jetzt 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. Zum Beispiel machen wir dies nach Monaten. Jede Partition wird auf der Grundlage einer Partitionierungsregel erstellt, die auf dem Wert des Feldes basiert clock<\/b>, den wir mit einem 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 Befehl f\u00fcgt der von uns erstellten Tabelle die Partitionierung hinzu history_tmp<\/code>. Dabei stellen wir klar, dass Daten, bei denen der Wert des Feldes clock <\/b>weniger als \u201e2019-02-01 00:00:00\u201c ist, in die Partition p20190201<\/i>gehen, und die Daten, deren Wert des Feldes clock<\/b> gr\u00f6\u00dfer als \u201e2019-02-01 00:00:00\u201c aber kleiner als \u201e2019-02-07 00:00:00\u201c sind, in die Partition p20190207 <\/i>usw.<\/p>\n
Wichtiger Hinweis:<\/b> Was passiert, wenn in unserer partitionierten Tabelle Daten mit einem Zeitstempel gr\u00f6\u00dfer oder gleich \u00ab2019-03-01 00:00:00\u00bb erscheinen? Da es f\u00fcr diese Daten keine passende Partition gibt, werden sie nicht in die Tabelle aufgenommen und gehen verloren. Daher ist es wichtig, rechtzeitig weitere Partitionen zu erstellen, um solche Datenverluste zu vermeiden (siehe unten).<\/p><\/blockquote>\n
 So, die tempor\u00e4re Tabelle ist vorbereitet. Wir laden die Daten hoch. Der Prozess kann ziemlich lange dauern, aber gl\u00fccklicherweise blockiert er keine anderen Anfragen, sodass Sie einfach Geduld haben sollten:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nDas Schl\u00fcsselwort IGNORE ist beim ersten Laden nicht zwingend erforderlich, da die Tabelle ohnehin leer ist, jedoch wird es beim Nachladen der Daten von Nutzen sein. Zudem kann es hilfreich sein, falls Sie den Ladevorgang unterbrechen mussten und von vorne beginnen m\u00f6chten.<\/p>\n
So, nach einer gewissen Zeit (m\u00f6glicherweise sogar mehreren Stunden) ist der erste Datenimport abgeschlossen. Wie Sie sehen k\u00f6nnen, enth\u00e4lt die Tabelle history_tmp <\/code>nicht alle Daten aus der Tabelle history<\/code>, sondern nur die, die zu Beginn des Anforderungsvorgangs in ihr vorhanden waren. Hier haben Sie die Wahl: Entweder wir machen einen weiteren Durchgang (falls der Upload-Prozess lange gedauert hat), oder wir wechseln sofort zur Umbenennung der Tabellen, die weiter oben erw\u00e4hnt wurde. Lassen Sie uns zuerst \u00fcber den zweiten Durchgang sprechen. Zun\u00e4chst m\u00fcssen wir die Zeit des letzten eingef\u00fcgten Eintrags verstehen 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 des Daten-Uploads:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nDieser Durchgang sollte deutlich schneller abgeschlossen sein. Wenn der erste Durchgang jedoch Stunden gedauert hat und der zweite ebenfalls eine lange Zeit in Anspruch nimmt, k\u00f6nnte es sinnvoll sein, einen dritten Durchgang durchzuf\u00fchren, der genau wie der zweite funktioniert.<\/p>\n
Am Ende f\u00fchren wir erneut die Abfrage durch, um die Zeit des letzten eingef\u00fcgten Eintrags in history_tmp<\/code>, indem wir ausf\u00fchren:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nAngenommen, Sie haben erhalten 1551085645<\/b>. Speichern Sie diesen Wert \u2014 wir ben\u00f6tigen ihn f\u00fcr den Nachf\u00fcllprozess.<\/p>\n
Und nun, da der prim\u00e4re Daten-Upload 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 behandelt, um den Fall zu vermeiden, dass Daten in eine nicht vorhandene Tabelle eingef\u00fcgt werden, da die Tabelle nach dem ersten RENAME bis zur Ausf\u00fchrung des zweiten RENAME nicht existieren wird. history <\/code>Aber selbst wenn zwischen den RENAME-Operationen Daten in die Tabelle gelangen, die Tabelle jedoch noch nicht vorhanden ist (wegen der Umbenennung), erhalten wir einige Einf\u00fcgungsfehler, die vernachl\u00e4ssigbar sind (wir haben Monitoring, nicht Banking). history <\/code>Jetzt haben wir eine neue Tabelle<\/p>\n
mit Partitionierung, aber es fehlen Daten, die w\u00e4hrend des letzten Datenladevorgangs in die Tabelle erhalten wurden. history<\/code> Diese Daten haben wir jedoch in der Tabelle history_tmp<\/code>und wir werden sie jetzt dort erg\u00e4nzen. Dazu ben\u00f6tigen wir den zuvor gespeicherten Wert 1551085645. Warum haben wir diesen Wert gespeichert und nicht die maximale Ladezeit aus der aktuellen Tabelle verwendet? history_old <\/code>INSERT IGNORE INTO `history` SELECT * FROM history_old WHERE clock >= 1551045645; 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
Nach Abschluss dieser Operation haben wir in unserer neuen, partitionierten Tabelle<\/code><\/pre>\n
\nalle Daten, die in der alten enthalten waren, plus die, die bereits nach der Umbenennung der Tabelle angekommen sind. Die Tabelle history <\/code>enth\u00e4lt alle Daten, die in der alten Tabelle vorhanden waren, sowie die, die nach der Umbenennung der Tabelle bereits eingegangen sind. Tabelle history_old <\/code>Wir ben\u00f6tigen es nicht mehr. Sie k\u00f6nnen es sofort l\u00f6schen oder, falls Sie paranoid sind, vorher eine Sicherungskopie erstellen.<\/p>\n
Der gesamte oben beschriebene Prozess muss f\u00fcr die Tabellen wiederholt werden. history_str<\/code>, history_text <\/code>und history_uint<\/code>.<\/p>\n
Was muss in den Einstellungen des Zabbix Servers angepasst werden?<\/h3>\n
\nNun liegt die Wartung der Datenbank in Bezug auf die Verlaufsdaten in unseren H\u00e4nden. Das bedeutet, dass Zabbix keine alten Daten mehr l\u00f6schen muss \u2013 wir k\u00fcmmern uns selbst darum. Damit Zabbix Server nicht versucht, die Daten selbst zu bereinigen, gehen Sie bitte in die Weboberfl\u00e4che von Zabbix, w\u00e4hlen Sie im Men\u00fc \"Administration\" das Untermen\u00fc \"Allgemein\" und w\u00e4hlen Sie im Dropdown-Men\u00fc auf der rechten Seite \"Historienbereinigung\". Auf der nun erscheinenden Seite m\u00fcssen Sie alle H\u00e4kchen in der Gruppe \"Historie\" entfernen und auf die Schaltfl\u00e4che \"Aktualisieren\" klicken. Dies verhindert die unerw\u00fcnschte Bereinigung der Tabellen. history*<\/code> \u00fcber den Housekeeper.<\/p>\n
Beachten Sie auf dieser Seite auch die Gruppe \"\u00c4nderungsdynamik\". Dies ist genau die Tabelle, trends<\/code>, zu der wir versprochen haben zur\u00fcckzukehren. Wenn sie auch bei Ihnen zu gro\u00df geworden ist und partitioniert werden muss, entfernen Sie die H\u00e4kchen auch in dieser Gruppe und bearbeiten Sie diese Tabelle genau so wie bei den anderen Tabellen. history*<\/code>.<\/p>\n
Weitere Datenbankpflege<\/h3>\n
\nWie bereits erw\u00e4hnt, ist es f\u00fcr die ordnungsgem\u00e4\u00dfe Funktion von partitionierten Tabellen erforderlich, rechtzeitig Partitionen zu erstellen. Dies kann folgenderma\u00dfen erfolgen:<\/p>\n
ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\nDa wir partitionierte Tabellen erstellt und Zabbix Server verboten haben, sie zu bereinigen, liegt die Verantwortung f\u00fcr das L\u00f6schen alter Daten nun bei uns. Zum Gl\u00fcck gibt es dabei \u00fcberhaupt keine Probleme. Dies geschieht einfach durch das L\u00f6schen der Partition, deren Daten wir nicht mehr ben\u00f6tigen. <\/p>\n
Zum Beispiel:<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nIm Gegensatz zu DELETE FROM-Befehlen mit Datumsbereichen wird DROP PARTITION innerhalb von Sekunden ausgef\u00fchrt und belastet das System nicht. der Server<\/a> Es funktioniert ebenso problemlos bei der Verwendung von MySQL-Replikationen.<\/p>\n
Fazit<\/h3>\n
\nDie beschriebene L\u00f6sung hat sich bew\u00e4hrt. Der Datenumfang w\u00e4chst, jedoch ist keine sp\u00fcrbare Leistungseinbu\u00dfe festzustellen.
\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\udd47 Die Verwendung von Partitionierung in MySQL f\u00fcr Zabbix mit einer gro\u00dfen Anzahl von Monitoring-Objekten | ProHoster","description":"Seit langem setzen wir zur \u00dcberwachung von Servern und Diensten erfolgreich auf eine Kombination aus Nagios und Munin. Allerdings bringt diese Kombination einige Nachteile mit sich, weshalb wir, wie viele andere auch, aktiv Zabbix nutzen. In diesem Artikel zeigen wir, wie Sie mit minimalem Aufwand die Leistungsproblematik bei einer steigenden Anzahl \u00fcberwachteter Metriken l\u00f6sen k\u00f6nnen.","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. \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","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"},"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}]}}