🥇Paggamit sa MySQL Partitioning para sa Zabbix nga adunay Daghang Gi-monitor nga mga Butang

Aron ma-monitor ang mga server ug serbisyo, gigamit namon ang usa ka hiniusa nga solusyon nga gibase sa Nagios ug Munin sa dugay nga panahon, ug malampuson gihapon. Bisan pa, kini nga kombinasyon adunay daghang mga disbentaha, mao nga kami, sama sa kadaghanan, aktibo nga nagpahimulos Zabbix. Niini nga artikulo maghisgot kami kung giunsa, nga adunay gamay nga paningkamot, mahimo nimong masulbad ang usa ka problema sa pasundayag kung gidugangan ang gidaghanon sa mga sukatan nga gikuha ug gipadako ang mga volume sa database sa MySQL

Mga problema sa paggamit sa MySQL database sa Zabbix

Samtang ang database gamay ug ang gidaghanon sa mga sukatan nga gitipigan niini gamay ra, ang tanan maayo. Ang standard nga proseso sa housekeeper, nga gilunsad sa Zabbix Server mismo, malampuson nga nagtangtang sa mga outdated records gikan sa database, nga nagpugong niini sa pagtubo. Bisan pa, sa diha nga ang gidaghanon sa mga sukatan nga gikuha ug ang gidak-on sa database nakaabot sa usa ka piho nga gidak-on, ang mga butang misamot. Ang Housekeeper mihunong sa pagtangtang sa datos sulod sa gilay-on sa panahon nga gigahin niini, ug ang daan nga datos nagsugod sa pagpabilin sa database. Samtang nagdagan ang housekeeper, adunay dugang nga load sa Zabbix Server, nga mahimong magpadayon sa dugay nga panahon. Naklaro nga kinahanglan namong sulbaron ang kasamtangang sitwasyon.

Kini usa ka nahibal-an nga problema, hapit tanan nga nagtrabaho sa daghang mga volume sa pag-monitor sa Zabbix nakasugat sa parehas nga butang. Adunay usab daghang mga solusyon: pananglitan, pag-ilis sa MySQL sa PostgreSQL o bisan sa Elasticsearch, apan ang labing yano ug labing napamatud-an nga solusyon mao ang pagbalhin sa mga partition nga lamesa nga nagtipig sa datos sa sukatan sa database sa MySQL. Nakahukom kami nga moadto sa ingon nga paagi.

Pagbalhin gikan sa regular nga MySQL nga mga lamesa ngadto sa mga partitioned

Ang Zabbix maayo nga dokumentado ug ang mga lamesa diin kini nagtipig sa mga sukatan nahibal-an. Mao kini ang mga lamesa: history, diin gitipigan ang mga kantidad sa float, history_str, diin ang mubu nga mga kantidad sa string gitipigan, history_text, diin ang taas nga mga kantidad sa teksto gitipigan ug history_uint, diin gitipigan ang mga integer nga kantidad. Adunay usab usa ka lamesa trends, nga nagtipig sa mga dinamika sa mga pagbag-o, apan nakahukom kami nga dili kini hikapon, tungod kay ang gidak-on niini gamay ug mobalik kami niini sa ulahi.

Sa kinatibuk-an, klaro kung unsang mga lamesa ang kinahanglan iproseso. Nakahukom kami nga maghimo mga partisyon alang sa matag semana, gawas sa katapusan, base sa mga numero sa bulan, i.e. upat ka batch kada bulan: gikan sa ika-1 ngadto sa ika-7, gikan sa ika-8 ngadto sa ika-14, gikan sa ika-15 ngadto sa ika-21 ug gikan sa ika-22 ngadto sa ika-1 (sa sunod nga bulan). Ang kalisud mao nga kinahanglan namon nga ibalhin ang mga lamesa nga kinahanglan namon nga gibahin "sa langaw", nga wala makabalda sa operasyon sa Zabbix Server ug pagkolekta sa mga sukatan.

Katingad-an, ang istruktura sa datos sa mga lamesa mismo mitabang kanamo niini. Pananglitan sa lamesa history adunay mosunod nga istruktura:

`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',

sa samang higayon

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

Sama sa imong makita, ang matag metric sa katapusan gisulod sa usa ka lamesa nga adunay duha ka hinungdanon ug kombenyente nga mga natad alang kanamo butangid и orasan. Sa ingon, dali kita makahimo og usa ka temporaryo nga lamesa, pananglitan, nga adunay ngalan history_tmp, i-set up ang partitioning para niini ug dayon ibalhin ang tanang data gikan sa table didto historyug dayon ilisan ang ngalan sa lamesa history в history_old, ug ang lamesa history_tmp в history, ug dayon idugang ang datos nga wala namo gipuno history_old в history ug delete history_old. Mahimo kini nga hingpit nga luwas, dili kami mawad-an bisan unsa, tungod kay ang mga natad sa ibabaw butangid и orasan paghatag pagbugkos sa usa ka piho nga sukatan sa usa ka piho nga oras, ug dili sa pila ka serial number.

Ang proseso sa transisyon mismo

Atensyon! Kini mao ang kaayo advisable, sa dili pa magsugod sa bisan unsa nga mga aksyon, sa paghimo sa usa ka bug-os nga backup nga kopya sa database. Kitang tanan buhi nga mga tawo ug mahimong masayop sa hugpong sa mga sugo, nga mahimong mosangpot sa pagkawala sa datos. Oo. Ang usa ka backup dili makasiguro sa labing taas nga pagka-update, apan mas maayo nga adunay usa kaysa wala.

Busa, dili nato i-turn off o ihunong ang bisan unsa. Ang nag-unang butang mao nga ang MySQL server mismo adunay igo nga gidaghanon sa libre nga espasyo sa disk, i.e. mao nga alang sa matag usa sa mga lamesa nga gilista sa ibabaw history, history_text, history_str, history_uint, sa labing gamay, adunay igo nga wanang aron makahimo usa ka lamesa nga adunay suffix nga "_tmp", tungod kay kini parehas nga gidak-on sa orihinal nga lamesa.

Dili namo ihulagway ang tanan sa makadaghang higayon alang sa matag usa sa mga lamesa sa ibabaw ug tagdon ang tanan gamit ang pananglitan sa usa lamang niini - ang lamesa history.

Busa, maghimo kita og walay sulod nga lamesa history_tmp base sa istruktura sa lamesa history.

CREATE TABLE `history_tmp` LIKE `history`;

Gihimo namo ang mga partisyon nga among gikinahanglan. Pananglitan, buhaton nato kini sulod sa usa ka bulan. Ang matag partisyon gihimo base sa lagda sa partitioning base sa bili sa field orasan, nga atong itandi sa timestamp:

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"))
);

Kini nga operator nagdugang partitioning alang sa lamesa nga among gibuhat history_tmp. Klarohon nato ang maong datos kansang field value orasan ubos sa "2019-02-01 00:00:00" ang maapil sa batch p20190201, dayon data kansang field value orasan labaw pa sa "2019-02-01 00:00:00" apan ubos sa "2019-02-07 00:00:00" ang maapil sa partisyon p20190207 ug sa ingon sa.

Importante nga nota: Unsa ang mahitabo kung kita adunay mga datos sa partitioned table kansang bili sa field sa orasan mas dako o katumbas sa "2019-03-01 00:00:00"? Tungod kay wala'y angay nga partisyon alang niini nga datos, dili kini makita sa lamesa ug mawala. Busa, kinahanglan nimong hinumdoman ang paghimo og dugang nga mga partisyon sa tukma sa panahon nga paagi aron malikayan ang mga pagkawala sa datos (sama sa gihisgutan sa ubos).

Busa, ang temporaryo nga lamesa giandam. Pun-a ang datos. Ang proseso mahimo’g dugay nga panahon, apan maayo nga wala kini makababag sa bisan unsang ubang mga hangyo, mao nga kinahanglan nimo nga mapailubon:

INSERT IGNORE INTO `history_tmp` SELECT * FROM history;

Ang IGNORE nga keyword wala kinahanglana sa panahon sa una nga pagpuno, tungod kay wala’y datos sa lamesa bisan pa, apan kinahanglan nimo kini kung magdugang data. Dugang pa, kini mahimong mapuslanon kung, samtang nag-upload sa datos, kinahanglan nimong hunongon kini nga proseso ug magsugod pag-usab.

Busa, human sa pipila ka panahon (tingali bisan sa pipila ka oras), ang unang data upload nahitabo. Sama sa imong nasabtan, karon ang lamesa history_tmp wala maglangkob sa tanan nga datos gikan sa lamesa history, apan kadto lamang nga anaa niini sa panahon nga nagsugod ang hangyo. Dinhi aduna ka'y kapilian: mahimo ba nga maghimo kami og usa pa ka pass (kung ang proseso sa pagpuno dugay), o dayon kami magpadayon sa pag-usab sa ngalan sa mga lamesa, nga gihisgutan sa ibabaw. Atong hisgotan una ang ikaduhang pass. Una kinahanglan naton nga masabtan ang oras sa katapusan nga gisulud nga rekord sa history_tmp:

SELECT max(clock) FROM history_tmp;

Ingnon ta nga nakadawat ka: 1551045645. Karon among gigamit ang resulta nga kantidad sa ikaduhang pass sa pagpuno sa datos:

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

Kini nga tudling kinahanglan nga matapos sa labi ka paspas. Apan kung ang una nga pagpasa nagkinahanglan og mga oras aron makompleto, ug ang ikaduha nga usa usab dugay nga panahon, kini mahimong husto sa paghimo sa usa ka ikatulo nga pass, nga gihimo sa tukma nga paagi sa ikaduha nga paagi.

Sa katapusan, gihimo na usab namon ang operasyon sa pagkuha sa oras sa katapusan nga pagsulud sa usa ka rekord sa history_tmppinaagi sa pagdagan:

SELECT max(clock) FROM history_tmp;

Ingnon ta nga nakadawat ka 1551085645. I-save kini nga kantidad - kinahanglan namon kini alang sa pagpuno.

Ug karon, sa tinuud, kung ang una nga pagpuno sa datos sa history_tmp nahuman na, magsugod ta sa pag-ilis sa ngalan sa mga lamesa:

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

Gidisenyo namo kini nga block isip usa ka transaksyon aron malikayan ang pagsal-ot sa datos ngadto sa wala na nga lamesa, tungod kay human sa unang RENAME hangtod sa ikaduhang RENAME mapatuman, ang lamesa history dili maglungtad. Apan bisan kung tali sa RENAME nga mga operasyon sa lamesa history ang pipila ka mga datos moabut, apan ang lamesa mismo wala pa maglungtad (tungod sa pagbag-o sa ngalan), makadawat kami usa ka gamay nga gidaghanon sa mga sayup sa pagsal-ot nga mahimong mapasagdan (naa kami pag-monitor, dili usa ka bangko).

Karon naa mi bag-o nga lamesa history uban sa partitioning, apan kini kulang data nga nadawat sa panahon sa katapusan nga pass sa pagsal-ot sa data ngadto sa lamesa history_tmp. Apan kami adunay kini nga datos sa lamesa history_old ug ato na silang top up gikan didto. Aron mahimo kini, kinahanglan namon ang na-save nga kantidad nga 1551085645. Ngano nga gitipigan namon kini nga kantidad ug wala gigamit ang labing kadaghan nga oras sa pagpuno gikan sa karon nga lamesa history? Tungod kay ang bag-ong datos nagsulod na niini ug kita makakuha sa sayop nga panahon. Busa, atong idugang ang datos:

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

Human mahuman kini nga operasyon, sa among bag-o, partitioned table history naa ang tanan nga datos nga naa sa daan, dugang pa ang mga naabot na pagkahuman gibag-o ang ngalan sa lamesa. Lamesa history_old wala na nato kini kinahanglana. Mahimo nimo kini mapapas dayon, o mahimo nimo kini nga backup nga kopya sa dili pa kini tangtangon (kung paranoid ka).

Ang tibuok proseso sa ibabaw kinahanglan nga sublion alang sa mga lamesa history_str, history_text и history_uint.

Unsa ang kinahanglan nga matul-id sa mga setting sa Zabbix Server

Karon ang pagpadayon sa database sa mga termino sa kasaysayan sa datos nahulog sa among mga abaga. Kini nagpasabut nga ang Zabbix dili na kinahanglan nga tangtangon ang daan nga datos - buhaton namon kini sa among kaugalingon. Aron mapugngan ang Zabbix Server sa pagsulay sa paghawan sa data mismo, kinahanglan ka nga moadto sa Zabbix web interface, pilia ang "Administration" sa menu, dayon ang "General" submenu, unya pilia ang "Clear history" sa drop-down list sa ang katungod. Sa panid nga makita, kinahanglan nimo nga tangtangon ang tsek sa tanan nga mga kahon alang sa grupo nga "Kasaysayan" ug i-klik ang "Update" nga buton. Kini makapugong kanato sa paghawan sa mga lamesa nga wala kinahanglana history* pinaagi sa housekeeper.

Sa parehas nga panid, hatagan pagtagad ang grupo nga "Dynamics of Changes". Kini usa lamang ka lamesa trends, diin kami misaad nga mobalik. Kung nahimo usab kini nga dako kaayo ug nanginahanglan pagbahin, kuhaa ang tsek sa mga kahon sa kini nga grupo, ug dayon iproseso kini nga lamesa sa parehas nga paagi sama sa imong gibuhat sa mga lamesa. history*.

Dugang nga pagmentinar sa database

Sama sa gisulat sa sayo pa, alang sa normal nga operasyon sa mga partitioned nga mga lamesa, kinahanglan nga maghimo mga partisyon sa oras. Mahimo nimo kini sama niini:

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

Dugang pa, tungod kay naghimo kami og mga partitioned table ug gidid-an ang Zabbix Server sa paglimpyo niini, ang pagtangtang sa daan nga datos mao na ang among gikabalak-an. Maayo na lang, wala'y mga problema dinhi. Gihimo kini pinaagi lamang sa pagtangtang sa partisyon kansang datos wala na namo kinahanglana.

Pananglitan:

ALTER TABLE history DROP PARTITION p20190201;

Dili sama sa mga pahayag nga DELETE FROM nga adunay date range, ang DROP PARTITION mokabat ug pipila ka segundo aron makompleto ug hingpit nga ma-unload. server ug mogana nga walay putol kon mogamit og MySQL replication.

konklusyon

Ang gihulagway nga solusyon gisulayan sa panahon. Ang gidaghanon sa datos nagkadako, apan walay makita nga paghinay sa performance.

Source: www.habr.com