{"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\/hu\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","title":{"rendered":"Particion\u00e1l\u00e1s haszn\u00e1lata MySQL-ben Zabbix sz\u00e1m\u00e1ra nagy sz\u00e1m\u00fa monitoroz\u00e1si objektummal","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A szerverek \u00e9s szolg\u00e1ltat\u00e1sok monitoroz\u00e1s\u00e1hoz m\u00e1r r\u00e9g\u00f3ta, \u00e9s tov\u00e1bbra is sikeresen, egy kombin\u00e1lt megold\u00e1st haszn\u00e1lunk, amely a Nagiosra \u00e9s a Muninra \u00e9p\u00fcl. Ez a p\u00e1ros azonban sz\u00e1mos h\u00e1tr\u00e1nnyal j\u00e1r, ez\u00e9rt mi, mint sokan m\u00e1sok, akt\u00edvan kihaszn\u00e1ljuk Zabbix<\/a><\/noindex>. Ebben a cikkben arr\u00f3l fogunk besz\u00e9lni, hogy minim\u00e1lis er\u0151fesz\u00edt\u00e9sek \u00e1r\u00e1n hogyan lehet megoldani a teljes\u00edtm\u00e9nnyel kapcsolatos probl\u00e9m\u00e1kat a m\u00e9rt metrik\u00e1k sz\u00e1m\u00e1nak n\u00f6veked\u00e9s\u00e9vel \u00e9s a MySQL adatb\u00e1zis m\u00e9ret\u00e9nek n\u00f6veked\u00e9s\u00e9vel.
\n<\/a><\/noindex><\/p>\n

A MySQL adatb\u00e1zis Zabbixszal val\u00f3 haszn\u00e1lat\u00e1nak probl\u00e9m\u00e1i<\/h3>\n

\nAm\u00edg az adatb\u00e1zis kicsi volt \u00e9s a benne t\u00e1rolt metrik\u00e1k sz\u00e1ma is alacsony, minden csod\u00e1latosan m\u0171k\u00f6d\u00f6tt. A Zabbix Server \u00e1ltal futtatott housekeeper \u00fctemezett folyamat sikeresen t\u00f6r\u00f6lte az elavult rekordokat az adatb\u00e1zisb\u00f3l, megakad\u00e1lyozva annak n\u00f6veked\u00e9s\u00e9t. Azonban, ahogy a m\u00e9rt metrik\u00e1k sz\u00e1ma megn\u0151tt, \u00e9s az adatb\u00e1zis el\u00e9rte egy bizonyos m\u00e9retet, a helyzet romlani kezdett. A housekeeper nem tudta id\u0151ben t\u00f6r\u00f6lni az adatokat, \u00e9s az adatb\u00e1zisban r\u00e9gi adatok maradtak. A housekeeper m\u0171k\u00f6d\u00e9se alatt megn\u00f6vekedett terhel\u00e9s nehezedett a Zabbix Serverre, ami hosszabb ideig is eltartott. Nyilv\u00e1nval\u00f3v\u00e1 v\u00e1lt, hogy valamilyen m\u00f3don meg kell oldani a kialakult helyzetet.<\/p>\n

Ez egy \u00e1ltal\u00e1nosan ismert probl\u00e9ma, szinte mindenki, aki nagy mennyis\u00e9g\u0171 Zabbix monitoroz\u00e1ssal foglalkozott, ugyanezzel a helyzettel szembes\u00fclt. Sz\u00e1mos megold\u00e1s l\u00e9tezett: p\u00e9ld\u00e1ul a MySQL PostgreSQL-re vagy ak\u00e1r Elasticsearch-ra val\u00f3 cser\u00e9l\u00e9se, de a legegyszer\u0171bb \u00e9s legjobban bev\u00e1lt megold\u00e1s a MySQL adatb\u00e1zisban a metrik\u00e1kat t\u00e1rol\u00f3 t\u00e1bl\u00e1k particion\u00e1l\u00e1s\u00e1ra val\u00f3 \u00e1t\u00e1ll\u00e1s volt. Mi is \u00e9ppen ezen az \u00faton indultunk el.<\/p>\n

\u00c1t\u00e1ll\u00e1s a hagyom\u00e1nyos MySQL t\u00e1bl\u00e1kr\u00f3l a particion\u00e1ltakra<\/h3>\n

\nA Zabbix j\u00f3l dokument\u00e1lt, \u00e9s ismertek azok a t\u00e1bl\u00e1k, ahol a metrik\u00e1kat t\u00e1rolja. Ezek a t\u00e1bl\u00e1k: history<\/code>, ahol a float \u00e9rt\u00e9keket t\u00e1rolj\u00e1k, history_str<\/code>, ahol a r\u00f6vid sz\u00f6veges \u00e9rt\u00e9kek tal\u00e1lhat\u00f3k, history_text<\/code>, ahol a hossz\u00fa sz\u00f6veges \u00e9rt\u00e9kek tal\u00e1lhat\u00f3k, \u00e9s history_uint<\/code>, ahol az eg\u00e9sz sz\u00e1m\u00fa \u00e9rt\u00e9keket t\u00e1rolj\u00e1k. Van m\u00e9g egy t\u00e1bla, trends<\/code>, amely a v\u00e1ltoz\u00e1sok dinamik\u00e1j\u00e1t t\u00e1rolja, de azt nem \u00e9rintett\u00fck, mert a m\u00e9rete kicsi, \u00e9s k\u00e9s\u0151bb visszat\u00e9r\u00fcnk r\u00e1.<\/p>\n

\u00d6sszess\u00e9g\u00e9ben vil\u00e1gos volt, hogy mely t\u00e1bl\u00e1kat kell feldolgozni. Azt d\u00f6nt\u00f6tt\u00fck el, hogy hetente indik\u00e1tumokat k\u00e9sz\u00edt\u00fcnk, kiv\u00e9ve az utols\u00f3t, a h\u00f3nap sz\u00e1mai alapj\u00e1n, teh\u00e1t n\u00e9gy indik\u00e1ci\u00f3 havonta: az 1-t\u0151l a 7-ig, a 8-t\u00f3l a 14-ig, a 15-t\u0151l a 21-ig \u00e9s a 22-t\u0151l az (k\u00f6vetkez\u0151 h\u00f3nap) 1-ig. A neh\u00e9zs\u00e9g abban rejlik, hogy a sz\u00fcks\u00e9ges t\u00e1bl\u00e1kat<\/p>\n

meglep\u0151 m\u00f3don, maguk a t\u00e1bl\u00e1k adatszerkezete seg\u00edtett nek\u00fcnk. P\u00e9ld\u00e1ul a t\u00e1bl\u00e1zat history <\/code>a k\u00f6vetkez\u0151 szerkezettel rendelkezik:<\/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
\nezek mellett<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nAhogy l\u00e1tjuk, minden metrika v\u00e9g\u00fcl k\u00e9t nagyon fontos \u00e9s sz\u00e1munkra k\u00e9nyelmes mez\u0151be ker\u00fcl a t\u00e1bl\u00e1ba itemid<\/b> \u00e9s clock<\/b>. \u00cdgy teljesen l\u00e9trehozhatunk egy ideiglenes t\u00e1bl\u00e1t, p\u00e9ld\u00e1ul a nev\u00e9t history_tmp<\/code>, be\u00e1ll\u00edthatjuk a part\u00edcion\u00e1l\u00e1s\u00e1t, majd \u00e1tkonvert\u00e1lhatjuk az \u00f6sszes adatot a t\u00e1bl\u00e1b\u00f3l history<\/code>, ut\u00e1na \u00e1tnevezz\u00fck a t\u00e1bl\u00e1t history<\/code> be. history_old<\/code>, majd a t\u00e1bl\u00e1t history_tmp<\/code> be. history<\/code>, ezut\u00e1n pedig felt\u00f6ltj\u00fck azokat az adatokat, amelyeket nem siker\u00fclt \u00e1tkonvert\u00e1lni a history_old<\/code> be. history <\/code>\u00e9s t\u00f6r\u00f6lj\u00fck history_old<\/code>. Ezt teljesen biztons\u00e1gosan v\u00e9grehajthatjuk, nem vesz\u00edt\u00fcnk semmit, hiszen a fent eml\u00edtett mez\u0151k itemid <\/b>\u00e9s clock <\/b>biztos\u00edtj\u00e1k a konkr\u00e9t metrika adott id\u0151ponthoz val\u00f3 k\u00f6t\u00e9s\u00e9t, nem pedig valamilyen sorsz\u00e1mhoz.<\/p>\n
\u00c1tt\u00e9r\u00e9s menete<\/h3>\n
<\/p>\n
Figyelem! Nagyon aj\u00e1nlott, hogy b\u00e1rmilyen tev\u00e9kenys\u00e9g el\u0151tt k\u00e9sz\u00edts\u00fcnk egy teljes biztons\u00e1gi ment\u00e9st az adatb\u00e1zisb\u00f3l. Mindannyian \u00e9l\u0151 emberek vagyunk, \u00e9s hib\u00e1zhatunk a parancsok bevitel\u00e9n\u00e9l, ami adatveszt\u00e9shez vezethet. Igen, a biztons\u00e1gi m\u00e1solat nem biztos\u00edt maxim\u00e1lis aktualit\u00e1st, de jobb, ha van egy, mint ha nincs.<\/p><\/blockquote>\n
 Teh\u00e1t semmit sem kapcsolunk ki vagy \u00e1ll\u00edtunk le. A legfontosabb, hogy a MySQL szerveren elegend\u0151 szabad lemezter\u00fclet \u00e1lljon rendelkez\u00e9sre, teh\u00e1t minden felsorolt t\u00e1bl\u00e1hoz history<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, legal\u00e1bb elegend\u0151 hely \u00e1lljon rendelkez\u00e9sre egy '_tmp' v\u00e9gz\u0151d\u00e9s\u0171 t\u00e1bla l\u00e9trehoz\u00e1s\u00e1hoz, figyelembe v\u00e9ve, hogy az olyan m\u00e9ret\u0171 lesz, mint az eredeti t\u00e1bla.<\/p>\n
Nem fogunk minden egyes fent eml\u00edtett t\u00e1bl\u00e1t t\u00f6bbsz\u00f6r le\u00edrni, hanem csak egy p\u00e9lda alapj\u00e1n fogjuk megvizsg\u00e1lni - a t\u00e1bl\u00e1t history<\/code>.<\/p>\n
Teh\u00e1t, l\u00e9trehozunk egy \u00fcres t\u00e1bl\u00e1t history_tmp <\/code>a t\u00e1bla strukt\u00far\u00e1ja alapj\u00e1n history<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nMeghat\u00e1rozzuk a sz\u00fcks\u00e9ges part\u00edci\u00f3kat. P\u00e9ld\u00e1ul ezt egy h\u00f3napra fogjuk megtenni. Minden part\u00edci\u00f3 a particion\u00e1l\u00e1si szab\u00e1ly alapj\u00e1n j\u00f6n l\u00e9tre, amely a mez\u0151 \u00e9rt\u00e9k\u00e9n alapul clock<\/b>, amelyet az id\u0151b\u00e9lyeggel \u00f6sszehasonl\u00edtunk:<\/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
\nEz a parancs particion\u00e1l\u00e1st ad hozz\u00e1 az \u00e1ltalunk l\u00e9trehozott t\u00e1bl\u00e1hoz. history_tmp<\/code>Tiszt\u00e1zzuk, hogy azok az adatok, amelyek mez\u0151\u00e9rt\u00e9ke clock <\/b>kisebb mint \u201e2019-02-01 00:00:00\u201d, az p20190201 part\u00edci\u00f3ba fognak ker\u00fclni. p20190201<\/i>, azut\u00e1n azok az adatok, amelyek mez\u0151\u00e9rt\u00e9ke clock<\/b> nagyobb mint \u201e2019-02-01 00:00:00\u201d, de kisebb mint \u201e2019-02-07 00:00:00\u201d, a p20190207 part\u00edci\u00f3ba fognak ker\u00fclni. p20190207 <\/i>\u00e9s \u00edgy tov\u00e1bb.<\/p>\n
Fontos megjegyz\u00e9s:<\/b> Mi fog t\u00f6rt\u00e9nni, ha a particion\u00e1lt t\u00e1bl\u00e1ban olyan adatok jelennek meg, amelynek clock mez\u0151\u00e9rt\u00e9ke nagyobb vagy egyenl\u0151 \u201e2019-03-01 00:00:00\u201d-n\u00e1l? Mivel ezekhez az adatokhoz nincs megfelel\u0151 part\u00edci\u00f3, nem ker\u00fclnek a t\u00e1bl\u00e1ba, \u00e9s elvesznek. Ez\u00e9rt nem szabad elfelejtenie id\u0151ben l\u00e9trehozni tov\u00e1bbi part\u00edci\u00f3kat, hogy elker\u00fclje az ilyen adatveszt\u00e9st (err\u0151l lentebb).<\/p><\/blockquote>\n
 Teh\u00e1t, a ideiglenes t\u00e1bla el\u0151k\u00e9sz\u00edtve. T\u00f6lts\u00fck fel az adatokat. A folyamat el\u00e9g sok\u00e1ig tarthat, de szerencs\u00e9re nem blokkolja semmilyen m\u00e1s lek\u00e9rdez\u00e9st, \u00edgy csak t\u00fcrelemmel kell lennie:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nAz IGNORE kulcssz\u00f3 a kezdeti felt\u00f6lt\u00e9sn\u00e9l nem k\u00f6telez\u0151, hiszen az adatokat a t\u00e1bl\u00e1ban m\u00e9g nem tartalmazza, de sz\u00fcks\u00e9ge lesz r\u00e1 az adatok ut\u00f3lagos felt\u00f6lt\u00e9s\u00e9n\u00e9l. Ezen k\u00edv\u00fcl hasznos lehet, ha az adatok felt\u00f6lt\u00e9se sor\u00e1n meg kellett szak\u00edtania ezt a folyamatot \u00e9s \u00fajra kellett kezdenie.<\/p>\n
Teh\u00e1t, egy id\u0151 eltelt\u00e9vel (lehet, hogy ak\u00e1r t\u00f6bb \u00f3r\u00e1nyi), az els\u0151 adatfelt\u00f6lt\u00e9s megt\u00f6rt\u00e9nt. Ahogy \u00e9rthet\u0151, most a t\u00e1bla history_tmp <\/code>nem tartalmazza az \u00f6sszes adatot a t\u00e1bl\u00e1b\u00f3l, history<\/code>csak azokat, amelyek akkor voltak benne, amikor a lek\u00e9rdez\u00e9s v\u00e9grehajt\u00e1s\u00e1t elkezdt\u00e9k. Itt val\u00f3j\u00e1ban v\u00e1lasztania kell: vagy csin\u00e1lunk egy \u00fajabb \u00e1tj\u00e1r\u00e1st (ha a felt\u00f6lt\u00e9si folyamat hossz\u00fa volt), vagy azonnal \u00e1tt\u00e9r\u00fcnk a t\u00e1blanevek \u00e1tnevez\u00e9s\u00e9re, ahogyan az fentebb eml\u00edtve volt. El\u0151sz\u00f6r n\u00e9zz\u00fck a m\u00e1sodik \u00e1tj\u00e1r\u00e1st. El\u0151sz\u00f6r meg kell \u00e9rten\u00fcnk az utols\u00f3 beillesztett felv\u00e9tel idej\u00e9t history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nTegy\u00fck fel, hogy ezt kaptad: 1551045645<\/b>. Most haszn\u00e1ljuk a m\u00e1sodik adatfelt\u00f6lt\u00e9s sor\u00e1n kapott \u00e9rt\u00e9ket:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nEnnek a folyamatnak jelent\u0151sen gyorsabban kellene v\u00e9get \u00e9rnie. De ha az els\u0151 folyamat \u00f3r\u00e1kig tartott, \u00e9s a m\u00e1sodik is hossz\u00fa id\u0151t vesz ig\u00e9nybe, lehet, hogy \u00e9rdemes lenne egy harmadik folyamatot v\u00e9gezni, amely teljesen hasonl\u00f3an zajlik, mint a m\u00e1sodik.<\/p>\n
A v\u00e9g\u00e9n ism\u00e9t v\u00e9grehajtjuk a legutolj\u00e1ra besz\u00fart bejegyz\u00e9s id\u0151pontj\u00e1nak lek\u00e9rdez\u00e9s\u00e9t history_tmp<\/code>, v\u00e9grehajtva:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nT\u00e9telezz\u00fck fel, hogy megkaptad 1551085645<\/b>. Mentsd el ezt az \u00e9rt\u00e9ket \u2014 sz\u00fcks\u00e9g\u00fcnk lesz r\u00e1 a tov\u00e1bbi felt\u00f6lt\u00e9shez.<\/p>\n
Most pedig, amikor az els\u0151dleges adatfelt\u00f6lt\u00e9s a history_tmp <\/code>befejez\u0151d\u00f6tt, hozz\u00e1fogunk a t\u00e1bl\u00e1k \u00e1tnevez\u00e9s\u00e9hez:<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nEzt a blokkot egy tranzakci\u00f3k\u00e9nt alak\u00edtottuk meg, hogy elker\u00fclj\u00fck, hogy adatok ker\u00fcljenek egy nem l\u00e9tez\u0151 t\u00e1bl\u00e1ba, hiszen az els\u0151 RENAME ut\u00e1n, miel\u0151tt a m\u00e1sodik RENAME v\u00e9grehajt\u00f3dna, a t\u00e1bla history <\/code>nem fog l\u00e9tezni. De m\u00e9g ha a RENAME m\u0171veletek k\u00f6z\u00f6tt b\u00e1rmilyen adat is \u00e9rkezik a t\u00e1bl\u00e1ba, \u00e9s a t\u00e1bla m\u00e9g nem l\u00e9tezik (az \u00e1tnevez\u00e9s miatt), kapunk n\u00e9h\u00e1ny kis besz\u00far\u00e1si hib\u00e1t, amelyeket figyelmen k\u00edv\u00fcl hagyhatunk (hiszen nek\u00fcnk monitoroz\u00e1sunk van, nem bankunk). history <\/code>Most m\u00e1r van \u00faj t\u00e1bl\u00e1nk<\/p>\n
particion\u00e1l\u00e1ssal, de hi\u00e1nyzik bel\u0151le az az adat, amely az utols\u00f3 adatfelt\u00f6lt\u00e9s sor\u00e1n ker\u00fclt a t\u00e1bl\u00e1ba history<\/code> . De ezek az adatok megvannak a t\u00e1bl\u00e1ban history_tmp<\/code>, \u00e9s most onnan felt\u00f6ltj\u00fck \u0151ket. Ehhez sz\u00fcks\u00e9g\u00fcnk lesz a kor\u00e1bban elmentett 1551085645 \u00e9rt\u00e9kre. Mi\u00e9rt ezt az \u00e9rt\u00e9ket mentett\u00fck el, \u00e9s nem a maxim\u00e1lis felt\u00f6lt\u00e9si id\u0151t haszn\u00e1ltuk a jelenlegi t\u00e1bl\u00e1b\u00f3l? 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
A m\u0171velet befejez\u00e9se ut\u00e1n az \u00faj, particion\u00e1lt t\u00e1bl\u00e1nkban<\/code><\/pre>\n
\nminden adatunk megvan, ami a r\u00e9gi t\u00e1bl\u00e1ban volt, plusz azok, amelyek m\u00e1r \u00e9rkeztek a t\u00e1bla \u00e1tnevez\u00e9se ut\u00e1n. A t\u00e1bla history <\/code>t\u00f6bb\u00e9 nem sz\u00fcks\u00e9ges. Azonnal t\u00f6r\u00f6lhetj\u00fck, de t\u00f6rl\u00e9s el\u0151tt k\u00e9sz\u00edthet\u00fcnk r\u00f3la biztons\u00e1gi m\u00e1solatot (ha p\u00e1nikolunk). history_old <\/code>A fent le\u00edrt folyamatot meg kell ism\u00e9telni a t\u00e1bl\u00e1khoz<\/p>\n
A Zabbix Server be\u00e1ll\u00edt\u00e1sain sz\u00fcks\u00e9ges jav\u00edt\u00e1sok history_str<\/code>, history_text <\/code>\u00e9s history_uint<\/code>.<\/p>\n
Mit kell m\u00f3dos\u00edtani a Zabbix Server be\u00e1ll\u00edt\u00e1saiban<\/h3>\n
\nMost m\u00e1r a sz\u00e1mviteli adatb\u00e1zis karbantart\u00e1sa a mi feladatunk. Ez azt jelenti, hogy a Zabbixnak t\u00f6bb\u00e9 nem kell t\u00f6r\u00f6lnie a r\u00e9gi adatokat - ezt mi v\u00e9gezz\u00fck el. Ahhoz, hogy a Zabbix Server ne pr\u00f3b\u00e1lja meg automatikusan tiszt\u00edtani az adatokat, be kell l\u00e9pnie a Zabbix webb\u00f6ng\u00e9sz\u0151j\u00e9be, v\u00e1lassza az 'Adminisztr\u00e1ci\u00f3' men\u00fcpontot, majd az '\u00c1ltal\u00e1nos' almennyt, v\u00e9g\u00fcl a jobb oldali leg\u00f6rd\u00fcl\u0151 men\u00fcb\u0151l v\u00e1lassza a 'T\u00f6rt\u00e9net t\u00f6rl\u00e9se' lehet\u0151s\u00e9get. A megjelen\u0151 oldalon t\u00f6r\u00f6lj\u00f6n minden jel\u00f6l\u00e9st a 'T\u00f6rt\u00e9net' csoportb\u00f3l, majd kattintson a 'Friss\u00edt\u00e9s' gombra. Ez megakad\u00e1lyozza a nem k\u00edv\u00e1nt t\u00e1bl\u00e1k tiszt\u00edt\u00e1s\u00e1t. t\u00f6rt\u00e9net*<\/code> a h\u00e1zi gondnok \u00e1ltal.<\/p>\n
Ugyanezen az oldalon figyeljen a 'V\u00e1ltoz\u00e1sok dinamik\u00e1ja' csoportra. Ez a t\u00e1bl\u00e1zat trends<\/code>, amelyhez vissza\u00edg\u00e9rt\u00fcnk. Ha ez a t\u00e1bl\u00e1zat t\u00fal nagyra n\u0151tt, \u00e9s particion\u00e1l\u00e1sra szorul, akkor a jel\u00f6l\u00e9seket itt is vegye le, majd kezelje ezt a t\u00e1bl\u00e1zatot pontosan \u00fagy, mint a t\u00f6bbi t\u00e1bl\u00e1zat eset\u00e9ben. t\u00f6rt\u00e9net*<\/code>.<\/p>\n
A j\u00f6v\u0151beli adatb\u00e1zis karbantart\u00e1s<\/h3>\n
\nAhogy kor\u00e1bban eml\u00edtve volt, a particion\u00e1lt t\u00e1bl\u00e1k norm\u00e1lis m\u0171k\u00f6d\u00e9s\u00e9hez id\u0151ben l\u00e9tre kell hozni a part\u00edci\u00f3kat. Ezt \u00edgy lehet megtenni:<\/p>\n
ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\nEzen k\u00edv\u00fcl, mivel particion\u00e1lt t\u00e1bl\u00e1kat hoztunk l\u00e9tre, \u00e9s megtiltottuk a Zabbix Servernek azokat a tiszt\u00edt\u00e1st, \u00edgy a r\u00e9gi adatok t\u00f6rl\u00e9se m\u00e1r a mi gondunk. Szerencs\u00e9re itt semmilyen probl\u00e9ma nincsen. Ezt egyszer\u0171en a sz\u00fcks\u00e9gtelenn\u00e9 v\u00e1lt part\u00edci\u00f3 t\u00f6rl\u00e9s\u00e9vel v\u00e9gezhetj\u00fck el. <\/p>\n
P\u00e9ld\u00e1ul:<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nA DATUM INTERVALLUMON alapul\u00f3 DELETE FROM oper\u00e1torokkal ellent\u00e9tben a DROP PARTITION n\u00e9h\u00e1ny m\u00e1sodperc alatt v\u00e9grehajt\u00f3dik, \u00e9s nem terheli meg a rendszert szerver<\/a> \u00e9s ugyan\u00fagy probl\u00e9mamentesen m\u0171k\u00f6dik MySQL replik\u00e1ci\u00f3 haszn\u00e1lata eset\u00e9n is.<\/p>\n
Z\u00e1r\u00e1s<\/h3>\n
\nAz itt le\u00edrt megold\u00e1s az id\u0151 pr\u00f3b\u00e1j\u00e1t ki\u00e1llta. Az adatmennyis\u00e9g n\u0151, de l\u00e9nyeges teljes\u00edtm\u00e9nycs\u00f6kken\u00e9st nem \u00e9szleltek.
\n
Forr\u00e1s: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0414\u043b\u044f \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438 \u0441\u043b\u0443\u0436\u0431 \u0443 \u043d\u0430\u0441 \u0434\u0430\u0432\u043d\u043e, \u0438 \u0432\u0441\u0435 \u0435\u0449\u0435 \u0443\u0441\u043f\u0435\u0448\u043d\u043e, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u043a\u043e\u043c\u0431\u0438\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u043d\u0430 \u0431\u0430\u0437\u0435 Nagios \u0438 Munin. \u041e\u0434\u043d\u0430\u043a\u043e \u044d\u0442\u0430 \u0441\u0432\u044f\u0437\u043a\u0430 \u0438\u043c\u0435\u0435\u0442 \u0440\u044f\u0434 \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043a\u043e\u0432, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u044b, \u043a\u0430\u043a \u0438 \u043c\u043d\u043e\u0433\u0438\u0435, \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0438\u0440\u0443\u0435\u043c Zabbix. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u0438\u043d\u0438\u043c\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u0443\u0441\u0438\u043b\u0438\u044f\u043c\u0438 \u043c\u043e\u0436\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0441 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c\u044e \u043f\u0440\u0438 \u0443\u0432\u0435\u043b\u0438\u0447\u0435\u043d\u0438\u0438 \u0447\u0438\u0441\u043b\u0430 \u0441\u043d\u0438\u043c\u0430\u0435\u043c\u044b\u0445 \u043c\u0435\u0442\u0440\u0438\u043a \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53966","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47A particion\u00e1l\u00e1s alkalmaz\u00e1sa MySQL-ben a Zabbix sz\u00e1m\u00e1ra sok monitoring objektummal | ProHoster","description":"A szerverek \u00e9s szolg\u00e1ltat\u00e1sok monitoroz\u00e1s\u00e1ra r\u00e9g\u00f3ta, \u00e9s tov\u00e1bbra is sikeresen haszn\u00e1ljuk a Nagios \u00e9s Munin alap\u00fa \u00f6tv\u00f6z\u00f6tt megold\u00e1st.","canonical_url":"https:\/\/prohoster.info\/hu\/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":"hu_HU","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\/hu\/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\/hu\/wp-json\/wp\/v2\/posts\/53966","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/comments?post=53966"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/53966\/revisions"}],"predecessor-version":[{"id":172868,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/53966\/revisions\/172868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media?parent=53966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/categories?post=53966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/tags?post=53966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}