{"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 partitsioneerimise kasutamine Zabbixis, milles on palju 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 p\u00f5hist kombineeritud lahendust. Siiski on sellel paar puudust, mist\u00f5ttu kasutame aktiivselt, nagu paljusid teisedki, Zabbix<\/a><\/noindex>. Selles artiklis r\u00e4\u00e4gime, kuidas minimaalse vaeva korral saab lahendada tulemuslikkuse probleemi, kui j\u00e4lgitavate m\u00f5\u00f5dikute arv ja MySQL andmebaasi mahud suurenevad.
\n<\/a><\/noindex><\/p>\n

Probleemid MySQL andmebaasi kasutamisega koos Zabbixiga<\/h3>\n

\nKuni andmebaas oli v\u00e4ike ja seal salvestatud m\u00f5\u00f5dikute arv oli v\u00e4ike, oli k\u00f5ik suurep\u00e4rane. Zabbixi serveri automaatne protsess housekeeper kustutas edukalt aegunud kirjed andmebaasist, takistades selle kasvamist. Kuid niipea, kui j\u00e4lgitavate m\u00f5\u00f5dikute arv kasvas ja andmebaasi maht saavutas teatud suuruse, hakkasid asjad halvenema. Housekeeper ei suutnud andmeid etten\u00e4htud ajaraami jooksul eemaldada ja andmebaasi j\u00e4id vanad andmed. Housekeeperi t\u00f6\u00f6 ajal tekkis Zabbixi serverile suur koormus, mis v\u00f5is kesta kaua. Selgeks sai, et olukorda tuleb kuidagi lahendada.<\/p>\n

See on tuntud probleem, millega on silmitsi seisnud praktiliselt iga\u00fcks, kes on t\u00f6\u00f6tanud Zabbixi peal suurte j\u00e4lgimismahtudega. Lahendusi oli paar: n\u00e4iteks MySQL asendamine PostgreSQL v\u00f5i isegi Elasticsearchiga, kuid k\u00f5ige lihtsam ja proovitud lahendus oli \u00fcleminek partitiseeritud tabelitele, mis salvestavad m\u00f5\u00f5dikute andmed MySQL andmebaasis. Otsustasime minna just selle tee.<\/p>\n

\u00dcleminek tavalistest MySQL tabelitest partitiseeritud tabelitele<\/h3>\n

\nZabbix on korralikult dokumenteeritud ja tabelid, kus ta s\u00e4ilitab m\u00f5\u00f5dikud, on teada. Need tabelid on: konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud.<\/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\u00e4isarve. On olemas ka tabel trends<\/code>, mis salvestab muutuste d\u00fcnaamikat, kuid me otsustasime seda mitte puutuda, kuna selle suurus on v\u00e4ike ja hiljem tuleme selle juurde tagasi.<\/p>\n

\u00dcldiselt oli selge, millised tabelid tuleb t\u00f6\u00f6delda. Otsustasime teha jaotisi iga n\u00e4dala jaoks, v\u00e4lja arvatud viimane, p\u00f5hinedes kuu numbritel, st neli jaotust kuus: 1. kuni 7., 8. kuni 14., 15. kuni 21. ja 22. kuni 1. (j\u00e4rgmisel kuul). Raskuseks oli see, et vajalikud tabelid tuli muuta jaotistesse \"lennu ajal\", katkestamata Zabbix Serveri t\u00f6\u00f6d ja andmete kogumist.<\/p>\n

Kuidas imekombel, tuli meile appi tabelite andmestruktuur. N\u00e4iteks tabel konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud. <\/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
\nsamal ajal<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nNagu n\u00e4eme, kantakse iga meetrika l\u00f5puks tabelisse, milles on kaks meie jaoks v\u00e4ga olulist ja mugavat v\u00e4lja itemid<\/b> ja clock<\/b>. Seega saame \u00fcsna h\u00f5lpsalt luua ajutise tabeli, n\u00e4iteks nimega history_tmp<\/code>, seadistada selle jaoks jaotuse ja seej\u00e4rel kanda k\u00f5ik andmed tabelist konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud.<\/code>, seej\u00e4rel nimetada tabel konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud.<\/code> ja history_old<\/code>, ja tabel history_tmp<\/code> ja konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud.<\/code>, p\u00e4rast mida saame lisada andmed, mis meil j\u00e4i kantamata tabelist history_old<\/code> ja konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud. <\/code>ja kustutada history_old<\/code>. Seda saab teha t\u00e4iesti ohutult, me ei kaota mitte midagi, sest \u00fclaltoodud v\u00e4ljad itemid <\/b>ja clock <\/b>tagavad konkreetse meetrika sidumise konkreetse ajaga, mitte mingi j\u00e4rjestikuse numbriga.<\/p>\n
\u00dclemineku protseduur<\/h3>\n
<\/p>\n
T\u00e4helepanu! V\u00e4ga soovitatav on enne mingite tegevuste alustamist teha andmebaasi t\u00e4ielik varukoopia. Me k\u00f5ik oleme elavad inimesed ja v\u00f5ime teha k\u00e4sureas vigu, mis v\u00f5ivad viia andmete kadumiseni. Jah, varukoopia ei garanteeri maksimaalset ajakohasust, kuid parem on see kui mitte midagi.<\/p><\/blockquote>\n
 Nii et, me ei l\u00fclita midagi v\u00e4lja ega peata. Peamine on, et MySQL serveris oleks piisavalt vaba ketta ruumi, st et iga \u00fclaltoodud tabeli jaoks konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud.<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, oleks v\u00e4hemalt piisavalt ruumi tabeli loomiseks, mille sufiks on \"_tmp\", arvestades, et selle maht on sama kui algse tabeli maht.<\/p>\n
Me ei kirjuta k\u00f5ike mitmeid kordi iga \u00fclaltoodud tabeli jaoks ja vaatame k\u00f5ike vaid \u00fche n\u00e4ite p\u00f5hjal \u2014 tabeli konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud.<\/code>.<\/p>\n
Nii et, loome t\u00fchja tabeli history_tmp <\/code>tabeli struktuuri p\u00f5hjal konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud.<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nLoome vajalikud partitsioonid. N\u00e4iteks teeme seda kuuks ajaks. Iga partitsioon luuakse partitsioneerimise reegli alusel, mis p\u00f5hineb v\u00e4lja v\u00e4\u00e4rtusel clock<\/b>, mida me v\u00f5rreldame ajatempli puhul:<\/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\u00e4lja v\u00e4\u00e4rtus clock <\/b>on v\u00e4iksem kui \u00ab2019-02-01 00:00:00\u00bb, satuvad partitsiooni p20190201<\/i>, seej\u00e4rel andmed, mille v\u00e4lja v\u00e4\u00e4rtus clock<\/b> on suurem kui \u00ab2019-02-01 00:00:00\u00bb, aga v\u00e4iksem kui \u00ab2019-02-07 00:00:00\u00bb, satuvad partitsiooni p20190207 <\/i>ja nii edasi.<\/p>\n
Oluline m\u00e4rkus:<\/b> Mis juhtub, kui meie partitsioneeritud tabelis ilmnevad andmed, mille v\u00e4lja v\u00e4\u00e4rtus clock on suurem v\u00f5i v\u00f5rdne \u00ab2019-03-01 00:00:00\u00bb? Kuna nendele andmetele ei ole sobivat partitsiooni, ei satu need tabelisse ja kaovad. Seet\u00f5ttu peate meeles pidama, et luua \u00f5igeaegselt t\u00e4iendavaid partitsioone, et v\u00e4ltida selliste andmete kadumist (millest r\u00e4\u00e4gitakse allpool).<\/p><\/blockquote>\n
 Nii, ajutine tabel on valmis. Laeme andmed \u00fcles. Protsess v\u00f5ib v\u00f5tta \u00fcsna kaua aega, kuid \u00f5nneks ei blokeeri see muid p\u00e4ringuid, seega peab lihtsalt kannatust varuma:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nP\u00f6\u00f6rdv\u00f5ti IGNORE ei ole algses laadimises kohustuslik, kuna tabelis andmeid ei ole, kuid see on vajalik andmete t\u00e4iendavaks laadimiseks. Samuti v\u00f5ib see osutuda kasulikuks, kui pidite andmete laadimise protsessi katki j\u00e4tma ja uuesti alustama.<\/p>\n
Seega, p\u00e4rast teatud aega (v\u00f5ib-olla isegi mitu tundi) on esimene andmete laadimine toimunud. Nagu arvata v\u00f5ib, sisaldab n\u00fc\u00fcd tabel history_tmp <\/code>mitte k\u00f5iki andmeid tabelist konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud.<\/code>, vaid ainult neid, mis olid selles hetkel, kui p\u00e4ring hakkas toimuma. Siin on teil valik: kas teha veel \u00fcks voor (kui laadimisprotsess kestis kaua), v\u00f5i minna kohe tabelite \u00fcmbernimetamise juurde, millest allpool r\u00e4\u00e4giti. R\u00e4\u00e4gime esmalt teisest voorust. Esiteks peame m\u00f5istma viimase sisestatud salvestuse aega history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nOletame, et saite: 1551045645<\/b>. N\u00fc\u00fcd kasutame saadud v\u00e4\u00e4rtust teisel andmete laadimise l\u00e4bimisel:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nSee l\u00e4bimine peaks l\u00f5ppema oluliselt kiiremini. Kuid kui esimene l\u00e4bimine kestis tunde, ja teine \u200b\u200bkestab samuti kaua, v\u00f5ib osutuda \u00f5igeks teha ka kolmas l\u00e4bimine, mis toimub t\u00e4iesti sarnaselt teisele.<\/p>\n
L\u00f5pus teeme j\u00e4lle operatsiooni viimase sisestamise aega saamiseks history_tmp<\/code>, tehes:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nOletame, et olete saanud 1551085645<\/b>. Salvestage see v\u00e4\u00e4rtus \u2014 see on meile vajalik doseerimiseks.<\/p>\n
Ja n\u00fc\u00fcd, kui esmane andmete laadimine history_tmp <\/code>on l\u00f5ppenud, alustame tabelite \u00fcmbernimetamisega:<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nOleme vormistanud selle ploki \u00fche tehinguna, et v\u00e4ltida andmete sisestamise hetke mittet\u00e4ielikku tabelisse, sest p\u00e4rast esimest RENAME'i ja enne teise RENAME'i t\u00e4itmist, tabel konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud. <\/code>ei eksisteeri. Kuid isegi kui RENAME'i operatsioonide vahel saadakse m\u00f5ningaid andmeid, ja tabelit endiselt ei ole (\u00fcleskutse t\u00f5ttu), saame me v\u00e4ikse hulga sisestamisvigu, millega saab ignoreerida (meil on j\u00e4lgimine, mitte pank). konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud. <\/code>N\u00fc\u00fcd on meil uus tabel<\/p>\n
partitsioneerimisega, kuid selles puuduvad andmed, mis saadi viimase andmete sisestamise k\u00e4igus tabelisse konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud.<\/code> . Kuid need andmed on meil tabelis history_tmp<\/code>ja me t\u00e4iendame need sealt. Selleks vajame eelnevalt salvestatud v\u00e4\u00e4rtust 1551085645. Miks me selle v\u00e4\u00e4rtuse salvestasime, mitte kasutasime maksimaalset laadimisaega juba praegusest tabelist history_old <\/code>INSERT IGNORE INTO `history` SELECT * FROM history_old WHERE clock>=1551045645; konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud.<\/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
P\u00e4rast selle operatsiooni l\u00f5ppemist on meil uues, partitsioneeritud tabelis<\/code><\/pre>\n
\nk\u00f5ik andmed, mis olid vanas, pluss need, mis saabusid p\u00e4rast tabeli \u00fcmbernimetamist. Tabel konsolis, saate nimekirja k\u00e4skudest, mis on varem teie kontoga t\u00e4idetud. <\/code>ei ole meile enam vajalik. Saame selle kohe kustutada v\u00f5i enne kustutamist teha sellest varukoopia (kui teil on paranoia). history_old <\/code>Kogu \u00fclaltoodud protsess tuleb korrata tabelite jaoks<\/p>\n
Mida on vaja Zabbix Serveri seadetes parandada. history_str<\/code>, history_text <\/code>ja 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
\nN\u00fc\u00fcd langeb andmebaasi hooldus, sealhulgas andmeajaloo osas, meie \u00f5lgadele. See t\u00e4hendab, et Zabbix ei pea enam vanu andmeid kustutama \u2014 me tegeleme sellega ise. Selleks, et Zabbix Server ei p\u00fc\u00fcaks andmeid ise puhastada, peate minema Zabbixi veebiliidesesse, valima men\u00fc\u00fcs 'Haldus', seej\u00e4rel alammen\u00fc\u00fcs '\u00dcldine' ning seej\u00e4rel paremal v\u00e4ljal allalaadimise nimekirjas valima 'Ajaloo puhastus'. Ilmuvatel lehtedel peate eemaldama k\u00f5ik m\u00e4rgised r\u00fchmas 'Ajaloos' ja vajutama nuppu 'Ainult'. See takistab meil edasist vajadust tabelite puhastamise j\u00e4rele. ajalugu*<\/code> koos housekeeperiga.<\/p>\n
Pange t\u00e4hele, et sama lehe peal on r\u00fchm 'Muutuste d\u00fcnaamika'. See on just see tabel, trends<\/code>, mille juurde me lubasime tagasi p\u00f6\u00f6rduda. Kui sellel on liiga palju andmeid ja see vajab partitsioneerimist, eemaldage m\u00e4rgised ka sellest r\u00fchmast, ja siis t\u00f6\u00f6tlege seda tabelit t\u00e4pselt samamoodi nagu eelnevalt tabelite puhul. ajalugu*<\/code>.<\/p>\n
Edasine andmebaasi hooldamine<\/h3>\n
\nNagu varem \u00f6eldud, on partitsioneeritud tabelitel n\u00f5uetekohaseks t\u00f6\u00f6ks 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, kuna oleme loonud partitsioneeritud tabelid ja keelanud Zabbix Serveril neid puhastada, on vanade andmete kustutamine n\u00fc\u00fcd meie mure. \u00d5nneks ei ole siin mingeid probleeme. See toimub lihtsalt partitsiooni kustutamisega, mille andmed me enam ei vaja. <\/p>\n
N\u00e4iteks:<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nErinevalt DELETE FROM operaatoritest, kus on m\u00e4\u00e4ratud kuup\u00e4evavahemik, t\u00e4idetakse DROP PARTITION paari sekundi jooksul ja ei tekita \u00fchtegi koormust, server<\/a> ja t\u00f6\u00f6tab probleemideta ka juhul, kui kasutatakse MySQL replikatsiooni.<\/p>\n
Kokkuv\u00f5te<\/h3>\n
\nKirjeldatud lahendus on aja jooksul t\u00f5estatud. Andmemaht kasvab, kuid m\u00e4rkimisv\u00e4\u00e4rset j\u00f5udluse langust ei ole t\u00e4heldatud.
\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\udd47MySQL partitsioneerimise kasutamine Zabbixis suure hulga j\u00e4lgitavate objektide jaoks | ProHoster","description":"Serverite ja teenuste j\u00e4lgimiseks oleme juba ammu ja j\u00e4tkuvalt edukalt kasutanud Nagios ja Munin p\u00f5hist kombineeritud lahendust.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}