{"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\/pl\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","title":{"rendered":"Zastosowanie partycjonowania w MySQL dla Zabbix z du\u017c\u0105 liczb\u0105 obiekt\u00f3w monitorowania","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Od dawna u\u017cywamy po\u0142\u0105czenia Nagios i Munin do monitorowania serwer\u00f3w i us\u0142ug, i nadal odnosi ono sukcesy. Jednak to rozwi\u0105zanie ma pewne wady, dlatego my, podobnie jak wielu innych, aktywnie wykorzystujemy Zabbix<\/a><\/noindex>. W tym artykule opowiemy, jak przy minimalnym wysi\u0142ku rozwi\u0105za\u0107 problem wydajno\u015bci przy rosn\u0105cej liczbie pobieranych metryk i wzro\u015bcie baz danych MySQL.
\n<\/a><\/noindex><\/p>\n

Problemy z u\u017cywaniem bazy danych MySQL razem z Zabbixem<\/h3>\n

\nDop\u00f3ki baza danych by\u0142a ma\u0142a, a liczba przechowywanych w niej metryk niewielka, wszystko by\u0142o idealne. Proces housekeeper, kt\u00f3ry uruchamia sam serwer Zabbixa, skutecznie usuwa\u0142 przestarza\u0142e rekordy z bazy danych, nie pozwalaj\u0105c jej rosn\u0105\u0107. Jednak gdy liczba pobieranych metryk wzros\u0142a, a obj\u0119to\u015b\u0107 bazy danych osi\u0105gn\u0119\u0142a pewien rozmiar, sytuacja zacz\u0119\u0142a si\u0119 pogarsza\u0107. Housekeeper przesta\u0142 nad\u0105\u017ca\u0107 z usuwaniem danych w przydzielonym czasie, w bazie danych zacz\u0119\u0142y gromadzi\u0107 si\u0119 stare dane. Podczas pracy housekeepera wyst\u0119powa\u0142o zwi\u0119kszone obci\u0105\u017cenie serwera Zabbixa, kt\u00f3re mog\u0142o trwa\u0107 d\u0142ugo. Zrozumieli\u015bmy, \u017ce musimy jako\u015b rozwi\u0105za\u0107 t\u0119 sytuacj\u0119.<\/p>\n

To znany problem, prawie ka\u017cdy, kto pracowa\u0142 z du\u017cymi ilo\u015bciami monitoringu w Zabbixie, napotka\u0142 ten sam problem. By\u0142o kilka rozwi\u0105za\u0144: na przyk\u0142ad wymiana MySQL na PostgreSQL lub nawet Elasticsearch, ale najprostszym i wypr\u00f3bowanym rozwi\u0105zaniem by\u0142o przej\u015bcie na partycjonowanie tabel, kt\u00f3re przechowuj\u0105 dane metryk w bazie danych MySQL. Postanowili\u015bmy wybra\u0107 t\u0119 drog\u0119.<\/p>\n

Przej\u015bcie od zwyk\u0142ych tabel MySQL do tabel partycjonowanych<\/h3>\n

\nZabbix jest dobrze udokumentowany, a tabele, w kt\u00f3rych przechowuje metryki, s\u0105 znane. To s\u0105 tabele: historia<\/code>, w kt\u00f3rych przechowywane s\u0105 warto\u015bci float, history_str<\/code>, w kt\u00f3rych przechowywane s\u0105 kr\u00f3tkie warto\u015bci tekstowe, history_text<\/code>, w kt\u00f3rych przechowywane s\u0105 d\u0142ugie warto\u015bci tekstowe i history_uint<\/code>, w kt\u00f3rych przechowywane s\u0105 warto\u015bci ca\u0142kowite. Jest te\u017c tabela trends<\/code>, kt\u00f3ra przechowuje dynamik\u0119 zmian, ale postanowili\u015bmy jej nie rusza\u0107, poniewa\u017c jej rozmiar jest niewielki i wr\u00f3cimy do niej nieco p\u00f3\u017aniej.<\/p>\n

Og\u00f3lnie wiadomo, kt\u00f3re tabele nale\u017ca\u0142o przetworzy\u0107. Postanowili\u015bmy tworzy\u0107 partycje co tydzie\u0144, z wyj\u0105tkiem ostatniego, na podstawie liczb miesi\u0105ca, tzn. w czterech partycjach na miesi\u0105c: od 1 do 7, od 8 do 14, od 15 do 21 oraz od 22 do 1 (nast\u0119pnego miesi\u0105ca). Problematyczne by\u0142o to, \u017ce musieli\u015bmy przekszta\u0142ci\u0107 odpowiednie tabele w partycjonowane \u201ew locie\u201d, nie przerywaj\u0105c pracy Zabbix Server ani zbierania metryk.<\/p>\n

Jak dziwnie by to nie brzmia\u0142o, w tej sprawie pomog\u0142a nam sama struktura danych tabel. Na przyk\u0142ad tabela historia <\/code>ma nast\u0119puj\u0105c\u0105 struktur\u0119:<\/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
\nprzy czym<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nJak widzimy, ka\u017cda metryka ostatecznie trafia do tabeli z dwoma bardzo wa\u017cnymi i wygodnymi dla nas polami itemid<\/b> i clock<\/b>. W ten spos\u00f3b mo\u017cemy stworzy\u0107 tymczasow\u0105 tabel\u0119, na przyk\u0142ad o nazwie history_tmp<\/code>, skonfigurowa\u0107 dla niej partycjonowanie, a nast\u0119pnie przela\u0107 do niej wszystkie dane z tabeli historia<\/code>, a potem zmieni\u0107 nazw\u0119 tabeli historia<\/code> do history_old<\/code>, a tabel\u0119 history_tmp<\/code> do historia<\/code>, po czym doda\u0107 te dane, kt\u00f3re nie zosta\u0142y jeszcze dodane z history_old<\/code> do historia <\/code>i usun\u0105\u0107 history_old<\/code>. Mo\u017cna to zrobi\u0107 ca\u0142kowicie bezpiecznie, niczego nie stracimy, poniewa\u017c wspomniane powy\u017cej pola itemid <\/b>i clock <\/b>zapewniaj\u0105 powi\u0105zanie konkretnej metryki z konkretnym czasem, a nie z jakim\u015b numerem porz\u0105dkowym.<\/p>\n
Sama procedura przej\u015bcia<\/h3>\n
<\/p>\n
Uwaga! Zdecydowanie zaleca si\u0119, przed rozpocz\u0119ciem jakichkolwiek dzia\u0142a\u0144, wykonanie pe\u0142nej kopii zapasowej bazy danych. Jeste\u015bmy wszystkimi lud\u017ami i mo\u017cemy pope\u0142ni\u0107 b\u0142\u0105d w zestawie polece\u0144, co mo\u017ce prowadzi\u0107 do utraty danych. Tak, kopia zapasowa nie zapewni maksymalnej aktualno\u015bci, ale lepiej mie\u0107 tak\u0105, ni\u017c \u017cadn\u0105.<\/p><\/blockquote>\n
 Ot\u00f3\u017c niczego nie wy\u0142\u0105czamy ani nie zatrzymujemy. Najwa\u017cniejsze, aby na samym serwerze MySQL by\u0142o wystarczaj\u0105co du\u017co wolnego miejsca na dysku, tzn. \u017ceby na ka\u017cd\u0105 z wymienionych powy\u017cej tabel historia<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, przynajmniej by\u0142o wystarczaj\u0105co miejsca na utworzenie tabeli z sufiksem \u201e_tmp\u201d, maj\u0105c na uwadze, \u017ce b\u0119dzie ona mia\u0142a tak\u0105 sam\u0105 obj\u0119to\u015b\u0107 jak tabela \u017ar\u00f3d\u0142owa.<\/p>\n
Nie b\u0119dziemy opisywa\u0107 wszystkiego kilka razy dla ka\u017cdej z wymienionych tabel i rozwa\u017cymy wszystko na przyk\u0142adzie tylko jednej z nich \u2014 tabeli historia<\/code>.<\/p>\n
Zatem tworzymy pust\u0105 tabel\u0119 history_tmp <\/code>na podstawie struktury tabeli historia<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nTworzymy potrzebne nam partycje. Na przyk\u0142ad, zrobimy to na miesi\u0105c. Ka\u017cda partycja jest tworzona na podstawie regu\u0142y partycjonowania, opartej na warto\u015bci pola clock<\/b>, kt\u00f3re por\u00f3wnujemy z znakiem czasu:<\/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
\nTen operator dodaje partycjonowanie do utworzonej przez nas tabeli history_tmp<\/code>. U\u015bci\u015blijmy, \u017ce dane, kt\u00f3rych warto\u015b\u0107 pola clock <\/b>jest mniejsza ni\u017c \u201e2019-02-01 00:00:00\u201d trafi\u0105 do partycji p20190201<\/i>, nast\u0119pnie dane, kt\u00f3rych warto\u015b\u0107 pola clock<\/b> jest wi\u0119ksza ni\u017c \u201e2019-02-01 00:00:00\u201d ale mniejsza ni\u017c \u201e2019-02-07 00:00:00\u201d trafi\u0105 do partycji p20190207 <\/i>i tym podobne.<\/p>\n
Wa\u017cna uwaga:<\/b> Co si\u0119 stanie, je\u015bli w naszej partycjonowanej tabeli pojawi\u0105 si\u0119 dane, kt\u00f3rych warto\u015b\u0107 pola clock b\u0119dzie wi\u0119ksza lub r\u00f3wna \u201e2019-03-01 00:00:00\u201d? Poniewa\u017c dla tych danych nie ma odpowiedniej partycji, nie trafi\u0105 one do tabeli i zostan\u0105 utracone. Dlatego musisz pami\u0119ta\u0107 o regularnym tworzeniu dodatkowych partycji, aby unikn\u0105\u0107 takich utrat danych (o czym poni\u017cej).<\/p><\/blockquote>\n
 A zatem, tymczasowa tabela jest przygotowana. Wprowadzamy dane. Proces mo\u017ce zaj\u0105\u0107 do\u015b\u0107 d\u0142ugi czas, ale na szcz\u0119\u015bcie nie blokuje \u017cadnych innych zapyta\u0144, wi\u0119c trzeba po prostu uzbroi\u0107 si\u0119 w cierpliwo\u015b\u0107:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nS\u0142owo kluczowe IGNORE przy pocz\u0105tkowym wprowadzaniu nie jest obowi\u0105zkowe, poniewa\u017c w tabeli i tak nie ma danych, jednak przyda si\u0119 przy ponownym wprowadzaniu danych. Ponadto mo\u017ce by\u0107 przydatne, je\u015bli podczas wprowadzania danych musia\u0142e\u015b przerwa\u0107 ten proces i zacz\u0105\u0107 od nowa.<\/p>\n
Po pewnym czasie (mo\u017ce nawet kilku godzinach), pierwsze wprowadzenie danych zosta\u0142o zako\u0144czone. Jak rozumiesz, teraz tabela history_tmp <\/code>zawiera nie wszystkie dane z tabeli historia<\/code>, a tylko te, kt\u00f3re by\u0142y w niej w momencie rozpocz\u0119cia wykonywania zapytania. Tutaj masz wyb\u00f3r: albo wykonujemy kolejny przebieg (je\u015bli proces wprowadzania trwa\u0142 d\u0142ugo), albo od razu przechodzimy do zmiany nazw tabel, o kt\u00f3rych wspomniano wcze\u015bniej. Zacznijmy od drugiego przebiegu. Na pocz\u0105tek musimy zrozumie\u0107 czas ostatnio wstawionego wpisu w history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nZa\u0142\u00f3\u017cmy, \u017ce otrzyma\u0142e\u015b: 1551045645<\/b>Teraz wykorzystujemy uzyskan\u0105 warto\u015b\u0107 w drugim przebiegu \u0142adowania danych:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nTen przebieg powinien zako\u0144czy\u0107 si\u0119 znacznie szybciej. Ale je\u015bli pierwszy przebieg trwa\u0142 godziny, a drugi r\u00f3wnie\u017c trwa\u0142 d\u0142ugo, mo\u017ce by\u0107 s\u0142uszne wykonanie trzeciego przebiegu, kt\u00f3ry b\u0119dzie przebiega\u0142 podobnie do drugiego.<\/p>\n
Na koniec ponownie wykonujemy operacj\u0119 uzyskania czasu ostatniego wstawienia rekordu w history_tmp<\/code>, wykonuj\u0105c:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nZa\u0142\u00f3\u017cmy, \u017ce otrzymali\u015bcie 1551085645<\/b>. Zachowaj t\u0119 warto\u015b\u0107 \u2014 b\u0119dzie nam potrzebna do do\u0142adowania.<\/p>\n
A teraz, gdy pocz\u0105tkowe \u0142adowanie danych w history_tmp <\/code>zako\u0144czy\u0142o si\u0119, przyst\u0119pujemy do zmiany nazw tabel:<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nZorganizowali\u015bmy ten blok jako jedn\u0105 transakcj\u0119, aby unikn\u0105\u0107 momentu wstawienia danych do nieistniej\u0105cej tabeli, poniewa\u017c po pierwszym RENAME do momentu wykonania drugiego RENAME tabela historia <\/code>nie b\u0119dzie istnia\u0142a. Ale nawet je\u015bli mi\u0119dzy operacjami RENAME do tabeli historia <\/code>przejd\u0105 jakie\u015b dane, a sama tabela jeszcze nie b\u0119dzie (z powodu zmiany nazwy), otrzymamy niewielk\u0105 liczb\u0119 b\u0142\u0119d\u00f3w wstawiania, kt\u00f3re mo\u017cna zignorowa\u0107 (mamy monitoring, a nie bank).<\/p>\n
Teraz mamy now\u0105 tabel\u0119 historia<\/code> z partycjonowaniem, ale brakuje w niej danych, kt\u00f3re zosta\u0142y uzyskane podczas ostatniego przebiegu wstawiania danych do tabeli history_tmp<\/code>. Ale te dane mamy w tabeli history_old <\/code>i teraz je tam dolejemy. W tym celu potrzebujemy wcze\u015bniej zapisanej warto\u015bci 1551085645. Dlaczego zapisali\u015bmy t\u0119 warto\u015b\u0107, a nie u\u017cyli\u015bmy maksymalnego czasu wstawienia ju\u017c z bie\u017c\u0105cej tabeli historia<\/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
\nPo zako\u0144czeniu tej operacji w naszej nowej, partycjonowanej tabeli historia <\/code>s\u0105 wszystkie dane, kt\u00f3re by\u0142y w starej, plus te, kt\u00f3re ju\u017c przysz\u0142y po zmianie nazwy tabeli. Tabela history_old <\/code>nie jest ju\u017c nam potrzebna. Mo\u017cna j\u0105 od razu usun\u0105\u0107, a mo\u017cna przed usuni\u0119ciem zrobi\u0107 jej kopi\u0119 zapasow\u0105 (je\u015bli masz paranoj\u0119).<\/p>\n
Ca\u0142y opisany powy\u017cej proces nale\u017cy powt\u00f3rzy\u0107 dla tabel history_str<\/code>, history_text <\/code>i history_uint<\/code>.<\/p>\n
Co nale\u017cy poprawi\u0107 w ustawieniach Zabbix Server<\/h3>\n
\nTeraz zarz\u0105dzanie baz\u0105 danych w zakresie historii danych spoczywa na naszych barkach. Oznacza to, \u017ce Zabbix nie musi ju\u017c usuwa\u0107 starych danych \u2014 zajmiemy si\u0119 tym sami. Aby Zabbix Server nie pr\u00f3bowa\u0142 samoczynnie oczyszcza\u0107 danych, nale\u017cy wej\u015b\u0107 w interfejs webowy Zabbix, wybra\u0107 w menu \u201eAdministracja\u201d, nast\u0119pnie podmenu \u201eOg\u00f3lne\u201d, a w rozwijanym menu po prawej stronie wybra\u0107 \u201eOczyszczanie historii\u201d. Na pojawiaj\u0105cej si\u0119 stronie nale\u017cy odznaczy\u0107 wszystkie opcje dla grupy \u201eHistoria\u201d i nacisn\u0105\u0107 przycisk \u201eAktualizuj\u201d. To zapobiegnie zb\u0119dnemu oczyszczaniu tabel. historia*<\/code> przez housekeeper.<\/p>\n
Zwr\u00f3\u0107 uwag\u0119 na tej samej stronie na grup\u0119 \u201eDynamika zmian\u201d. To w\u0142a\u015bnie tabela trends<\/code>, do kt\u00f3rej obiecali\u015bmy wr\u00f3ci\u0107. Je\u015bli r\u00f3wnie\u017c sta\u0142a si\u0119 zbyt du\u017ca i wymaga partycjonowania, odznacz opcje w tej grupie, a nast\u0119pnie przetw\u00f3rz t\u0119 tabel\u0119 dok\u0142adnie tak jak zrobiono dla tabel historia*<\/code>.<\/p>\n
Dalsze zarz\u0105dzanie baz\u0105 danych<\/h3>\n
\nJak wcze\u015bniej wspomniano, dla prawid\u0142owego dzia\u0142ania z partycjonowanymi tabelami, nale\u017cy na czas tworzy\u0107 partycje. Mo\u017cna to zrobi\u0107 w nast\u0119puj\u0105cy spos\u00f3b:<\/p>\n
ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\nPonadto, poniewa\u017c stworzyli\u015bmy partycjonowane tabele i zabronili\u015bmy Zabbix Serverowi ich oczyszcza\u0107, usuni\u0119cie starych danych r\u00f3wnie\u017c spoczywa na nas. Na szcz\u0119\u015bcie nie ma z tym \u017cadnych problem\u00f3w. Robi si\u0119 to po prostu usuwaj\u0105c t\u0119 partycj\u0119, kt\u00f3rej dane sta\u0142y si\u0119 niepotrzebne. <\/p>\n
Na przyk\u0142ad:<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nW przeciwie\u0144stwie do operator\u00f3w DELETE FROM z okre\u015blonym zakresem dat, DROP PARTITION wykonuje si\u0119 w kilka sekund, ca\u0142kowicie nie obci\u0105\u017caj\u0105c serwer<\/a> i r\u00f3wnie bezproblemowo dzia\u0142a w przypadku wykorzystania replikacji MySQL.<\/p>\n
Podsumowanie<\/h3>\n
\nOpisane rozwi\u0105zanie zosta\u0142o zweryfikowane przez czas. Ilo\u015b\u0107 danych ro\u015bnie, ale nie odnotowano znacz\u0105cego spowolnienia wydajno\u015bci.
\n
\u0179r\u00f3d\u0142o: 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\udd47U\u017cycie partycjonowania w MySQL dla Zabbix z du\u017c\u0105 liczb\u0105 obiekt\u00f3w monitorowania | ProHoster","description":"Od dawna z powodzeniem u\u017cywamy po\u0142\u0105czonego rozwi\u0105zania opartego na Nagios i Munin do monitorowania serwer\u00f3w i us\u0142ug.","canonical_url":"https:\/\/prohoster.info\/pl\/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":"pl_PL","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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/53966","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=53966"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/53966\/revisions"}],"predecessor-version":[{"id":172868,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/53966\/revisions\/172868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=53966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=53966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=53966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}