{"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\/hr\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","title":{"rendered":"Kori\u0161tenje particioniranja u MySQL za Zabbix s velikim brojem objekata za nadzor","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Za pra\u0107enje servera i usluga ve\u0107 dugo koristimo kombinirano rje\u0161enje bazirano na Nagiosu i Muninu, i to s uspjehom. No, ova kombinacija ima odre\u0111ene nedostatke, stoga mi, poput mnogih, aktivno koristimo Zabbix,<\/a><\/noindex>. U ovom \u010dlanku \u0107emo objasniti kako minimalnim naporima mo\u017eete rije\u0161iti problem s performansama prilikom pove\u0107anja broja prikupljenih metrike i rasta volumena MySQL baze podataka.
\n<\/a><\/noindex><\/p>\n

Problemi kori\u0161tenja MySQL baze podataka zajedno sa Zabbixom<\/h3>\n

\nDok je baza podataka bila mala i broj metrika koje su se pohranjivale bio je mali, sve je bilo savr\u0161eno. Standardni proces housekeeper, koji pokre\u0107e sam Zabbix Server, uspje\u0161no je brisao zastarjele zapise iz baze podataka, sprje\u010davaju\u0107i njezin rast. Me\u0111utim, \u010dim je broj prikupljenih metrika porastao i volumen baze podataka dosegla odre\u0111enu veli\u010dinu, situacija se pogor\u0161ala. Housekeeper vi\u0161e nije stizao brisati podatke unutar zadanog vremenskog intervala, a u bazi podataka su ostajali stari podaci. Tijekom rada housekeepera dolazilo je do pove\u0107anog optere\u0107enja na Zabbix Serveru, koje je moglo trajati dugo vremena. Postalo je jasno da se situacija mora rije\u0161iti.<\/p>\n

Ovo je poznat problem, gotovo svaki tko je radio s velikim volumenima monitoringa na Zabbixu susreo se s istim. Rje\u0161enja su tako\u0111er bila nekoliko: na primjer, zamjena MySQL-a s PostgreSQL-om ili \u010dak Elasticsearch-om, no najjednostavnije i ve\u0107 isprobano rje\u0161enje bilo je prebacivanje na particioniranje tablica koje pohranjuju podatke metrika u MySQL bazi podataka. Odlu\u010dili smo i\u0107i upravo tim putem.<\/p>\n

Prijelaz s obi\u010dnih MySQL tablica na particionirane<\/h3>\n

\nZabbix je dobro dokumentiran i tablice u kojima pohranjuje metrike su poznate. To su tablice: history<\/code>, gdje se pohranjuju float vrijednosti, history_str<\/code>, gdje se pohranjuju kratke string vrijednosti, history_text<\/code>, gdje se pohranjuju duga\u010dki tekstualni podaci i history_uint<\/code>, gdje se pohranjuju cijele broj\u010dane vrijednosti. Tu je jo\u0161 i tablica trends<\/code>, koja pohranjuje dinamiku promjena, no odlu\u010dili smo da je ne diramo jer je njezina veli\u010dina mala, a malo kasnije \u0107emo se opet vratiti na nju.<\/p>\n

U osnovi, bilo je jasno koje tablice treba obraditi. Odlu\u010dili smo napraviti particije za svaki tjedan, osim za posljednji, na temelju brojeva u mjesecu, tj. \u010detiri particije po mjesecu: od 1. do 7., od 8. do 14., od 15. do 21. i od 22. do 1. (sljede\u0107eg mjeseca). Te\u0161ko\u0107a je bila u tome \u0161to smo morali potrebne tablice pretvoriti u particionirane 'u hodu', ne prekidaju\u0107i rad Zabbix poslu\u017eitelja i prikupljanje metrike.<\/p>\n

Kako god \u010dudno zvu\u010dalo, u tome nam je pomogla sama struktura podataka tablica. Na primjer, tablica history <\/code>ima sljede\u0107u strukturu:<\/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
\npri tome<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nKao \u0161to vidimo, svaka metrike na kraju se unosi u tablicu s dva vrlo va\u017ena i korisna polja itemid<\/b> i clock<\/b>. Na taj na\u010din, mo\u017eemo stvoriti privremenu tablicu, na primjer, imenom history_tmp<\/code>, postaviti za nju particioniranje i zatim prenijeti sve podatke iz tablice history<\/code>, a zatim preimenovati tablicu history<\/code> u history_old<\/code>, a tablicu history_tmp<\/code> u history<\/code>, nakon \u010dega \u0107emo dodati one podatke koje nismo prenijeli iz history_old<\/code> u history <\/code>i ukloniti history_old<\/code>. To se mo\u017ee raditi potpuno sigurno, ne\u0107emo ni\u0161ta izgubiti, jer navedena polja itemid <\/b>i clock <\/b>osiguravaju vezanje konkretne metrike za odre\u0111eno vrijeme, a ne za neki redoslijedni broj.<\/p>\n
Postupak prijelaza<\/h3>\n
<\/p>\n
Pa\u017enja! Vrlo je po\u017eeljno, prije po\u010detka bilo kakvih radnji, napraviti potpunu sigurnosnu kopiju iz baze podataka. Svi smo mi \u017eivi ljudi i mo\u017eemo napraviti gre\u0161ku u unosu komandnog niza, \u0161to mo\u017ee dovesti do gubitka podataka. Da, sigurnosna kopija ne\u0107e osigurati maksimalnu a\u017eurnost, ali bolje imati takvu nego nikakvu.<\/p><\/blockquote>\n
 Dakle, ni\u0161ta ne isklju\u010dujemo i ne zaustavljamo. Va\u017eno je da na samom MySQL poslu\u017eitelju postoji dovoljno slobodnog mjesta na disku, tj. da za svaku od gore navedenih tablica history<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, minimalno, bude dovoljno mjesta za stvaranje tablice s sufiksom '_tmp', imaju\u0107i na umu da \u0107e imati istu zapreminu kao i izvornja tablica.<\/p>\n
Ne\u0107emo opisivati sve nekoliko puta za svaku od gore navedenih tablica i razmotrit \u0107emo sve na primjeru samo jedne od njih \u2014 tablice history<\/code>.<\/p>\n
Dakle, stvaramo praznu tablicu history_tmp <\/code>na temelju strukture tablice history<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nStvaramo potrebne particije. Kao primjer, u\u010dinit \u0107emo to na mjesec. Svaka particija se stvara na osnovu pravila particioniranja temeljenog na vrijednosti polja clock<\/b>, koje uspore\u0111ujemo s vremenskom oznakom:<\/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
\nOva naredba dodaje particioniranje za na\u0161u stvorenu tablicu history_tmp<\/code>. Da pojasnimo, podaci \u010dija vrijednost polja clock <\/b>manja je od '2019-02-01 00:00:00' do\u0107i \u0107e u particiju p20190201<\/i>, zatim podaci \u010dija vrijednost polja clock<\/b> ve\u0107a je od '2019-02-01 00:00:00' ali manja od '2019-02-07 00:00:00' do\u0107i \u0107e u particiju p20190207 <\/i>i tako dalje.<\/p>\n
Va\u017ena napomena:<\/b> \u0160to \u0107e se dogoditi ako u na\u0161oj particioniranoj tablici budu podaci \u010dija vrijednost polja clock bude ve\u0107a ili jednaka '2019-03-01 00:00:00'? Budu\u0107i da za te podatke ne postoji odgovaraju\u0107a particija, oni ne\u0107e biti pohranjeni u tablicu i bit \u0107e izgubljeni. Stoga, morate se sjetiti pravovremeno stvarati dodatne particije kako biste izbjegli gubitak podataka (o \u010demu govori dalje).<\/p><\/blockquote>\n
 Dakle, privremena tablica je pripremljena. U\u010ditavamo podatke. Proces mo\u017ee trajati prili\u010dno dugo, ali sre\u0107om ne blokira druge upite, tako da samo trebate imati strpljenja:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nKlju\u010dna rije\u010d IGNORE prilikom inicijalnog u\u010ditavanja nije obavezna, budu\u0107i da u tablici ionako nema podataka, no bit \u0107e vam potrebna prilikom dodatnog u\u010ditavanja podataka. Osim toga, mo\u017ee biti korisna ako ste morali prekinuti ovaj proces i zapo\u010deti ispo\u010detka.<\/p>\n
Dakle, nakon nekog vremena (mo\u017eda \u010dak nekoliko sati), prvo u\u010ditavanje podataka je pro\u0161lo. Kao \u0161to razumijete, sada tablica history_tmp <\/code>sadr\u017ei ne sve podatke iz tablice history<\/code>, ve\u0107 samo one koji su bili u njoj u trenutku kada je zapo\u010deto izvr\u0161enje upita. Ovdje zapravo imate izbor: ili napravimo jo\u0161 jedan prolaz (ako je proces u\u010ditavanja trajao dugo), ili odmah prelazimo na preimenovanje tablica, o \u010demu je bilo rije\u010di ranije. Prvo razgovarajmo o drugom prolazu. Za po\u010detak trebamo saznati vrijeme posljednje unesene stavke u history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nPretpostavimo da ste dobili: 1551045645<\/b>. Sada koristimo dobivenu vrijednost u drugom prolazu uno\u0161enja podataka:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nOvaj prolaz trebao bi zavr\u0161iti znatno br\u017ee. No, ako je prvi prolaz trajao satima, a drugi tako\u0111er dugo, mo\u017eda bi bilo ispravno napraviti i tre\u0107i prolaz, koji se izvr\u0161ava potpuno analogno drugome.<\/p>\n
Na kraju ponovno izvr\u0161avamo operaciju dobivanja vremena posljednjeg umetanja zapisa u history_tmp<\/code>, izvr\u0161iv\u0161i:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nPretpostavimo da ste dobili 1551085645<\/b>. Spremite ovu vrijednost \u2014 trebat \u0107e nam za dodatno uno\u0161enje.<\/p>\n
A sada zapravo, kada je primarno uno\u0161enje podataka u history_tmp <\/code>zavr\u0161eno, prelazimo na preimenovanje tablica:<\/p>\n
PO\u010cNI;\nPREIMENUJ TABLICU history TO history_old;\nPREIMENUJ TABLICU history_tmp TO history;\nKRAJ;<\/code><\/pre>\n
\nOvaj blok smo oblikovali kao jednu transakciju kako bismo izbjegli trenutak umetanja podataka u nepostoje\u0107u tablicu, jer nakon prvog PREIMENUJ do trenutka izvr\u0161enja drugog PREIMENUJ, tablica history <\/code>ne\u0107e postojati. Ali \u010dak i ako tijekom operacija PREIMENUJ u tablicu history <\/code>do\u0111u neki podaci, a same tablice jo\u0161 ne\u0107e biti (zbog preimenovanja), dobit \u0107emo malo pogre\u0161aka umetanja na koje se mo\u017ee zanemariti (mi imamo nadzor, a ne banku).<\/p>\n
Sada imamo novu tablicu history<\/code> s particioniranjem, ali nedostaju joj podaci koji su dobiveni tijekom posljednjeg prolaza umetanja podataka u tablicu history_tmp<\/code>. No, te podatke imamo u tablici history_old <\/code>i sada \u0107emo ih dodati odatle. Za to nam je potrebna ranije spremljena vrijednost 1551085645. Za\u0161to smo spremili tu vrijednost, a ne koristili maksimalno vrijeme umetanja ve\u0107 iz trenutne tablice 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
\nNakon zavr\u0161etka ove operacije, imamo u novoj, particioniranoj tablici history <\/code>sve podatke koji su bili u staroj, plus one koji su ve\u0107 do\u0161li nakon preimenovanja tablice. Tablica history_old <\/code>vi\u0161e nam nije potrebna. Mo\u017eemo je odmah obrisati, ili mo\u017eemo napraviti sigurnosnu kopiju prije brisanja (ako ste pomalo paranoidni).<\/p>\n
Cijeli gore opisan proces potrebno je ponoviti za tablice history_str<\/code>, history_text <\/code>i history_uint<\/code>.<\/p>\n
\u0160to treba ispraviti u postavkama Zabbix Server<\/h3>\n
\nSada je odr\u017eavanje baze podataka u vezi s povije\u0161\u0107u podataka preba\u010deno na nas. To zna\u010di da Zabbix vi\u0161e ne bi trebao brisati stare podatke \u2014 time \u0107emo se baviti sami. Da Zabbix Server ne poku\u0161a sam o\u010distiti podatke, morate u\u0107i u web su\u010delje Zabbixa, odabrati u izborniku 'Administracija', zatim podizbornik 'Op\u0107e', a zatim u desnom padaju\u0107em izborniku odabrati '\u010ci\u0161\u0107enje povijesti'. Na pojavnoj stranici potrebno je ukloniti sve oznake za grupu 'Povijest' i pritisnuti gumb 'A\u017eurirati'. Ovo \u0107e sprije\u010diti nepotrebno \u010di\u0161\u0107enje tablica. povijest*<\/code> putem housekeepera.<\/p>\n
Obratite pa\u017enju na istoj stranici na grupu 'Dinamika promjena'. Ovo je upravo tablica trends<\/code>, kojoj smo se obavezali vratiti. Ako je i ona postala prevelika i treba joj particioniranje, uklonite oznake i u ovoj grupi, a zatim obradite tu tablicu na sli\u010dan na\u010din kao \u0161to se radilo za tablice povijest*<\/code>.<\/p>\n
Daljnje odr\u017eavanje baze podataka<\/h3>\n
\nKao \u0161to je ranije napisano, za normalan rad na particioniranim tablicama, potrebno je pravovremeno kreirati particije. To se mo\u017ee napraviti ovako:<\/p>\n
ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\nOsim toga, budu\u0107i da smo stvorili particionirane tablice i zabranili Zabbix Serveru da ih \u010disti, uklanjanje starih podataka sada je na\u0161a briga. Sre\u0107om, ovdje nema nikakvih problema. To se jednostavno radi brisanjem one particije \u010diji nam podaci vi\u0161e nisu potrebni. <\/p>\n
Na primjer:<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nZa razliku od naredbi DELETE FROM s navedenim rasponom datuma, DROP PARTITION se izvr\u0161ava za nekoliko sekundi, potpuno ne optere\u0107uje server<\/a> i radi jednako besprijekorno u slu\u010daju kori\u0161tenja MySQL replikacije.<\/p>\n
Zaklju\u010dak<\/h3>\n
\nOpisano rje\u0161enje testirano je vremenom. Obim podataka raste, ali nije zabilje\u017eeno nikakvo zna\u010dajno usporavanje performansi.
\n
Izvor: 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\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\udd47Kori\u0161tenje particioniranja u MySQL za Zabbix s velikim brojem objekata pra\u0107enja | ProHoster","description":"Za pra\u0107enje poslu\u017eitelja i usluga ve\u0107 dugo, i jo\u0161 uvijek s uspjehom, koristimo kombinirano rje\u0161enje temeljen na Nagiosu i Muninu.","canonical_url":"https:\/\/prohoster.info\/hr\/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":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/53966","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=53966"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/53966\/revisions"}],"predecessor-version":[{"id":172868,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/53966\/revisions\/172868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=53966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=53966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=53966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}