{"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\/ro\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","title":{"rendered":"Utilizarea parti\u021bion\u0103rii \u00een MySQL pentru Zabbix cu un num\u0103r mare de obiecte de monitorizare","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pentru monitorizarea serverelor \u0219i a serviciilor, utiliz\u0103m de mult timp o solu\u021bie combinat\u0103 bazat\u0103 pe Nagios \u0219i Munin, cu succes continuu. Cu toate acestea, aceast\u0103 combina\u021bie are o serie de dezavantaje, a\u0219a c\u0103, la fel ca mul\u021bi al\u021bii, ne-am orientat activ Zabbix<\/a><\/noindex>. \u00cen acest articol, vom explica cum, cu eforturi minime, se poate rezolva problema legat\u0103 de performan\u021b\u0103 atunci c\u00e2nd num\u0103rul metricelor monitorizate cre\u0219te \u0219i volumul bazei de date MySQL se extinde.
\n<\/a><\/noindex><\/p>\n

Probleme legate de utilizarea bazei de date MySQL \u00eempreun\u0103 cu Zabbix<\/h3>\n

\nP\u00e2n\u0103 c\u00e2nd baza de date era mic\u0103 \u0219i num\u0103rul metricelor stocate \u00een ea era mic, totul func\u021biona excelent. Procesul de \u00eentre\u021binere housekeeper care pornea automat de Zabbix Server reu\u0219ea s\u0103 elimine \u00eenregistr\u0103rile \u00eenvechite din baza de date, \u00eempiedic\u00e2ndu-i astfel cre\u0219terea. Cu toate acestea, de \u00eendat\u0103 ce num\u0103rul metricelor monitorizate a crescut \u0219i volumul bazei de date a atins o dimensiune oarecare, lucrurile s-au deteriorat. Housekeeper a \u00eencetat s\u0103 elimine datele \u00een intervalul de timp alocat, iar \u00een baza de date au r\u0103mas date vechi. \u00cen timpul func\u021bion\u0103rii housekeeper-ului, s-a sim\u021bit o sarcin\u0103 crescut\u0103 pe Zabbix Server, care putea dura mult timp. A devenit clar c\u0103 trebuie s\u0103 se fac\u0103 ceva pentru a rezolva situa\u021bia.<\/p>\n

Aceasta este o problem\u0103 cunoscut\u0103; aproape to\u021bi cei care au lucrat cu volume mari de monitorizare pe Zabbix s-au confruntat cu aceea\u0219i situa\u021bie. Au existat \u0219i mai multe solu\u021bii: de exemplu, \u00eenlocuirea MySQL cu PostgreSQL sau chiar Elasticsearch, dar cea mai simpl\u0103 \u0219i testat\u0103 solu\u021bie a fost trecerea la parti\u021bionarea tablourilor care stocheaz\u0103 datele metricelor \u00een baza de date MySQL. Am decis s\u0103 mergem exact pe aceast\u0103 cale.<\/p>\n

Trecerea de la tablouri MySQL obi\u0219nuite la cele parti\u021bionate<\/h3>\n

\nZabbix este bine documentat, iar tablourile \u00een care stocheaz\u0103 metricile sunt cunoscute. Acestea sunt tablouri: history<\/code>, unde sunt stocate valori float, history_str<\/code>, unde sunt stocate valori scurte de tip string, history_text<\/code>, unde sunt stocate valori lungi de text \u0219i history_uint<\/code>, unde sunt stocate valori \u00eentregi. Exist\u0103 \u0219i un tablou trends<\/code>, care stocheaz\u0103 dinamica modific\u0103rilor, dar am decis s\u0103 nu-l atingem, deoarece dimensiunea sa este mic\u0103 \u0219i ne vom \u00eentoarce la el mai t\u00e2rziu.<\/p>\n

\u00cen general, a fost clar ce tabele trebuie procesate. Am decis s\u0103 facem parti\u021bii pentru fiecare s\u0103pt\u0103m\u00e2n\u0103, cu excep\u021bia ultimei, baz\u00e2ndu-ne pe zilele lunii, adic\u0103 c\u00e2te patru parti\u021bii pe lun\u0103: de la 1 la 7, de la 8 la 14, de la 15 la 21 \u0219i de la 22 la 1 (a lunii urm\u0103toare). Dificultatea a fost c\u0103 trebuia s\u0103 transform\u0103m tabelele necesare \u00een tabele parti\u021bionate \"pe loc\", f\u0103r\u0103 a \u00eentrerupe func\u021bionarea serverului Zabbix \u0219i colectarea metricilor.<\/p>\n

Cumva, structura de date a tabelelor ne-a venit \u00een ajutor. De exemplu, tabela history <\/code>are urm\u0103toarea structur\u0103:<\/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
\n\u00een acest context,<\/p>\n
CHEIE `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nCum vedem, fiecare metric\u0103 este \u00eenregistrat\u0103 \u00een cele din urm\u0103 \u00een tabel\u0103 cu dou\u0103 c\u00e2mpuri foarte importante \u0219i utile pentru noi: itemid<\/b> \u0219i clock<\/b>. Astfel, putem crea o tabel\u0103 temporar\u0103, de exemplu, cu numele history_tmp<\/code>, s\u0103 configur\u0103m parti\u021bionarea pentru aceasta \u0219i apoi s\u0103 transfer\u0103m toate datele din tabela history<\/code>, dup\u0103 care s\u0103 redenumim tabela history<\/code> \u00een history_old<\/code>, iar tabela history_tmp<\/code> \u00een history<\/code>, dup\u0103 care s\u0103 ad\u0103ug\u0103m datele care nu au fost \u00eenc\u0103 transferate din history_old<\/code> \u00een history <\/code>\u0219i s\u0103 \u0219tergem history_old<\/code>. Putem face asta complet \u00een siguran\u021b\u0103, nu vom pierde nimic, deoarece c\u00e2mpurile men\u021bionate mai sus itemid <\/b>\u0219i clock <\/b>asigur\u0103 leg\u0103tura metricii specifice cu un anumit moment, nu cu un num\u0103r de ordine.<\/p>\n
Procedura de tranzi\u021bie<\/h3>\n
<\/p>\n
Aten\u021bie! Este foarte recomandat, \u00eenainte de a \u00eencepe orice ac\u021biune, s\u0103 facem o copie de rezerv\u0103 complet\u0103 a bazei de date. Suntem cu to\u021bii oameni \u0219i putem gre\u0219i \u00een introducerea comenzilor, ceea ce poate duce la pierderi de date. Da, copia de rezerv\u0103 nu va asigura actualitatea maxim\u0103, dar este mai bine s\u0103 avem una dec\u00e2t s\u0103 nu avem deloc.<\/p><\/blockquote>\n
 A\u0219adar, nu oprim \u0219i nu \u00eenchidem nimic. Principalul este s\u0103 existe suficient spa\u021biu liber pe disc pe serverul MySQL, adic\u0103 pentru fiecare din tabelele enumerate mai sus history<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, s\u0103 fie disponibil, cel pu\u021bin, suficient loc pentru crearea unei tabele cu sufixul \u201e_tmp\u201d, av\u00e2nd \u00een vedere c\u0103 aceasta va avea acela\u0219i volum ca \u0219i tabela ini\u021bial\u0103.<\/p>\n
Nu vom descrie totul de mai multe ori pentru fiecare din tabelele men\u021bionate \u0219i vom considera totul pe exemplul doar uneia dintre ele \u2014 tabela history<\/code>.<\/p>\n
A\u0219adar, cre\u0103m o tabel\u0103 goal\u0103 history_tmp <\/code>bazat\u0103 pe structura tabelei history<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nCre\u0103m parti\u021biile necesare. De exemplu, vom face acest lucru pentru o lun\u0103. Fiecare parti\u021bie este creat\u0103 pe baza unei reguli de parti\u021bionare, bazate pe valoarea c\u00e2mpului clock<\/b>, pe care o compar\u0103m cu marca de timp:<\/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
\nAceast\u0103 comand\u0103 adaug\u0103 parti\u021bionare pentru tabela creat\u0103 de noi history_tmp<\/code>. S\u0103 preciz\u0103m c\u0103 datele, al c\u0103ror c\u00e2mp clock <\/b>este mai mic dec\u00e2t \u201e2019-02-01 00:00:00\u201d vor c\u0103dea \u00een parti\u021bia p20190201<\/i>, apoi datele al c\u0103ror c\u00e2mp clock<\/b> este mai mare dec\u00e2t \u201e2019-02-01 00:00:00\u201d dar mai mic dec\u00e2t \u201e2019-02-07 00:00:00\u201d vor c\u0103dea \u00een parti\u021bia p20190207 <\/i>\u0219i a\u0219a mai departe.<\/p>\n
Not\u0103 important\u0103:<\/b> Ce se va \u00eent\u00e2mpla dac\u0103 \u00een tabela noastr\u0103 parti\u021bionat\u0103 apar date al c\u0103ror c\u00e2mp clock va fi mai mare sau egal cu \u201e2019-03-01 00:00:00\u201d? Deoarece nu exist\u0103 o parti\u021bie adecvat\u0103 pentru aceste date, ele nu vor fi incluse \u00een tabel \u0219i se vor pierde. Prin urmare, este necesar s\u0103 nu uita\u021bi s\u0103 crea\u021bi la timp parti\u021bii suplimentare, pentru a evita astfel de pierderi de date (despre care vom discuta mai jos).<\/p><\/blockquote>\n
 A\u0219adar, tabela temporar\u0103 este preg\u0103tit\u0103. \u00cencepem \u00eenc\u0103rcarea datelor. Procesul poate dura destul de mult timp, dar din fericire, nu blocheaz\u0103 alte cereri, deci trebuie doar s\u0103 ave\u021bi r\u0103bdare:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nCuv\u00e2ntul cheie IGNORE la \u00eenc\u0103rcarea ini\u021bial\u0103 nu este obligatoriu, deoarece nu exist\u0103 date \u00een tabel, totu\u0219i \u00eel ve\u021bi avea nevoie la o \u00eenc\u0103rcare ulterioar\u0103 a datelor. \u00cen plus, acesta poate fi util dac\u0103 a trebuit s\u0103 \u00eentrerupe\u021bi acest proces \u0219i s\u0103 \u00eencepe\u021bi din nou.<\/p>\n
A\u0219adar, dup\u0103 un timp (poate chiar c\u00e2teva ore), prima \u00eenc\u0103rcare a datelor a fost complet\u0103. A\u0219a cum v\u0103 imagina\u021bi, acum tabelul history_tmp <\/code>con\u021bine nu toate datele din tabelul history<\/code>, ci doar cele care au fost \u00een el \u00een momentul \u00eenceperii execu\u021biei cererii. Aici, \u00een principiu, ave\u021bi op\u021biunea: fie facem o alt\u0103 trecere (dac\u0103 procesul de \u00eenc\u0103rcare a durat mult), fie trecem direct la redenumirea tabelelor, despre care am discutat mai sus. S\u0103 discut\u0103m mai \u00eent\u00e2i despre a doua trecere. Pentru \u00eenceput, trebuie s\u0103 \u00een\u021belegem timpul ultimei \u00eenregistr\u0103ri inserate \u00een history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nS\u0103 presupunem c\u0103 a\u021bi ob\u021binut: 1551045645<\/b>. Acum folosim valoarea ob\u021binut\u0103 \u00een a doua trecere a \u00eenc\u0103rc\u0103rii datelor:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nAceast\u0103 trecere ar trebui s\u0103 se termine semnificativ mai repede. Dar dac\u0103 prima trecere a durat ore, iar a doua dureaz\u0103 de asemenea mult, poate ar fi corect s\u0103 facem \u0219i o a treia trecere, care se desf\u0103\u0219oar\u0103 complet similar celei de-a doua.<\/p>\n
La final, efectuam din nou opera\u021bia de a ob\u021bine timpul ultimei inser\u021bii a \u00eenregistr\u0103rii \u00een history_tmp<\/code>, execut\u00e2nd:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nPresupunem c\u0103 a\u021bi ob\u021binut 1551085645<\/b>. Salva\u021bi aceast\u0103 valoare \u2014 ne va fi necesar\u0103 pentru suplimentarea datelor.<\/p>\n
\u0218i acum, c\u00e2nd \u00eenc\u0103rcarea ini\u021bial\u0103 a datelor \u00een history_tmp <\/code>s-a \u00eencheiat, \u00eencepem redenumirea tabelelor:<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nAm structurat acest bloc ca o singur\u0103 tranzac\u021bie, pentru a evita inserarea datelor \u00een o tabel\u0103 inexistent\u0103, deoarece dup\u0103 prima redenumire, p\u00e2n\u0103 la finalizarea celei de-a doua redenumiri, tabela history <\/code>nu va exista. Dar chiar dac\u0103 \u00eentre opera\u021biile de redenumire \u00een tabel vor veni unele date, iar tabela \u00een sine nu va fi \u00eenc\u0103 disponibil\u0103 (din cauza redenumirii), vom ob\u021bine un num\u0103r mic de erori de inserare, care pot fi neglijate (avem monitorizare, nu un banc). history <\/code>Acum avem o nou\u0103 tabel\u0103<\/p>\n
cu parti\u021bionare, dar \u00eei lipsesc datele care au fost ob\u021binute \u00een timpul ultimei treceri a inser\u021biei de date \u00een tabel history<\/code> . Dar aceste date le avem \u00een tabelul history_tmp<\/code>\u0219i le vom completa acum. Pentru aceasta, ne va trebui valoarea salvat\u0103 anterior 1551085645. De ce am salvat aceast\u0103 valoare \u0219i nu am folosit timpul maxim de \u00eenc\u0103rcare deja din tabelul curent 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
Dup\u0103 finalizarea acestei opera\u021bii, avem \u00een noua noastr\u0103 tabel\u0103, par\u021bionat\u0103<\/code><\/pre>\n
\ntoate datele care erau \u00een vechea, plus cele care au venit deja dup\u0103 redenumirea tabelei. Tabela history <\/code>nu ne mai este necesar\u0103. O putem \u0219terge imediat sau putem face o copie de rezerv\u0103 \u00eenainte de a o \u0219terge (dac\u0103 sunte\u021bi paranoici). history_old <\/code>\u00centregul proces descris mai sus trebuie s\u0103 fie repetat pentru tabelele<\/p>\n
Ce trebuie corectat \u00een set\u0103rile Zabbix Server history_str<\/code>, history_text <\/code>\u0219i history_uint<\/code>.<\/p>\n
Ce trebuie s\u0103 corect\u0103m \u00een set\u0103rile Zabbix Server<\/h3>\n
\nAcum, gestionarea bazei de date \u00een ceea ce prive\u0219te istoricul datelor revine \u00een sarcina noastr\u0103. Acest lucru \u00eenseamn\u0103 c\u0103 Zabbix nu va mai trebui s\u0103 \u0219terg\u0103 datele vechi \u2014 ne vom ocupa noi de acest lucru. Pentru a preveni ca Zabbix Server s\u0103 \u00eencerce s\u0103 cure\u021be datele singur, trebuie s\u0103 accesa\u021bi interfa\u021ba web a Zabbix, s\u0103 selecta\u021bi din meniul \u201eAdministrare\u201d, apoi submeniu \u201eGeneral\u201d, iar \u00een lista derulant\u0103 din dreapta s\u0103 alege\u021bi \u201eCur\u0103\u021bare istoric\u201d. Pe pagina care apare, trebuie s\u0103 debifa\u021bi toate casetele pentru grupul \u201eIstoric\u201d \u0219i s\u0103 ap\u0103sa\u021bi pe butonul \u201eActualizare\u201d. Acest lucru va preveni cur\u0103\u021barea inutil\u0103 a tabelului nostru. history*<\/code> prin housekeeper.<\/p>\n
Re\u021bine\u021bi pe aceea\u0219i pagin\u0103 grupul \u201eDinamic\u0103 a modific\u0103rilor\u201d. Aceasta este exact tabela trends<\/code>, la care am promis c\u0103 ne vom \u00eentoarce. Dac\u0103 aceasta a devenit \u0219i ea prea mare \u0219i necesit\u0103 particionare, debifa\u021bi casetele \u0219i \u00een acest grup, apoi trata\u021bi aceast\u0103 tabel\u0103 exact a\u0219a cum a fost f\u0103cut pentru tabelele history*<\/code>.<\/p>\n
\u00centre\u021binerea ulterioar\u0103 a bazei de date<\/h3>\n
\nA\u0219a cum s-a men\u021bionat anterior, pentru a func\u021biona corect cu tabelele partitionate, este necesar s\u0103 se creeze la timp particiile. Acest lucru se poate face astfel:<\/p>\n
ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\n\u00cen plus, deoarece am creat tabele partitionate \u0219i am interzis Zabbix Server-ului s\u0103 le cure\u021be, \u0219tergerea datelor vechi este acum responsabilitatea noastr\u0103. Din fericire, nu exist\u0103 probleme de acest fel. Acest lucru se face pur \u0219i simplu prin \u0219tergerea acelei particii a c\u0103rei date nu ne mai sunt necesare. <\/p>\n
De exemplu:<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nSpre deosebire de operatorii DELETE FROM cu specificarea unei interval de date, DROP PARTITION se execut\u0103 \u00een c\u00e2teva secunde, f\u0103r\u0103 a crea o sarcin\u0103 mare serverul<\/a> \u0219i func\u021bioneaz\u0103 la fel de bine \u00een cazul utiliz\u0103rii replic\u0103rii MySQL.<\/p>\n
Concluzie<\/h3>\n
\nSolu\u021bia descris\u0103 a fost testat\u0103 \u00een timp. Volumul de date cre\u0219te, dar nu am observat o \u00eencetinire semnificativ\u0103 a performan\u021bei.
\n
Sursa: 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\udd47Utilizarea particion\u0103rii \u00een MySQL pentru Zabbix cu un num\u0103r mare de obiecte de monitorizare | ProHoster","description":"Pentru monitorizarea serverelor \u0219i serviciilor, folosim de mult timp, \u0219i \u00een continuare cu succes, o solu\u021bie combinat\u0103 bazat\u0103 pe Nagios \u0219i Munin.","canonical_url":"https:\/\/prohoster.info\/ro\/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":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/53966","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=53966"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/53966\/revisions"}],"predecessor-version":[{"id":172868,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/53966\/revisions\/172868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=53966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=53966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=53966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}