{"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\/sv\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","title":{"rendered":"Anv\u00e4ndning av partitionering i MySQL f\u00f6r Zabbix med ett stort antal \u00f6vervakningsobjekt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

F\u00f6r \u00f6vervakning av servrar och tj\u00e4nster har vi l\u00e4nge, och fortfarande framg\u00e5ngsrikt, anv\u00e4nt en kombinerad l\u00f6sning baserad p\u00e5 Nagios och Munin. Men denna kombination har en rad nackdelar, vilket g\u00f6r att vi, precis som m\u00e5nga andra, aktivt anv\u00e4nder Zabbix<\/a><\/noindex>. I den h\u00e4r artikeln kommer vi att ber\u00e4tta om hur man med minimala anstr\u00e4ngningar kan l\u00f6sa problem med prestanda n\u00e4r antalet m\u00e4tv\u00e4rden \u00f6kar och storleken p\u00e5 MySQL-databaser v\u00e4xer.
\n<\/a><\/noindex><\/p>\n

Problem med att anv\u00e4nda MySQL-databaser tillsammans med Zabbix<\/h3>\n

\nS\u00e5 l\u00e4nge databasen var liten och antalet sparade m\u00e4tv\u00e4rden var litet, var allt bra. Den inbyggda processen housekeeper, som k\u00f6rs av Zabbix Server, tog effektivt bort f\u00f6r\u00e5ldrade poster fr\u00e5n databasen, vilket f\u00f6rhindrade att den v\u00e4xte. Men s\u00e5 snart antalet m\u00e4tv\u00e4rden \u00f6kade och databasen n\u00e5dde en viss storlek blev allt s\u00e4mre. Housekeeper kunde inte l\u00e4ngre radera data inom den tilldelade tidsramen, och gamla data blev kvar i databasen. Under tiden som housekeeper var aktiv blev belastningen p\u00e5 Zabbix Server h\u00f6g, vilket kunde p\u00e5g\u00e5 under l\u00e5ng tid. Det blev klart att vi p\u00e5 n\u00e5got s\u00e4tt beh\u00f6vde l\u00f6sa den uppkomna situationen.<\/p>\n

Detta \u00e4r ett v\u00e4lk\u00e4nt problem, n\u00e4stan alla som har arbetat med stora \u00f6vervakningsvolymer i Zabbix har st\u00f6tt p\u00e5 samma sak. Det fanns ocks\u00e5 flera l\u00f6sningar: till exempel att byta ut MySQL mot PostgreSQL eller till och med Elasticsearch, men den enklaste och mest bepr\u00f6vade l\u00f6sningen var att \u00f6verg\u00e5 till partitionering av tabeller som lagrar m\u00e4tdata i MySQL-databasen. Vi beslutade att g\u00e5 denna v\u00e4g.<\/p>\n

\u00d6verg\u00e5ng fr\u00e5n vanliga MySQL-tabeller till partitionerade<\/h3>\n

\nZabbix \u00e4r v\u00e4l dokumenterat och tabellerna d\u00e4r det lagrar m\u00e4tv\u00e4rden \u00e4r k\u00e4nda. Dessa tabeller \u00e4r: history<\/code>, d\u00e4r float-v\u00e4rden lagras, history_str<\/code>, d\u00e4r korta str\u00e4ngv\u00e4rden lagras, history_text<\/code>, d\u00e4r l\u00e5nga textv\u00e4rden lagras, och history_uint<\/code>, d\u00e4r heltal lagras. Det finns ocks\u00e5 en tabell trends<\/code>, som lagrar f\u00f6r\u00e4ndringsdynamik, men den beslutade vi att inte p\u00e5verka, eftersom dess storlek \u00e4r liten och vi kommer att \u00e5terkomma till den senare.<\/p>\n

Generellt sett var det tydligt vilka tabeller som beh\u00f6vde bearbetas. Vi besl\u00f6t att g\u00f6ra partitioner varje vecka, med undantag f\u00f6r den sista, baserat p\u00e5 m\u00e5nadens datum, d.v.s. fyra partitioner per m\u00e5nad: fr\u00e5n 1:a till 7:e, fr\u00e5n 8:e till 14:e, fr\u00e5n 15:e till 21:a och fr\u00e5n 22:a till 1:a (n\u00e4sta m\u00e5nad). Sv\u00e5righeten l\u00e5g i att vi beh\u00f6vde omvandla de tabeller som var relevanta f\u00f6r oss till partitionerade \"i farten\", utan att avbryta driften av Zabbix Server och insamlingen av metrik.<\/p>\n

Konstigt nog fick vi hj\u00e4lp av just databasstrukturen i tabellerna. Till exempel har tabellen history <\/code>f\u00f6ljande struktur:<\/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
\nd\u00e4r<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nSom vi ser lagras varje metrik i slut\u00e4nden i en tabell med tv\u00e5 mycket viktiga och anv\u00e4ndbara f\u00e4lt f\u00f6r oss itemid<\/b> och clock<\/b>. S\u00e5ledes kan vi utan problem skapa en tempor\u00e4r tabell, exempelvis med namnet history_tmp<\/code>, konfigurera partitionering f\u00f6r den och sedan \u00f6verf\u00f6ra alla data fr\u00e5n tabellen history<\/code>, och d\u00e4refter d\u00f6pa om tabellen history<\/code> p\u00e5 history_old<\/code>, och tabellen history_tmp<\/code> p\u00e5 history<\/code>, efter vilket vi l\u00e4gger till de data som vi har kvar att l\u00e4gga till fr\u00e5n history_old<\/code> p\u00e5 history <\/code>och ta bort history_old<\/code>. Detta kan g\u00f6ras helt s\u00e4kert, vi kommer inte att f\u00f6rlora n\u00e5got, eftersom de angivna f\u00e4lten itemid <\/b>och clock <\/b>s\u00f6rjer f\u00f6r kopplingen av den specifika metrikken till en specifik tidpunkt, inte till n\u00e5got ordningsnummer.<\/p>\n
Sj\u00e4lva \u00f6verg\u00e5ngsprocessen<\/h3>\n
<\/p>\n
Observera! Det \u00e4r mycket \u00f6nskv\u00e4rt att g\u00f6ra en fullst\u00e4ndig s\u00e4kerhetskopia av databasen innan man p\u00e5b\u00f6rjar n\u00e5gra \u00e5tg\u00e4rder. Vi \u00e4r alla m\u00e4nniskor och kan g\u00f6ra misstag med kommandon, vilket kan leda till dataf\u00f6rlust. Ja, s\u00e4kerhetskopian garanterar inte maximal aktualitet, men det \u00e4r b\u00e4ttre att ha en s\u00e5dan \u00e4n ingen alls.<\/p><\/blockquote>\n
 S\u00e5, vi st\u00e4nger inte av eller stoppar n\u00e5got. Det viktigaste \u00e4r att det finns tillr\u00e4ckligt med ledigt utrymme p\u00e5 MySQL-servern, d.v.s. att varje av de ovan n\u00e4mnda tabellerna history<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, minst, har tillr\u00e4ckligt med utrymme f\u00f6r att skapa en tabell med suffixet \"_tmp\", med h\u00e4nsyn till att den kommer att ha samma volym som den ursprungliga tabellen.<\/p>\n
Vi kommer inte att beskriva allt flera g\u00e5nger f\u00f6r var och en av de ovan n\u00e4mnda tabellerna, utan vi kommer att illustrera allt med bara ett exempel \u2014 tabellen history<\/code>.<\/p>\n
S\u00e5, vi skapar en tom tabell history_tmp <\/code>baserat p\u00e5 strukturen av tabellen history<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nSkapar de partitioner vi beh\u00f6ver. Som ett exempel kommer vi att g\u00f6ra detta under en m\u00e5nad. Varje partition skapas p\u00e5 grundval av en partitioneringsregel som baseras p\u00e5 v\u00e4rdet av f\u00e4ltet clock<\/b>, som vi j\u00e4mf\u00f6r med tidsst\u00e4mpeln:<\/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
\nDenna operator l\u00e4gger till partitionering f\u00f6r den tabell vi just har skapat history_tmp<\/code>. L\u00e5t oss tydligg\u00f6ra att data vars f\u00e4ltv\u00e4rde clock <\/b>\u00e4r mindre \u00e4n \"2019-02-01 00:00:00\" kommer att hamna i partitionen p20190201<\/i>, f\u00f6ljt av data vars f\u00e4ltv\u00e4rde clock<\/b> \u00e4r st\u00f6rre \u00e4n \"2019-02-01 00:00:00\" men mindre \u00e4n \"2019-02-07 00:00:00\" som hamnar i partitionen p20190207 <\/i>och h\u00e4mta bilder fr\u00e5n dab.semrush.com<\/p>\n
Viktig notering:<\/b> Vad h\u00e4nder om vi i den partitionerade tabellen f\u00e5r data vars f\u00e4ltv\u00e4rde clock \u00e4r st\u00f6rre eller lika med \"2019-03-01 00:00:00\"? Eftersom det inte finns en l\u00e4mplig partition f\u00f6r dessa data kommer de inte att hamna i tabellen och kommer att g\u00e5 f\u00f6rlorade. D\u00e4rf\u00f6r \u00e4r det viktigt att ni inte gl\u00f6mmer att i tid skapa ytterligare partitioner f\u00f6r att undvika s\u00e5dana dataloss (som beskrivs nedan).<\/p><\/blockquote>\n
 S\u00e5, den tempor\u00e4ra tabellen \u00e4r f\u00f6rberedd. Vi laddar upp data. Processen kan ta ganska l\u00e5ng tid, men lyckligtvis blockerar den inga andra f\u00f6rfr\u00e5gningar, s\u00e5 man beh\u00f6ver bara ha t\u00e5lamod:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nNyckelordet IGNORE vid den f\u00f6rsta uppladdningen \u00e4r inte obligatoriskt, eftersom det \u00e4nd\u00e5 inte finns n\u00e5gra data i tabellen, men det kommer att beh\u00f6vas vid senare uppdateringar av data. Dessutom kan det vara anv\u00e4ndbart om du m\u00e5ste avbryta denna process under dataladdningen och starta om den.<\/p>\n
S\u00e5, efter en tid (m\u00f6jligen flera timmar) har den f\u00f6rsta dataladdningen genomf\u00f6rts. Som ni f\u00f6rst\u00e5r inneh\u00e5ller nu tabellen history_tmp <\/code>inte alla data fr\u00e5n tabellen history<\/code>, utan endast de som fanns d\u00e4r vid tidpunkten f\u00f6r utf\u00f6randet av f\u00f6rfr\u00e5gan. H\u00e4r har ni egentligen ett val: antingen g\u00f6r vi en ny genomg\u00e5ng (om uppladdningsprocessen tog l\u00e5ng tid), eller s\u00e5 g\u00e5r vi direkt till omd\u00f6pningen av tabellerna som n\u00e4mndes ovan. L\u00e5t oss b\u00f6rja med den andra genomg\u00e5ngen. F\u00f6rst beh\u00f6ver vi f\u00f6rst\u00e5 tiden f\u00f6r den senaste inskrivna posten i history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nAnta att ni fick: 1551045645<\/b>. Nu anv\u00e4nder vi det erh\u00e5llna v\u00e4rdet f\u00f6r den andra omg\u00e5ngen av datainfl\u00f6det:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nDen h\u00e4r omg\u00e5ngen b\u00f6r avslutas betydligt snabbare. Men om den f\u00f6rsta omg\u00e5ngen tog timmar och den andra ocks\u00e5 tog l\u00e5ng tid, kan det vara vettigt att g\u00f6ra en tredje omg\u00e5ng som utf\u00f6rs helt p\u00e5 samma s\u00e4tt som den andra.<\/p>\n
I slutet genomf\u00f6r vi \u00e5terigen operationen f\u00f6r att f\u00e5 tiden f\u00f6r den senaste ins\u00e4ttningen av en post i history_tmp<\/code>, genom att utf\u00f6ra:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nAnta att du har f\u00e5tt 1551085645<\/b>. Spara detta v\u00e4rde \u2014 vi kommer att beh\u00f6va det f\u00f6r efterf\u00f6ljande ins\u00e4ttningar.<\/p>\n
Och nu, n\u00e4r den prim\u00e4ra datainfl\u00f6det i history_tmp <\/code>\u00e4r avslutat, g\u00e5r vi vidare till att byta namn p\u00e5 tabellerna:<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nVi har formulerat detta block som en transaktion f\u00f6r att undvika att inf\u00f6ra data i en icke-existerande tabell, eftersom efter den f\u00f6rsta RENAME till dess att den andra RENAME utf\u00f6rs, kommer tabellen history <\/code>inte att existera. Men \u00e4ven om n\u00e5gra data kommer in i tabellen mellan RENAME-operationerna, och tabellen \u00e4nnu inte existerar (p\u00e5 grund av namnbytet), kommer vi att f\u00e5 ett minimalt antal ins\u00e4ttningsfel som kan ignoreras (vi har \u00f6vervakning, inte en bank). history <\/code>Nu har vi en ny tabell<\/p>\n
med partitionering, men den saknar data som erh\u00f6lls under den senaste omg\u00e5ngen av datainfl\u00f6det till tabellen history<\/code> . Men dessa data har vi i tabellen history_tmp<\/code>och vi ska nu fylla p\u00e5 dem d\u00e4rifr\u00e5n. F\u00f6r detta beh\u00f6ver vi det tidigare sparade v\u00e4rdet 1551085645. Varf\u00f6r sparade vi detta v\u00e4rde och inte anv\u00e4nde den maximala ins\u00e4ttningstiden fr\u00e5n den aktuella tabellen 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
Efter avslutningen av denna operation har vi i den nya, partitionerade tabellen<\/code><\/pre>\n
\nalla data som l\u00e5g i den gamla, plus de som redan kommit efter namnbytet av tabellen. Tabellen history <\/code>\u00e4r inte l\u00e4ngre n\u00f6dv\u00e4ndig. Den kan tas bort omedelbart, eller s\u00e5 kan du g\u00f6ra en s\u00e4kerhetskopia av den innan du tar bort den (om du \u00e4r paranoid). history_old <\/code>Hela den ovan beskrivna processen beh\u00f6ver upprepas f\u00f6r tabellerna<\/p>\n
Vad som beh\u00f6ver \u00e4ndras i Zabbix Server-inst\u00e4llningarna history_str<\/code>, history_text <\/code>och history_uint<\/code>.<\/p>\n
Vad beh\u00f6ver justeras i Zabbix Server-inst\u00e4llningarna<\/h3>\n
\nNu \u00e5ligger det oss att sk\u00f6ta databasunderh\u00e5llet av historikdata. Det inneb\u00e4r att Zabbix inte l\u00e4ngre beh\u00f6ver ta bort gammal data \u2014 vi kommer att hantera detta sj\u00e4lva. F\u00f6r att f\u00f6rhindra att Zabbix Server f\u00f6rs\u00f6ker rensa data sj\u00e4lv, beh\u00f6ver du g\u00e5 in i Zabbix webbgr\u00e4nssnitt, v\u00e4lja menyn \"Administration\", sedan undermenyn \"Allm\u00e4nt\", och d\u00e4refter i listrutan till h\u00f6ger v\u00e4lja \"Rensning av historik\". P\u00e5 den framtr\u00e4dande sidan ska du avmarkera alla kryssrutor f\u00f6r gruppen \"Historia\" och trycka p\u00e5 knappen \"Uppdatera\". Detta f\u00f6rhindrar on\u00f6dig rensning av tabeller som vi inte beh\u00f6ver. historia*<\/code> via housekeeper.<\/p>\n
Observera ocks\u00e5 gruppen \"\u00c4ndringsdynamik\" p\u00e5 samma sida. Det \u00e4r just den tabell trends<\/code>, som vi lovade att \u00e5terkomma till. Om den har blivit f\u00f6r stor och beh\u00f6ver partitioneras, avmarkera kryssrutorna \u00e4ven i denna grupp, och behandla denna tabell p\u00e5 samma s\u00e4tt som vi gjorde f\u00f6r tabellerna. historia*<\/code>.<\/p>\n
Vidare databasunderh\u00e5ll<\/h3>\n
\nSom tidigare n\u00e4mnts, f\u00f6r att partitionerade tabeller ska fungera normalt, \u00e4r det n\u00f6dv\u00e4ndigt att skapa partitioner i tid. Det kan g\u00f6ras s\u00e5 h\u00e4r:<\/p>\n
ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\nDessutom, eftersom vi har skapat partitionerade tabeller och f\u00f6rbjudit Zabbix Server att rensa dem, s\u00e5 \u00e4r borttagning av gammal data nu v\u00e5rt ansvar. Lyckligtvis finns det inga problem med detta. Det g\u00f6rs enkelt genom att ta bort den partitionen vars data inte l\u00e4ngre beh\u00f6vs. <\/p>\n
Till exempel:<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nTill skillnad fr\u00e5n DELETE FROM-kommandon med datumintervall, utf\u00f6rs DROP PARTITION p\u00e5 n\u00e5gra sekunder, belastar inte server<\/a> och fungerar lika smidigt n\u00e4r det anv\u00e4nds i MySQL-replikation.<\/p>\n
Slutsats<\/h3>\n
\nDen beskrivna l\u00f6sningen har testats och bevisats \u00f6ver tid. Datavolymen \u00f6kar, men n\u00e5gon m\u00e4rkbar f\u00f6rs\u00e4mring av prestanda har inte noterats.
\n
K\u00e4lla: 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\udd47Anv\u00e4ndning av partitionering i MySQL f\u00f6r Zabbix med ett stort antal \u00f6vervakningsobjekt | ProHoster","description":"F\u00f6r server- och tj\u00e4nst\u00f6vervakning har vi l\u00e4nge och framg\u00e5ngsrikt anv\u00e4nt en kombinerad l\u00f6sning baserad p\u00e5 Nagios och Munin.","canonical_url":"https:\/\/prohoster.info\/sv\/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":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/53966","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=53966"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/53966\/revisions"}],"predecessor-version":[{"id":172868,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/53966\/revisions\/172868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=53966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=53966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=53966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}