{"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\/sq\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","title":{"rendered":"P\u00ebrdorimi i particionimit n\u00eb MySQL p\u00ebr Zabbix me nj\u00eb num\u00ebr t\u00eb madh objektesh monitorimi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

P\u00ebr monitorimin e server\u00ebve dhe sh\u00ebrbimeve kemi p\u00ebrdorur prej koh\u00ebsh nj\u00eb zgjidhje t\u00eb kombinuar mbi baz\u00ebn e Nagios dhe Munin. Megjithat\u00eb, kjo lidhje ka disa disavantazhe, prandaj ne, si shum\u00eb t\u00eb tjer\u00eb, e shfryt\u00ebzojm\u00eb aktivisht Zabbix<\/a><\/noindex>. N\u00eb k\u00ebt\u00eb artikull do t\u00eb flasim p\u00ebr m\u00ebnyrat se si mund t\u00eb zgjidhni problemin e performanc\u00ebs me minimum p\u00ebrpjekjesh, nd\u00ebrsa numri i metrikave t\u00eb mbledhura rritet dhe rritet volumi i BD MySQL
\n<\/a><\/noindex><\/p>\n

Problemet e p\u00ebrdorimit t\u00eb BD MySQL n\u00eb p\u00ebrputhje me Zabbix<\/h3>\n

\nDerisa BD ishte e vog\u00ebl dhe numri i metrikave t\u00eb ruajtura n\u00eb t\u00eb ishte i vog\u00ebl, gjith\u00e7ka shkonte mrekullisht. Procesi standard housekeeper, i cili aktivizohet nga Zabbix Server, kishte sukses t\u00eb fshinte t\u00eb dh\u00ebnat e vjetra nga BD, duke mos e lejuar at\u00eb t\u00eb rritet. Megjithat\u00eb, sa her\u00eb q\u00eb numri i metrikave t\u00eb mbledhura u rrit dhe volumi i BD arriti nj\u00eb madh\u00ebsi t\u00eb caktuar, gjith\u00e7ka u p\u00ebrkeq\u00ebsua. Housekeeper nuk arriti t\u00eb fshinte t\u00eb dh\u00ebnat brenda intervalit t\u00eb caktuar, duke l\u00ebn\u00eb t\u00eb dh\u00ebna t\u00eb vjetra n\u00eb BD. Gjat\u00eb pun\u00ebs s\u00eb housekeeper kishte ngarkes\u00eb t\u00eb shtuar n\u00eb Zabbix Server, e cila mund t\u00eb zgjaste p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb. U b\u00eb e qart\u00eb se duhej t\u00eb gjeje nj\u00eb zgjidhje p\u00ebr situat\u00ebn e krijuar.<\/p>\n

Kjo \u00ebsht\u00eb nj\u00eb problem i njohur, pothuajse secili q\u00eb ka punuar me volume t\u00eb m\u00ebdha monitorimi n\u00eb Zabbix \u00ebsht\u00eb p\u00ebrballur me t\u00eb nj\u00ebjt\u00ebn gj\u00eb. Zgjidhjet gjithashtu ishin disa: p\u00ebr shembull, z\u00ebvend\u00ebsimi i MySQL me PostgreSQL ose madje Elasticsearch, por zgjidhja m\u00eb e thjesht\u00eb dhe e provuar ishte kalimi n\u00eb pjes\u00ebzim t\u00eb tabelave q\u00eb ruajn\u00eb t\u00eb dh\u00ebnat e metrikave n\u00eb BD MySQL. Ne vendos\u00ebm t\u00eb ndjekim k\u00ebt\u00eb rrug\u00eb.<\/p>\n

Kalimi nga tabelat e zakonshme MySQL n\u00eb ato t\u00eb ndara<\/h3>\n

\nZabbix \u00ebsht\u00eb mir\u00eb-dokumentuar dhe tabelat ku ruan metrikat jan\u00eb t\u00eb njohura. K\u00ebto jan\u00eb tabelat: history<\/code>, ku ruhen vlera float, history_str<\/code>, ku ruhen vlera t\u00eb shkurtra string, history_text<\/code>, ku ruhen vlera t\u00eb gjata tekstuale dhe history_uint<\/code>, ku ruhen vlera t\u00eb plota. Ka gjithashtu nj\u00eb tabel\u00eb trends<\/code>, e cila ruan dinamik\u00ebn e ndryshimeve, por ne vendos\u00ebm ta l\u00ebm\u00eb t\u00eb paprekur, sepse madh\u00ebsia e saj \u00ebsht\u00eb e vog\u00ebl dhe m\u00eb von\u00eb do t\u00eb kthehemi te ajo.<\/p>\n

N\u00eb p\u00ebrgjith\u00ebsi, ishte e qart\u00eb se cilat tabela duhej t\u00eb p\u00ebrpunoheshin. Ne vendos\u00ebm t\u00eb krijonim pjes\u00eb p\u00ebr \u00e7do jav\u00eb, p\u00ebrve\u00e7 jav\u00ebs s\u00eb fundit, bazuar n\u00eb numrat e muajit, dometh\u00ebn\u00eb, kat\u00ebr pjes\u00eb p\u00ebr muaj: nga 1 deri n\u00eb 7, nga 8 deri n\u00eb 14, nga 15 deri n\u00eb 21 dhe nga 22 deri n\u00eb 1 (t\u00eb muajit tjet\u00ebr). V\u00ebshtir\u00ebsia ishte se duhej t\u00eb transformonim tabelat q\u00eb na duheshin n\u00eb tabelat e ndara \"n\u00eb flak\u00eb\", pa nd\u00ebrprer\u00eb pun\u00ebn e Zabbix Server dhe mbledhjen e metrikave.<\/p>\n

Si\u00e7 duket e \u00e7uditshme, struktura e t\u00eb dh\u00ebnave t\u00eb tabelave na ndihmoi n\u00eb k\u00ebt\u00eb. history <\/code>P\u00ebr shembull, tabela<\/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
\nnd\u00ebrkoh\u00eb q\u00eb<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nSi\u00e7 e shohim, \u00e7do metrik\u00eb p\u00ebrfundimisht sh\u00ebnohet n\u00eb tabel\u00eb me dy fusha shum\u00eb t\u00eb r\u00ebnd\u00ebsishme dhe t\u00eb p\u00ebrshtatshme p\u00ebr ne itemid<\/b> dhe clock<\/b>. K\u00ebshtu, ne mund t\u00eb krijojm\u00eb nj\u00eb tabel\u00eb p\u00ebrkohshme, p\u00ebr shembull, me emrin history_tmp<\/code>, t\u00eb konfiguroni ndarjen p\u00ebr t\u00eb dhe m\u00eb pas t\u00eb derdhni t\u00eb gjith\u00eb t\u00eb dh\u00ebnat nga tabela history<\/code>, e pastaj t\u00eb rinominojm\u00eb tabel\u00ebn history<\/code> n\u00eb history_old<\/code>, dhe tabel\u00ebn history_tmp<\/code> n\u00eb history<\/code>, pas t\u00eb cilit do t\u00eb shtojm\u00eb ato t\u00eb dh\u00ebna q\u00eb nuk i kemi futur nga history_old<\/code> n\u00eb history <\/code>dhe t\u00eb fshihet history_old<\/code>. Kjo mund t\u00eb b\u00ebhet krejt\u00ebsisht n\u00eb m\u00ebnyr\u00eb t\u00eb sigurt, ne nuk do t\u00eb humbim asgj\u00eb, pasi fusha t\u00eb p\u00ebrmendura m\u00eb sip\u00ebr itemid <\/b>dhe clock <\/b>sigurojn\u00eb lidhjen e metrikave t\u00eb caktuara me nj\u00eb koh\u00eb t\u00eb caktuar, dhe jo me nj\u00eb num\u00ebr rendor.<\/p>\n
Procedura e kalimit<\/h3>\n
<\/p>\n
Kujdes! \u00cbsht\u00eb shum\u00eb e d\u00ebshirueshme, para se t\u00eb filloni ndonj\u00eb veprim, t\u00eb b\u00ebni nj\u00eb kopje t\u00eb plot\u00eb rezerv\u00eb t\u00eb databaz\u00ebs. Ne jemi njer\u00ebz t\u00eb gjall\u00eb dhe mund t\u00eb b\u00ebjm\u00eb gabime n\u00eb komanda, q\u00eb mund t\u00eb \u00e7ojn\u00eb n\u00eb humbje t\u00eb t\u00eb dh\u00ebnash. Po, kopja rezerv\u00eb nuk do t\u00eb siguroj\u00eb maksimalisht aktualitetin, por \u00ebsht\u00eb m\u00eb mir\u00eb t\u00eb kesh nj\u00eb t\u00eb till\u00eb sesa asnj\u00eb.<\/p><\/blockquote>\n
 Pra, asgj\u00eb nuk fiket dhe nuk ndalet. E r\u00ebnd\u00ebsishme \u00ebsht\u00eb q\u00eb n\u00eb MySQL server t\u00eb ekzistoj\u00eb nj\u00eb hap\u00ebsir\u00eb e mjaftueshme e lir\u00eb n\u00eb disk, dometh\u00ebn\u00eb, p\u00ebr secil\u00ebn nga tabelat e p\u00ebrmendura m\u00eb sip\u00ebr history<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, duhen t\u00eb pakt\u00ebn sa hap\u00ebsir\u00eb p\u00ebr t\u00eb krijuar nj\u00eb tabel\u00eb me sufixin \"_tmp\", duke e pasur parasysh se do t\u00eb ket\u00eb t\u00eb nj\u00ebjt\u00ebn pesh\u00eb si tabela origjinale.<\/p>\n
Ne nuk do ta p\u00ebrshkruajm\u00eb gjith\u00e7ka disa her\u00eb p\u00ebr secil\u00ebn nga tabelat e m\u00ebsip\u00ebrme dhe do ta shqyrtojm\u00eb gjith\u00e7ka vet\u00ebm n\u00eb shembullin e nj\u00eb prej tyre \u2014 tabel\u00ebs history<\/code>.<\/p>\n
Pra, krijojm\u00eb nj\u00eb tabel\u00eb t\u00eb zbraz\u00ebt history_tmp <\/code>n\u00eb baz\u00eb t\u00eb struktur\u00ebs s\u00eb tabel\u00ebs history<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nKrijojm\u00eb partit\u00eb q\u00eb na nevojiten. P\u00ebr shembull, do ta b\u00ebjm\u00eb k\u00ebt\u00eb p\u00ebr nj\u00eb muaj. \u00c7do parti krijohet mbi baz\u00ebn e nj\u00eb rregulli ndarjeje, i bazuar n\u00eb vler\u00ebn e fush\u00ebs clock<\/b>, e cila e krahasojm\u00eb me vul\u00ebn e koh\u00ebs:<\/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
\nKy operator shton ndarjen p\u00ebr tabel\u00ebn q\u00eb krijuam history_tmp<\/code>. Sqarojm\u00eb se t\u00eb dh\u00ebnat, t\u00eb cilat kan\u00eb vler\u00ebn e fush\u00ebs clock <\/b>m\u00eb pak se \"2019-02-01 00:00:00\" do t\u00eb hyjn\u00eb n\u00eb partin\u00eb p20190201<\/i>, pastaj t\u00eb dh\u00ebnat t\u00eb cilat kan\u00eb vler\u00ebn e fush\u00ebs clock<\/b> m\u00eb shum\u00eb se \"2019-02-01 00:00:00\" por m\u00eb pak se \"2019-02-07 00:00:00\" do t\u00eb hyjn\u00eb n\u00eb partin\u00eb p20190207 <\/i>dhe k\u00ebshtu me radh\u00eb.<\/p>\n
Nj\u00eb sh\u00ebnim i r\u00ebnd\u00ebsish\u00ebm:<\/b> \u00c7far\u00eb do t\u00eb ndodh\u00eb, n\u00ebse n\u00eb tabel\u00ebn me ndarje duhet t\u00eb kemi t\u00eb dh\u00ebna p\u00ebr t\u00eb cilat vlera e fush\u00ebs clock \u00ebsht\u00eb m\u00eb e madhe ose e barabart\u00eb me \"2019-03-01 00:00:00\"? P\u00ebr shkak se p\u00ebr k\u00ebto t\u00eb dh\u00ebna nuk ka nj\u00eb parti t\u00eb p\u00ebrshtatshme, ato nuk do t\u00eb hyjn\u00eb n\u00eb tabel\u00eb dhe do t\u00eb humbasin. Prandaj, \u00ebsht\u00eb e nevojshme t\u00eb mos harroni t\u00eb krijoni me koh\u00eb parti t\u00eb tjera, p\u00ebr t\u00eb parandaluar humbjen e till\u00eb t\u00eb t\u00eb dh\u00ebnave (si\u00e7 do t\u00eb shpjegohet m\u00eb posht\u00eb).<\/p><\/blockquote>\n
 Pra, tabela e p\u00ebrkohshme \u00ebsht\u00eb p\u00ebrgatitur. Po ngarkojm\u00eb t\u00eb dh\u00ebnat. Procesi mund t\u00eb zgjas\u00eb nj\u00eb koh\u00eb t\u00eb gjat\u00eb, por fatmir\u00ebsisht ai nuk bllokon k\u00ebrkesa t\u00eb tjera, k\u00ebshtu q\u00eb thjesht duhet t\u00eb jeni t\u00eb duruesh\u00ebm:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nFjalori kryesor IGNORE gjat\u00eb ngarkes\u00ebs fillestare nuk \u00ebsht\u00eb i domosdosh\u00ebm, pasi t\u00eb dh\u00ebnat n\u00eb tabel\u00eb nuk ka, megjithat\u00eb ai do t'ju nevojitet gjat\u00eb ngarkes\u00ebs s\u00eb m\u00ebtejshme t\u00eb t\u00eb dh\u00ebnave. P\u00ebr m\u00eb tep\u00ebr, ai mund t\u00eb jet\u00eb i dobish\u00ebm, n\u00ebse gjat\u00eb ngarkes\u00ebs t\u00eb dh\u00ebnash ju duhej ta nd\u00ebrprisnit k\u00ebt\u00eb proces dhe ta fillonit nga e para.<\/p>\n
Pra, pas nj\u00eb kohe (ndoshta edhe disa or\u00eb), ngarkesa e par\u00eb e t\u00eb dh\u00ebnave ka p\u00ebrfunduar. Si\u00e7 e kuptoni, tani tabela history_tmp <\/code>p\u00ebrmban t\u00eb gjitha t\u00eb dh\u00ebnat nga tabela history<\/code>, por vet\u00ebm ato q\u00eb ishin n\u00eb t\u00eb n\u00eb momentin e fillimit t\u00eb ekzekutimit t\u00eb k\u00ebrkes\u00ebs. Tani keni nj\u00eb zgjedhje: ose b\u00ebjm\u00eb nj\u00eb kalim tjet\u00ebr (n\u00ebse procesi i ngarkes\u00ebs zgjati gjat\u00eb), ose menj\u00ebher\u00eb kalojm\u00eb n\u00eb rinovimin e tabelave, p\u00ebr t\u00eb cil\u00ebn \u00ebsht\u00eb folur m\u00eb lart. Le t\u00eb flasim fillimisht p\u00ebr kalimin e dyt\u00eb. P\u00ebr fillim na nevojitet t\u00eb kuptojm\u00eb koh\u00ebn e regjistrit t\u00eb fundit t\u00eb futur n\u00eb history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nSupozoni se keni marr\u00eb: 1551045645<\/b>. Tani do tani, ne do ta vler\u00ebsojm\u00eb vler\u00ebn e marr\u00eb n\u00eb kalimin e dyt\u00eb t\u00eb mbushjes s\u00eb t\u00eb dh\u00ebnave:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nKy kalim duhet t\u00eb p\u00ebrfundoj\u00eb shum\u00eb m\u00eb shpejt. Por n\u00ebse kalimi i par\u00eb zgjati or\u00eb, dhe kalimi i dyt\u00eb gjithashtu zgjat p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb, ndoshta do t\u00eb ishte e arsyeshme t\u00eb b\u00ebni edhe nj\u00eb kalim t\u00eb tret\u00eb, i cili do t\u00eb ekzekutohet ashtu si kalimi i dyt\u00eb.<\/p>\n
N\u00eb fund, ne p\u00ebrs\u00ebri kryejm\u00eb operacionin p\u00ebr t\u00eb marr\u00eb koh\u00ebn e fundit t\u00eb shkrimit t\u00eb regjistrit n\u00eb history_tmp<\/code>, duke ekzekutuar:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nSupozoni se keni marr\u00eb 1551085645<\/b>. Ruani k\u00ebt\u00eb vler\u00eb - do na nevojitet p\u00ebr mbushje t\u00eb m\u00ebtejshme.<\/p>\n
Tani, pasi q\u00eb mbushja fillestare e t\u00eb dh\u00ebnave n\u00eb history_tmp <\/code>ka p\u00ebrfunduar, fillojm\u00eb me rinovimin e tabelave:<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nNe e kemi dizajnuar k\u00ebt\u00eb bllok si nj\u00eb transaksion, p\u00ebr t\u00eb shmangur momentin e insertimit t\u00eb t\u00eb dh\u00ebnave n\u00eb nj\u00eb tabel\u00eb q\u00eb nuk ekziston, sepse pas RENAME t\u00eb par\u00eb deri n\u00eb momentin e ekzekutimit t\u00eb RENAME t\u00eb dyt\u00eb, tabela history <\/code>nuk do t\u00eb ekzistoj\u00eb. Por, edhe n\u00ebse gjat\u00eb operacioneve RENAME ndodhin disa t\u00eb dh\u00ebna n\u00eb tabel\u00eb, nd\u00ebrsa tabela vet\u00eb nuk do t\u00eb jet\u00eb (p\u00ebr shkak t\u00eb rinovimit), ne do t\u00eb marrim nj\u00eb num\u00ebr t\u00eb vog\u00ebl gabimesh insertimi, t\u00eb cilat mund t\u00eb injorohen (ne kemi monitorim, jo bank\u00eb). history <\/code>Tani kemi nj\u00eb tabel\u00eb t\u00eb re<\/p>\n
me ndarje, por i mungojn\u00eb t\u00eb dh\u00ebnat q\u00eb u mor\u00ebn gjat\u00eb kalimit t\u00eb fundit t\u00eb mbushjes s\u00eb t\u00eb dh\u00ebnave n\u00eb tabel\u00eb. history<\/code> . Por ne i kemi k\u00ebto t\u00eb dh\u00ebna n\u00eb tabel\u00ebn history_tmp<\/code>dhe tani do t'i mbushim ato nga aty. P\u00ebr k\u00ebt\u00eb, do t\u00eb na nevojitet vlera e ruajtur m\u00eb par\u00eb 1551085645. Pse e ruajm\u00eb k\u00ebt\u00eb vler\u00eb dhe jo koh\u00ebn maksimale t\u00eb mbushjes nga tabela aktuale? 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
Pas p\u00ebrfundimit t\u00eb k\u00ebtij operacioni, n\u00eb tabel\u00ebn ton\u00eb t\u00eb re, t\u00eb ndar\u00eb,<\/code><\/pre>\n
\nkemi t\u00eb gjitha t\u00eb dh\u00ebnat q\u00eb ishin n\u00eb t\u00eb vjetr\u00ebn, plus ato q\u00eb kan\u00eb mb\u00ebrritur pas rinovimit t\u00eb tabel\u00ebs. Tabela history <\/code>nuk na nevojitet m\u00eb. Mund ta fshijm\u00eb menj\u00ebher\u00eb, ose para se ta fshijm\u00eb mund t\u00eb b\u00ebjm\u00eb nj\u00eb kopje rezerv\u00eb (n\u00ebse keni paranoj\u00eb). history_old <\/code>E gjith\u00eb kjo proces duhet p\u00ebrs\u00ebritur p\u00ebr tabelat<\/p>\n
\u00c7far\u00eb duhet t\u00eb rregullohet n\u00eb cil\u00ebsimet e Zabbix Server history_str<\/code>, history_text <\/code>dhe history_uint<\/code>.<\/p>\n
\u0427\u0442\u043e \u043d\u0443\u0436\u043d\u043e \u043f\u043e\u043f\u0440\u0430\u0432\u0438\u0442\u044c \u0432 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0430\u0445 Zabbix Server<\/h3>\n
\nTani administrimi i baz\u00ebs s\u00eb t\u00eb dh\u00ebnave mbi historin\u00eb e t\u00eb dh\u00ebnave tani bie mbi ne. Kjo do t\u00eb thot\u00eb q\u00eb Zabbix nuk duhet m\u00eb t\u00eb fshij\u00eb t\u00eb dh\u00ebna t\u00eb vjetra \u2014 do t\u00eb merremi ne me k\u00ebt\u00eb vet\u00eb. P\u00ebr t\u00eb parandaluar q\u00eb Zabbix Server t\u00eb p\u00ebrpiqet t\u00eb pastroj\u00eb t\u00eb dh\u00ebnat vet\u00eb, ju duhen t\u00eb hyni n\u00eb nd\u00ebrfaqen web t\u00eb Zabbix, t\u00eb zgjidhni n\u00eb menun\u00eb \"Administrimi\", pastaj n\u00ebnmenun\u00eb \"T\u00eb p\u00ebrgjithshmet\", dhe m\u00eb pas n\u00eb list\u00ebn e r\u00ebnies nga ana e djatht\u00eb t\u00eb zgjidhni \"Pastrimin e historis\u00eb\". N\u00eb faqen q\u00eb shfaqet, duhet t\u00eb hiqni t\u00eb gjitha shenjat p\u00ebr grupin \"Historia\" dhe t\u00eb klikoni n\u00eb butonin \"Rivendos\". Kjo do t\u00eb parandaloj\u00eb pastrimin e panevojsh\u00ebm t\u00eb tabelave. historia*<\/code> n\u00ebp\u00ebrmjet housekeeper.<\/p>\n
Vini re se n\u00eb k\u00ebt\u00eb faqe po ashtu, ndodhet grupi \"Dinamikat e ndryshimeve\". Kjo \u00ebsht\u00eb tabela trends<\/code>, t\u00eb cil\u00ebs ne premtuam se do t'i kthehemi. N\u00ebse kjo gjithashtu ka b\u00ebr\u00eb shum\u00eb t\u00eb madhe dhe ka nevoj\u00eb p\u00ebr ndarje, hiqni shenjat n\u00eb k\u00ebt\u00eb grup, dhe pastaj trajtoni k\u00ebt\u00eb tabel\u00eb ashtu si\u00e7 \u00ebsht\u00eb b\u00ebr\u00eb p\u00ebr tabelat historia*<\/code>.<\/p>\n
Mir\u00ebmbajtja e m\u00ebtejshme e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave<\/h3>\n
\nAshtu si\u00e7 u tha m\u00eb par\u00eb, p\u00ebr funksionimin normal t\u00eb tabelave t\u00eb ndara, \u00ebsht\u00eb e nevojshme t\u00eb krijoni ndarje n\u00eb koh\u00eb. K\u00ebt\u00eb mund ta b\u00ebni k\u00ebshtu:<\/p>\n
ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\nP\u00ebr m\u00eb tep\u00ebr, q\u00eb ne krijuam tabela t\u00eb ndara dhe ndaluam Zabbix Server t\u00eb pastronte ato, tani fshirja e t\u00eb dh\u00ebnave t\u00eb vjetra \u00ebsht\u00eb p\u00ebrgjegj\u00ebsia jon\u00eb. Fatmir\u00ebsisht, k\u00ebtu nuk ka asnj\u00eb problem. Kjo b\u00ebhet thjesht duke fshir\u00eb at\u00eb ndarje, t\u00eb cilat t\u00eb dh\u00ebnat e saj nuk na duhen m\u00eb. <\/p>\n
P\u00ebr shembull:<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nNdryshe nga operator\u00ebt DELETE FROM me nj\u00eb diapazon datash, DROP PARTITION ekzekutohet p\u00ebr disa sekonda, dhe nuk shkakton ndonj\u00eb ngarkes\u00eb server<\/a> dhe funksionon nj\u00ebsoj pa probleme n\u00eb rastin e p\u00ebrdorimit t\u00eb replikimit n\u00eb MySQL.<\/p>\n
P\u00ebrfundim<\/h3>\n
\nZgjidhja e p\u00ebrshkruar \u00ebsht\u00eb provuar me kalimin e koh\u00ebs. V\u00ebllimi i t\u00eb dh\u00ebnave rritet, por nuk ka ushtruar ndonj\u00eb ngadal\u00ebsim t\u00eb duksh\u00ebm t\u00eb performanc\u00ebs.
\n
Burimi: 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\udd47P\u00ebrdorimi i ndarjes n\u00eb MySQL p\u00ebr Zabbix me nj\u00eb num\u00ebr t\u00eb madh objektesh monitorimi | ProHoster","description":"P\u00ebr monitorimin e server\u00ebve dhe sh\u00ebrbimeve, ne prej koh\u00ebsh, dhe ende me sukses, p\u00ebrdorim nj\u00eb zgjidhje t\u00eb kombinuar bazuar n\u00eb Nagios dhe Munin.","canonical_url":"https:\/\/prohoster.info\/sq\/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":"sq_AL","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\/sq\/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\/sq\/wp-json\/wp\/v2\/posts\/53966","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=53966"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/53966\/revisions"}],"predecessor-version":[{"id":172868,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/53966\/revisions\/172868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=53966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=53966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=53966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}