{"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\/et\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","title":{"rendered":"MySQL-i parterite kasutamine Zabbixis, millel on suur hulk j\u00e4lgitavaid objekte","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Serverite ja teenuste j\u00e4lgimiseks oleme juba pikka aega edukalt kasutanud Nagios ja Munin baasil p\u00f5hinevat lahendust. Siiski on sellel kombinatsioonil mitmeid puudusi, mist\u00f5ttu kasutame ka meie aktiivselt. Zabbix<\/a><\/noindex>. Selles artiklis r\u00e4\u00e4gime, kuidas minimaalse vaeva ning pingutusega saab lahendada j\u00f5udlusprobleeme, kui j\u00e4lgitavate m\u00f5\u00f5dikute arv suureneb ja MySQL andmebaasi maht kasvab.
\n<\/a><\/noindex><\/p>\n

MySQL andmebaasi probleemid koos Zabbixiga<\/h3>\n

\nKuni andmebaas oli v\u00e4ike ja selles hoitavate m\u00f5\u00f5dikute arv v\u00e4ike, l\u00e4ks k\u00f5ik suurep\u00e4raselt. Zabbix Serveri k\u00e4ivitav teenus housekeeper suutis edukalt kustutada vanu kirjeid andmebaasist, takistades selle suurenemist. Kuid niipea, kui j\u00e4lgitavate m\u00f5\u00f5dikute arv suurenes ja andmebaasi maht saavutas teatud suuruse, halvenes olukord. Housekeeper ei suutnud k\u00fcmne m\u00e4\u00e4ratud aja jooksul andmeid kustutada ning andmebaasi j\u00e4id vanad andmed. Housekeeperi t\u00f6\u00f6 ajal oli Zabbix Serveril suurenenud koormus, mis v\u00f5is kesta pikka aega. \u00dcks asi oli selge: olukorda tuli kuidagi lahendada.<\/p>\n

See on tuntud probleem, millega silmitsi seisavad praktiliselt k\u00f5ik, kes on t\u00f6\u00f6tanud Zabbixiga suurte j\u00e4lgimismahtudega. Lahendusi on olnud mitmeid: n\u00e4iteks MySQL asendamine PostgreSQL-iga v\u00f5i isegi Elasticsearchiga, kuid k\u00f5ige lihtsam ja t\u00f5estatud lahendus oli minna \u00fcle tabelite partitsioneerimisele, kus hoitakse m\u00f5\u00f5dikute andmeid MySQL andmebaasis. Me otsustasime valida just selle tee.<\/p>\n

\u00dcleminek tavalistelt MySQL tabelitelt partitsioneeritud tabelitele<\/h3>\n

\nZabbix on h\u00e4sti dokumenteeritud ja tabelid, kus ta hoiab m\u00f5\u00f5dikuid on teada. Need tabelid on: history<\/code>, kus hoitakse float v\u00e4\u00e4rtusi, history_str<\/code>, kus hoitakse l\u00fchikesi stringi v\u00e4\u00e4rtusi, history_text<\/code>, kus hoitakse pikki tekstiv\u00e4\u00e4rtusi ja history_uint<\/code>, kus hoitakse t\u00e4isarvulisi v\u00e4\u00e4rtusi. On veel tabel trends<\/code>, mis hoiab muutuste d\u00fcnaamikat, kuid seda me ei puutu, kuna selle suurus on v\u00e4ike ja hiljem tagasi j\u00f5uame selle juurde.<\/p>\n

\u00dcldiselt oli selge, millised tabelid tuleb t\u00f6\u00f6delda. Otsustasime luua partitioone iga n\u00e4dala kohta, v\u00e4lja arvatud viimane, kuu numbrite p\u00f5hjal, st neli partitiooni kuus: 1.\u20137., 8.\u201314., 15.\u201321. ja 22.\u20131. (j\u00e4rgmisel kuul). Raskuseks oli see, et meie vajalikud tabelid tuli \u201elennult\u201d muuta partiitioneeritud tabeliteks, katkestamata Zabbix Serveri t\u00f6\u00f6d ja meetrite kogumist.<\/p>\n

Kuidas iganes, aitas meid sellel andmetabelite struktuur. N\u00e4iteks tabel history <\/code>omab j\u00e4rgmist struktuuri:<\/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
\nsamas<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nKuidas n\u00e4eme, iga m\u00f5\u00f5dik kantakse l\u00f5puks tabelisse, kus on kaks v\u00e4ga olulist ja mugavat meile v\u00e4ljaannet itemid<\/b> ja clock<\/b>. Nii et me v\u00f5ime t\u00e4iesti luua ajutise tabeli, n\u00e4iteks nimega history_tmp<\/code>, seadistada selle partitioneerimise ja seej\u00e4rel kanda k\u00f5ik andmed tabelist history<\/code>, seej\u00e4rel nimetada tabel history<\/code> \u00fches history_old<\/code>, ja tabel history_tmp<\/code> \u00fches history<\/code>, seej\u00e4rel lisada need andmed, mis meil on lisamata tabelist history_old<\/code> \u00fches history <\/code>ja kustutada. history_old<\/code>. Seda saab teha t\u00e4iesti ohutult, me ei kaota midagi, kuna \u00fclaltoodud v\u00e4ljad itemid <\/b>ja clock <\/b>tagavad konkreetse m\u00f5\u00f5diku sidumise kindlat aega, mitte mingi j\u00e4rjestusnumbriga.<\/p>\n
Kogu \u00fclemineku protseduur<\/h3>\n
<\/p>\n
T\u00e4helepanu! Enne meetmete alustamist on soovitatav teha t\u00e4ielik varukoopia andmebaasist. Me k\u00f5ik oleme inimesed ja v\u00f5ime teha k\u00e4suviibaga vigu, mis v\u00f5ivad viia andmete kadumiseni. Jah, varukoopia ei paku maksimaalset ajakohasust, kuid parem on omada sellist kui mitte \u00fchtegi.<\/p><\/blockquote>\n
 Seega ei l\u00fclita me midagi v\u00e4lja ega peata. Peamine on see, et MySQL-serveris oleks piisavalt vabakohta kettal, t. e. et iga \u00fclalnimetatud tabeli jaoks history<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, oleks v\u00e4hemalt piisavalt ruumi loomise jaoks tabeli, millel on sufiks \u201e_tmp\u201d, arvestades, et see on sama suur nagu algne tabel.<\/p>\n
Me ei hakka kirjeldama k\u00f5ike mitu korda iga \u00fclaltoodud tabeli jaoks ja vaatame k\u00f5ike ainult \u00fche nende n\u00e4itel \u2014 tabeli history<\/code>.<\/p>\n
Nii et loome t\u00fchja tabeli history_tmp <\/code>tabeli struktuuri p\u00f5hjal history<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nLoome vajalikud jaotised. N\u00e4iteks teeme seda \u00fcheks kuuks. Iga jaotis luuakse partitsioneerimisreegli alusel, mis p\u00f5hineb v\u00e4li v\u00e4\u00e4rtusel clock<\/b>, mida me v\u00f5rreldame ajatempli:<\/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
\nSee k\u00e4sk lisab partitsioneerimise meie loodud tabelile history_tmp<\/code>. T\u00e4psustame, et andmed, mille v\u00e4\u00e4rtus on clock <\/b>v\u00e4hem kui \"2019-02-01 00:00:00\", l\u00e4hevad jaotisesse p20190201<\/i>, seej\u00e4rel andmed, mille v\u00e4\u00e4rtus on clock<\/b> rohkem kui \"2019-02-01 00:00:00\", kuid v\u00e4hem kui \"2019-02-07 00:00:00\", l\u00e4hevad jaotisesse p20190207 <\/i>ja nii edasi.<\/p>\n
Oluline m\u00e4rkus:<\/b> Entak kui meil on partitsioneeritud tabelis andmeid, mille kellaaeg on suurem v\u00f5i v\u00f5rdne \"2019-03-01 00:00:00\"? Kuna nendele andmetele ei ole sobivat partitsiooni, ei p\u00e4\u00e4se need tabelisse ja kaovad. Seet\u00f5ttu peate meeles pidama, et luua \u00f5igeaegselt t\u00e4iendavaid partitsioone, et v\u00e4ltida selliseid andmekao olukordi (millest r\u00e4\u00e4gime allpool).<\/p><\/blockquote>\n
 Nii et ajutine tabel on ette valmistatud. Laeme andmeid. Protsess v\u00f5ib v\u00f5tta \u00fcsna kaua aega, kuid \u00f5nneks see ei blokeeri mingeid teisi p\u00e4ringuid, nii et lihtsalt peame olema kannatlikud:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nS\u00f5na IGNORE algses laadimises ei ole vajalik, kuna tabelis andmeid ei ole, kuid see on vajalik andmete j\u00e4rkj\u00e4rguliseks lisamiseks. Lisaks v\u00f5ib see osutuda kasulikuks, kui laadimise ajal tuleb protsess peatada ja uuesti alustada.<\/p>\n
Nii et mingi aja p\u00e4rast (v\u00f5ib-olla isegi mitu tundi) on esimene andmete laadimine toimunud. Nagu te aru saate, sisaldab tabel n\u00fc\u00fcd history_tmp <\/code>k\u00f5iki andmeid tabelist history<\/code>, vaid need, mis olid selles hetkeks, kui p\u00e4ring hakkas toimuma. Siin on teil tegelikult valik: kas me teeme veel \u00fche k\u00e4igu (kui laadimisprotsess kestis kaua) v\u00f5i liigume kohe tabelite nimetamise juurde, millest eespool r\u00e4\u00e4giti. Alustame esimese rohkema k\u00e4igu m\u00e4\u00e4ramisega. Esiteks peame m\u00f5istma viimase sisestatud kirje kella aega history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nEeldame, et olete saanud: 1551045645<\/b>. N\u00fc\u00fcd kasutame saadud v\u00e4\u00e4rtust teise k\u00e4igu andmete laadimiseks:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nSee k\u00e4ik peaks l\u00f5ppema m\u00e4rgatavalt kiiremini. Kuid kui esimene k\u00e4ik kestis tunde ja teine samuti kaua, v\u00f5ib osutuda \u00f5igeks teha ka kolmas k\u00e4ik, mis toimub t\u00e4pselt nii nagu teine.<\/p>\n
L\u00f5pus teeme taas operatsiooni, et saada viimase sisestuse kellaaega history_tmp<\/code>, tehes:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nEeldame, et olete saanud 1551085645<\/b>. Salvestage see v\u00e4\u00e4rtus \u2014 see on meile vajalik laadimise ajal.<\/p>\n
Ja n\u00fc\u00fcd, kui esialgne andmete laadimine history_tmp <\/code>on l\u00f5ppenud, liigume tabelite nimetamise juurde:<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nMe oleme selle ploki korraldanud kui \u00fche tehingu, et v\u00e4ltida andmete sisestamise momenti mitteeksisteerivasse tabelisse, sest p\u00e4rast esimest RENAME'i kuni teise RENAME'i t\u00e4itmiseni tabel history <\/code>ei saa eksisteerida. Aga isegi kui RENAME\u2019i operatsioonide vahel tabelisse history <\/code>tulevad mingid andmed, ja tabelit endal veel ei ole (t\u00e4nu \u00fcmbernimetamisele), saame v\u00e4ikese hulga sisestusvigu, mille v\u00f5ib ignoreerida (meil on j\u00e4lgimine, mitte pank).<\/p>\n
N\u00fc\u00fcd on meil uus tabel history<\/code> partitsioneerimisega, kuid sellest puuduvad andmed, mis saadi viimase andmete sisestamise k\u00e4igus tabelisse history_tmp<\/code>. Kuid need andmed on meil tabelis history_old <\/code>ja me t\u00e4iendame neid sealt praegu. Selleks vajame varasemat salvestatud v\u00e4\u00e4rtust 1551085645. Miks me selle v\u00e4\u00e4rtuse salvestasime, mitte ei kasutanud suurimat sisestamise aega juba olemasolevast tabelist 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
\nP\u00e4rast selle operatsiooni l\u00f5ppu on meil uues, partitsioneeritud tabelis history <\/code>k\u00f5ik andmed, mis olid vanas, pluss need, mis on juba tulnud p\u00e4rast tabeli \u00fcmbernimetamist. Tabel history_old <\/code>me ei vajata enam. Saate selle kohe kustutada, v\u00f5i saate enne kustutamist teha sellest varukoopia (kui olete mures).<\/p>\n
\u00dclaltoodud protsess tuleb korduda tabelite jaoks. history_str<\/code>, history_text <\/code>ja history_uint<\/code>.<\/p>\n
Mida tuleks Zabbix Serveri seadistustes muuta?<\/h3>\n
\nN\u00fc\u00fcd lasub andmebaasi hooldus meie \u00f5lgadel seoses andmete ajalooga. See t\u00e4hendab, et Zabbix ei pea enam vanu andmeid kustutama \u2014 sellega tegeleme n\u00fc\u00fcd ise. Et Zabbix Server ei prooviks andmeid ise puhastada, peate sisenema Zabbix veebiliidesesse, valima men\u00fc\u00fcst 'Administratsioon', seej\u00e4rel alammen\u00fc\u00fcst '\u00dcldine', ja seej\u00e4rel paremas rippmen\u00fc\u00fcs valima 'Ajaloo puhastamine'. Ilmuvanel lehel tuleb t\u00fchistada k\u00f5ik ruudud r\u00fchmas 'Ajalugu' ja vajutada nuppu 'Uuenda'. See takistab meil mittevajalikku tabelite puhastamist. history*<\/code> housekeeperi kaudu.<\/p>\n
Pange t\u00e4hele, et samal lehel r\u00fchmas 'Muutuste d\u00fcnaamika'. See on see tabel trends<\/code>, mille juurde me lubasime tagasi tulla. Kui see on samuti liiga suur ja vajab jagamist, t\u00fchjendage ka selles grupis ruudud ja seej\u00e4rel t\u00f6\u00f6tlege seda tabelit t\u00e4pselt samamoodi nagu tehti tabelitega. history*<\/code>.<\/p>\n
Andmete baasi edasine hooldus<\/h3>\n
\nNagu varem mainitud, on partitseeritud tabelite normaalseks toimimiseks vajalik partitsioonide \u00f5igeaegne loomine. Seda saab teha j\u00e4rgmiselt:<\/p>\n
ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\nLisaks on meie \u00fclesanne eemaldada vanad andmed, kuna oleme loonud partitseeritud tabelid ja keelanud Zabbix Server'il neid puhastada. \u00d5nneks ei ole siin mingeid probleeme. See toimub lihtsalt partitsiooni kustutamisega, mille andmed pole enam vajalikud. <\/p>\n
N\u00e4iteks:<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nErinevalt DATE RANGE m\u00e4\u00e4ratlemisega DELETE FROM k\u00e4skudest, t\u00f6\u00f6tab DROP PARTITION paari sekundi jooksul, koormates t\u00e4iesti minimaalselt. server<\/a> See t\u00f6\u00f6tab sama probleemivabalt ka MySQL replikatsiooni kasutamisel.<\/p>\n
Kokkuv\u00f5te<\/h3>\n
\nKirjeldatud lahendus on aja jooksul t\u00f5estatud. Andmemaht kasvab, kuid mingit m\u00e4rkimisv\u00e4\u00e4rset j\u00f5udluse aeglustumist ei t\u00e4heldata.
\n
Allikas: 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\udd47Partitsioneerimise kasutamine MySQL-is Zabbixi jaoks suure arvu j\u00e4lgitavate objektide korral | ProHoster","description":"Serverite ja teenuste j\u00e4lgimiseks oleme pikka aega ja endiselt edukalt kasutanud Nagiosel ja Muninil p\u00f5hinevat kombineeritud lahendust. Siiski on sellel lahendusel mitmeid puudusi, seega, nagu paljud, kasutame aktiivselt Zabbixit. Selles artiklis r\u00e4\u00e4gime, kuidas minimaalsete pingutustega lahendada j\u00f5udlusprobleem, kui suureneb j\u00e4lgitavate m\u00f5\u00f5dikute arv ja","canonical_url":"https:\/\/prohoster.info\/et\/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":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 MySQL \u0434\u043b\u044f Zabbix \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u043e\u0431\u044a\u0435\u043a\u0442\u043e\u0432 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 | ProHoster","og:description":"\u0414\u043b\u044f \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438 \u0441\u043b\u0443\u0436\u0431 \u0443 \u043d\u0430\u0441 \u0434\u0430\u0432\u043d\u043e, \u0438 \u0432\u0441\u0435 \u0435\u0449\u0435 \u0443\u0441\u043f\u0435\u0448\u043d\u043e, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u043a\u043e\u043c\u0431\u0438\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u043d\u0430 \u0431\u0430\u0437\u0435 Nagios \u0438 Munin. \u041e\u0434\u043d\u0430\u043a\u043e \u044d\u0442\u0430 \u0441\u0432\u044f\u0437\u043a\u0430 \u0438\u043c\u0435\u0435\u0442 \u0440\u044f\u0434 \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043a\u043e\u0432, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u044b, \u043a\u0430\u043a \u0438 \u043c\u043d\u043e\u0433\u0438\u0435, \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0438\u0440\u0443\u0435\u043c Zabbix. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u0438\u043d\u0438\u043c\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u0443\u0441\u0438\u043b\u0438\u044f\u043c\u0438 \u043c\u043e\u0436\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0441 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c\u044e \u043f\u0440\u0438 \u0443\u0432\u0435\u043b\u0438\u0447\u0435\u043d\u0438\u0438 \u0447\u0438\u0441\u043b\u0430 \u0441\u043d\u0438\u043c\u0430\u0435\u043c\u044b\u0445 \u043c\u0435\u0442\u0440\u0438\u043a \u0438","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-12-13T21:00:00+00:00","article:modified_time":"2020-02-18T11:01:55+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53966","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 09:31:21","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:14:29","updated":"2026-01-24 09:31:21"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/53966","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=53966"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/53966\/revisions"}],"predecessor-version":[{"id":172868,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/53966\/revisions\/172868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=53966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=53966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=53966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}