🥇Bikaranîna Parvekirina MySQL ji bo Zabbix bi Hejmarek Zêde ya Tiştên Çavdêrkirî

Ji bo çavdêrîkirina server û karûbaran, em ji demek dirêj ve çareseriyek hevbeş li ser bingeha Nagios û Munin bikar tînin, û hîn jî bi serfirazî. Lêbelê, ev tevlihevî çend kêmasiyan heye, ji ber vê yekê em, mîna gelekan, bi rengek çalak îstismar dikin Zabbix. Di vê gotarê de em ê biaxivin ka meriv çawa, bi hewildanek hindiktirîn, hûn dikarin pirsgirêkek performansê çareser bikin dema ku hejmara metrîkên hatine girtin û mezinbûna cildên databasa MySQL

Pirsgirêkên karanîna databasek MySQL bi Zabbix re

Dema ku databas piçûk bû û hejmara metrîkên ku tê de hatine hilanîn hindik bû, her tişt mezin bû. Pêvajoya standard a malê, ku ji hêla Zabbix Server bixwe ve hatî destpêkirin, bi serfirazî tomarên kevnar ji databasê jêbirin, pêşî li mezinbûna wê digire. Lêbelê, gava ku hejmara metrîkên ku hatine girtin zêde bûn û mezinahiya databasê gihîştî mezinahiyek diyarkirî, tişt xirabtir bûn. Houserkeeper dev ji jêbirina daneyan di nav dema ku jê re hatî veqetandî de rawestand, û daneyên kevn dest pê kir ku di databasê de bimînin. Dema ku kedkarê malê dixebitî, li Servera Zabbix barek zêde bû, ku dikare demek dirêj bidome. Eşkere bû ku divê em bi awayekî rewşa heyî çareser bikin.

Ev pirsgirêkek naskirî ye, hema her kesê ku bi cildên mezin ên çavdêriyê li ser Zabbix xebitiye bi heman tiştî re rû bi rû maye. Di heman demê de gelek çareserî jî hebûn: Mînakî, guherandina MySQL bi PostgreSQL an jî Elasticsearch re, lê çareseriya herî hêsan û îsbatkirî derbasbûna tabloyên dabeşkirinê bû ku daneyên metrîkan di databasek MySQL de hilîne. Me biryar da ku em tam bi vî awayî biçin.

Ji tabloyên MySQL yên birêkûpêk derbasî yên dabeşkirî bibin

Zabbix baş tê belgekirin û tabloyên ku ew metrîkan hildide têne zanîn. Ev tablo ev in: history, cihê ku nirxên float têne hilanîn, history_str, cihê ku nirxên rêzikên kurt têne hilanîn, history_text, ku nirxên nivîsa dirêj têne hilanîn û history_uint, ku nirxên yekjimar têne hilanîn. Tabloyek jî heye trends, ku dînamîkên guhertinan diparêze, lê me biryar da ku dest nedin wê, ji ber ku mezinahiya wê piçûk e û em ê hinekî paşê vegerin.

Bi gelemperî, zelal bû ku kîjan tabloyên pêdivî ye ku bêne pêvajo kirin. Me biryar da ku ji bo her hefte, ji bilî ya paşîn, li gorî hejmarên mehê, ango, dabeşan çêbikin. çar beşên mehê: ji 1-ê heta 7-ê, ji 8-ê heta 14-ê, ji 15-ê heta 21-ê û ji 22-ê heta 1-ê (meha din). Zehmetî ev bû ku me hewce dikir ku tabloyên ku ji me re lazim in "li ser firînê" veguherînin yên dabeşkirî, bêyî ku xebata Zabbix Server û berhevkirina metrîkan qut bikin.

Pir ecêb e, di vê yekê de avahiya daneya tabloyan bixwe hat alîkariya me. Mînak tablo history xwedan avahiya jêrîn e:

`itemid` bigint(20) unsigned NOT NULL,
`clock` int(11) NOT NULL DEFAULT '0',
`value` double(16,4) NOT NULL DEFAULT '0.0000',
`ns` int(11) NOT NULL DEFAULT '0',

li ku

KEY `history_1` (`itemid`,`clock`)

Wekî ku hûn dikarin bibînin, her metrîk di dawiyê de têkevin tabloyek ku ji bo me du qadên pir girîng û hêsan hene. itemid и seet. Bi vî rengî, em dikarin bi hêsanî tabloyek demkî biafirînin, mînakî, bi navê history_tmp, ji bo wê dabeşkirinê saz bikin û dûv re hemî daneyên ji tabloyê li wir veguhezînin historyû paşê navê tabloyê biguherînin history в history_old, û sifrê history_tmp в history, û dûv re daneyên ku me jê tijî nekiriye lê zêde bike history_old в history û derxistin history_old. Ev dikare bi tevahî ewlehî were kirin, em ê tiştek winda nekin, ji ber ku zeviyên jorîn itemid и seet girêdana metrîkek taybetî bi demek taybetî re peyda dike, û ne ji hin jimareyek rêzik re.

Pêvajoya derbasbûnê bixwe

Baldarî! Berî ku hûn dest bi çalakiyan bikin, pir tê pêşniyar kirin ku hûn kopiyek hilanînê ya tevahî ya databasê çêbikin. Em hemî mirovên zindî ne û dikarin di koma fermanan de xeletiyek bikin, ku dibe sedema windabûna daneyê. Erê. Piştgiriyek dê rojanebûna herî zêde misoger neke, lê çêtir e ku yek ji tunebûnê hebe.

Ji ber vê yekê, em tiştek nagirin an jî tiştek rawestînin. Ya sereke ev e ku servera MySQL bixwe têra xwe cîhê dîska belaş heye, yanî. da ku ji bo her yek ji tabloyên li jor rêzkirî history, history_text, history_str, history_uint, bi kêmanî, cîh têra çêkirina tabloyek bi paşgira "_tmp" hebû, ji ber ku ew ê bi qasî tabloya orîjînal be.

Em ê her tiştî ji bo her yek ji tabloyên jorîn çend caran rave nekin û em ê her tiştî bi mînaka yek ji wan tenê binirxînin - tablo. history.

Ji ber vê yekê, werin em tabloyek vala ava bikin history_tmp li ser bingeha avahiya sifrê history.

CREATE TABLE `history_tmp` LIKE `history`;

Em dabeşên ku em hewce ne diafirînin. Mesela em vê yekê mehekê bikin. Her dabeşek li ser bingeha qaîdeyek dabeşkirinê li ser bingeha nirxa zeviyê tête çêkirin seet, ku em bi demjimêrê re berhev dikin:

ALTER TABLE `history_tmp` PARTITION BY RANGE( clock ) (
PARTITION p20190201 VALUES LESS THAN (UNIX_TIMESTAMP("2019-02-01 00:00:00")),
PARTITION p20190207 VALUES LESS THAN (UNIX_TIMESTAMP("2019-02-07 00:00:00")),
PARTITION p20190214 VALUES LESS THAN (UNIX_TIMESTAMP("2019-02-14 00:00:00")),
PARTITION p20190221 VALUES LESS THAN (UNIX_TIMESTAMP("2019-02-21 00:00:00")),
PARTITION p20190301 VALUES LESS THAN (UNIX_TIMESTAMP("2019-03-01 00:00:00"))
);

Ev operator dabeşkirina tabloya ku me çêkiriye zêde dike history_tmp. Ka em wê daneya ku nirxa zeviyê wê zelal bikin seet kêmtir ji "2019-02-01 00:00:00" dê di komê de be p20190201, paşê daneyên ku nirxa zeviyê seet bêtir ji "2019-02-01 00:00:00" lê kêmtir ji "2019-02-07 00:00:00" dê di dabeşkirinê de be p20190207 û da ser.

Nîşeya girîng: Ger daneyên me yên di tabloya dabeşkirî de hebin ku nirxa wan di qada demjimêrê de ji "2019-03-01 00:00:00" mezintir an wekhev be, çi dibe? Ji ber ku ji bo vê daneyê dabeşek minasib tune, ew ê di tabloyê de xuya neke û winda bibe. Ji ber vê yekê, hûn hewce ne ku ji bîr mekin ku hûn di wextê xwe de dabeşên zêde biafirînin da ku ji windahiyên daneya wusa dûr nekevin (wekî ku li jêr tê nîqaş kirin).

Ji ber vê yekê, tabloya demkî tê amadekirin. Daneyan dagirin. Pêvajo dikare demek pir dirêj bigire, lê bi bextewarî ew daxwazên din asteng nake, ji ber vê yekê hûn tenê hewce ne ku bîhnfireh bin:

INSERT IGNORE INTO `history_tmp` SELECT * FROM history;

Peyva IGNORE di dema dagirtina destpêkê de ne hewce ye, ji ber ku bi her awayî di tabloyê de dane tune, lê dema dagirtina daneyê hûn ê hewce bikin. Wekî din, dibe ku kêrhatî be heke, dema barkirina daneyan, we neçar ma ku vê pêvajoyê qut bike û ji nû ve dest pê bike.

Ji ber vê yekê, piştî demekê (dibe ku çend demjimêran jî), yekem barkirina daneyê pêk hat. Wekî ku hûn fêm dikin, niha tablo history_tmp hemû daneyên ji tabloyê nagire history, lê tenê yên ku di dema destpêkirina daxwazê de tê de bûn. Li vir hûn bi rastî vebijarkek heye: an em yek derbasiyek din dikin (heke pêvajoya dagirtinê demek dirêj dirêj kir), an jî em tavilê dest bi veguhertina navên tabloyan, ya ku li jor hatî behs kirin, dikin. Ka em pêşî li ser derbasbûna duyemîn biaxivin. Pêşî pêdivî ye ku em dema tomarkirina paşîn a tê de fam bikin history_tmp:

SELECT max(clock) FROM history_tmp;

Em bêjin ku we wergirtiye: 1551045645. Naha em di derbasbûna duyemîn a dagirtina daneyê de nirxa encam bikar tînin:

INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;

Divê ev derbasbûn pir zûtir bi dawî bibe. Lê heke derbasbûna yekem bi demjimêran bigire, û ya duyemîn jî demek dirêj girt, dibe ku rast be ku hûn derbasbûna sêyemîn bikin, ya ku tam bi heman awayê ya duyemîn tête kirin.

Di dawiyê de, em dîsa operasyona bidestxistina dema ketina paşîn a tomarê di nav de pêk tînin history_tmpbi rêve:

SELECT max(clock) FROM history_tmp;

Em bêjin ku we standiye 1551085645. Vê nirxê hilînin - em ê ji bo dagirtina wê hewce bikin.

Û naha, bi rastî, dema ku daneya destpêkê tê dagirtin history_tmp qediya, em dest bi guherandina navên tabloyan bikin:

BEGIN;
RENAME TABLE history TO history_old;
RENAME TABLE history_tmp TO history;
COMMIT;

Me ev blok wekî yek danûstendinê sêwirand da ku daneyan nekeve tabloyek neheyî, ji ber ku piştî RENAMEya yekem heya ku RENAME ya duyemîn were darve kirin, tablo history dê nebe. Lê tevî ku di navbera operasyonên RENAME de li ser sifrê history dê hin dane bigihîjin, lê tablo bixwe dê hîn nebe (ji ber binavkirinê), em ê hejmarek piçûk xeletiyên têxê ku dikarin werin paşguh kirin bistînin (me çavdêrî heye, ne bankek).

Niha tabloyeke me ya nû heye history bi dabeşkirinê re, lê ew daneyên ku di dema derbasbûna paşîn a danîna daneyan di tabloyê de hatine wergirtin tune history_tmp. Lê di tabloyê de ev dane hene history_old û em ê niha wan ji wir bilind bikin. Ji bo vê yekê, pêdivîya me bi nirxa ku berê hatî hilanîn 1551085645 heye. Çima me ev nirx hilanî û dema dagirtina herî zêde ya tabloya heyî bikar neanî history? Ji ber ku daneyên nû jixwe têkevin wê û em ê demek xelet bistînin. Ji ber vê yekê, em daneyan zêde bikin:

INSERT IGNORE INTO `history` SELECT * FROM history_old WHERE clock>=1551045645;

Piştî ku ev operasyon qediya, di tabloya meya nû, dabeşkirî de history hemî daneyên ku di ya kevin de bûn hene, plus yên ku piştî binavkirina tabloyê berê hatine. Mêz history_old êdî ne hewceyî me ne. Hûn dikarin wê tavilê jêbikin, an jî hûn dikarin berî jêbirina wê kopiyek hilanînê çêbikin (heke hûn paranoîd in).

Pêdivî ye ku tevahiya pêvajoya jorîn ji bo tabloyan were dubare kirin history_str, history_text и history_uint.

Tiştê ku divê di mîhengên Servera Zabbix de were rast kirin

Naha parastina databasê di warê dîroka daneyê de dikeve ser milê me. Ev tê vê wateyê ku Zabbix êdî neçar e ku daneyên kevn jêbibe - em ê bi xwe vê yekê bikin. Ji bo ku Pêşkêşkara Zabbix hewl nede ku daneyan bi xwe paqij bike, hûn hewce ne ku herin navgîniya webê ya Zabbix, di menuyê de "Rêveberî" hilbijêrin, dûv re jêrmenuya "Giştî" hilbijêrin, dûv re di navnîşa dakêşanê de "Dîrok Paqij bike" hilbijêrin. rast. Li ser rûpela ku xuya dibe, hûn hewce ne ku hemî qutiyên koma "Dîrok" rakin û li ser bişkoka "Nûvekirin" bikirtînin. Ev ê rê li me bigire ku tabloyên nehewce paqij nekin history* bi rêya kedkarê malê.

Di heman rûpelê de, bala xwe bidin koma "Dynamics of Changes". Ev tenê tabloyek e trends, ku me soz da ku em vegerin. Ger ew jî pir mezin bûye û pêdivî bi dabeşkirinê heye, qutiyên vê komê rakin, û dûv re vê tabloyê bi heman awayê ku we ji bo tabloyan kir pêvajo bike. history*.

Zêdetir parastina databasê

Wekî ku berê hate nivîsandin, ji bo xebata normal li ser tabloyên dabeşkirî, pêdivî ye ku di wextê de dabeşan çêbikin. Hûn dikarin bi vî rengî bikin:

ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP("2019-03-07 00:00:00")));

Wekî din, ji ber ku me tabloyên dabeşkirî afirandin û paqijkirina Zabbix Serverê qedexe kir, jêbirina daneyên kevn naha xema me ye. Xweşbextane, tu pirsgirêk li vir tune. Ev bi tenê bi jêbirina dabeşkirina ku daneyên wê êdî hewcedariya me ne tê kirin.

Bo nimûne:

ALTER TABLE history DROP PARTITION p20190201;

Berevajî daxuyaniyên DELETE FROM bi rêzek tarîxî, temamkirina DROP PARTITION çend saniyeyan digire û bi tevahî tê barkirin. server û dema ku replikasyona MySQL tê bikar anîn jî bi heman rengî bêkêmasî dixebite.