{"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\/da\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","title":{"rendered":"Brug af partitionering i MySQL til Zabbix med et stort antal overv\u00e5gningsobjekter","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Til overv\u00e5gning af servere og tjenester har vi i lang tid, og stadig med succes, brugt en kombineret l\u00f8sning baseret p\u00e5 Nagios og Munin. Men denne kombination har en r\u00e6kke ulemper, s\u00e5 vi, ligesom mange andre, udnytter aktivt Zabbix<\/a><\/noindex>. I denne artikel vil vi fort\u00e6lle om, hvordan man med minimale anstrengelser kan l\u00f8se problemet med ydeevnen ved at \u00f8ge antallet af m\u00e5lte metrikker og v\u00e6ksten af MySQL-databasevolumener
\n<\/a><\/noindex><\/p>\n

Problemer ved brug af MySQL-database sammen med Zabbix<\/h3>\n

\nS\u00e5 l\u00e6nge databasen var lille, og antallet af gemte metrikker var begr\u00e6nset, gik alt godt. Den indbyggede proces housekeeper, som k\u00f8rer Zabbix Server, fjernede med succes for\u00e6ldede poster fra databasen og forhindrede den i at vokse. Men da antallet af m\u00e5lte metrikker voksede, og databasen n\u00e5ede en vis st\u00f8rrelse, blev alt v\u00e6rre. Housekeeper kunne ikke l\u00e6ngere fjerne data inden for den tildelte tidsramme, og gamle data blev tilbageholdt i databasen. Under driften af housekeeper opstod der en \u00f8get belastning p\u00e5 Zabbix Server, som kunne vare i lang tid. Det blev klart, at der m\u00e5tte g\u00f8res noget ved den opst\u00e5ede situation.<\/p>\n

Dette er et kendt problem; praktisk talt alle, der har arbejdet med store m\u00e6ngder overv\u00e5gning i Zabbix, har st\u00f8dt p\u00e5 det samme. Der var ogs\u00e5 flere l\u00f8sninger: for eksempel at erstatte MySQL med PostgreSQL eller endda Elasticsearch, men den mest enkle og afpr\u00f8vede l\u00f8sning var at overg\u00e5 til partitionering af tabellerne, der opbevarer metrikdataene i MySQL-databasen. Vi besluttede at g\u00e5 netop denne vej.<\/p>\n

Overgangen fra almindelige MySQL-tabeller til partitionerede<\/h3>\n

\nZabbix er godt dokumenteret, og tabellerne, hvor den opbevarer metrikker, er kendt. Disse tabeller er: history<\/code>, hvor float-v\u00e6rdier gemmes, history_str<\/code>, hvor korte stringv\u00e6rdier opbevares, history_text<\/code>, hvor lange tekstv\u00e6rdier gemmes, og history_uint<\/code>, hvor heltalsv\u00e6rdier opbevares. Der er ogs\u00e5 en tabel trends<\/code>, som gemmer \u00e6ndringsdynamik, men den besluttede vi ikke at r\u00f8re, da dens st\u00f8rrelse er lille, og vi vil vende tilbage til den lidt senere.<\/p>\n

Generelt set var det klart, hvilke tabeller der skulle behandles. Vi besluttede at lave partitioner hver uge, undtagen den sidste, baseret p\u00e5 m\u00e5nedens numre, dvs. fire partitioner pr. m\u00e5ned: fra den 1. til den 7., fra den 8. til den 14., fra den 15. til den 21., og fra den 22. til den 1. (n\u00e6ste m\u00e5ned). Vanskeligheden l\u00e5 i, at vi skulle forvandle de n\u00f8dvendige tabeller til partitionerede \"on-the-fly\", uden at stoppe arbejdet med Zabbix Server og indsamlingen af metrics.<\/p>\n

M\u00e6rkeligt nok hjalp selve datastrukturen i tabellerne os i dette. history <\/code>For eksempel har tabellen<\/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
\nhvorved<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nSom vi kan se, skal hver metric i sidste ende inds\u00e6ttes i tabellen med to meget vigtige og praktiske felter itemid<\/b> og clock<\/b>. Dermed kan vi fuldt ud oprette en midlertidig tabel, f.eks. med navnet history_tmp<\/code>, konfigurere partitioneringen for den, og derefter overf\u00f8re alle data fra tabellen history<\/code>, og derefter omd\u00f8be tabellen history<\/code> i history_old<\/code>, og tabellen history_tmp<\/code> i history<\/code>, hvorefter vi tilf\u00f8jer de data, som vi ikke har tilf\u00f8jet fra history_old<\/code> i history <\/code>og fjerner history_old<\/code>. Dette kan g\u00f8res helt sikkert, vi vil ikke miste noget, da de n\u00e6vnte felter itemid <\/b>og clock <\/b>sikrer forbindelsen mellem den specifikke metric og det specifikke tidspunkt, ikke et eller andet r\u00e6kkef\u00f8lge nummer.<\/p>\n
Selve overgangsproceduren<\/h3>\n
<\/p>\n
Opm\u00e6rksomhed! Det er meget \u00f8nskeligt at lave en fuld sikkerhedskopi af databasen, f\u00f8r man p\u00e5begynder nogen handlinger. Vi er alle mennesker og kan lave fejl i kommandoerne, hvilket kan f\u00f8re til datatab. Ja, en sikkerhedskopi sikrer ikke maksimal aktualitet, men det er bedre at have en end ingen.<\/p><\/blockquote>\n
 S\u00e5 vi slukker og stopper ingenting. Det vigtigste er, at der er tilstr\u00e6kkeligt med ledig plads p\u00e5 disken p\u00e5 selve MySQL-serveren, dvs. at der for hver af de ovenn\u00e6vnte tabeller history<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, mindst skal v\u00e6re plads til at oprette en tabel med suffikset \"_tmp\", idet man tager hensyn til, at den vil have samme volumen som den oprindelige tabel.<\/p>\n
Vi vil ikke beskrive alt flere gange for hver af de n\u00e6vnte tabeller, men vil tage det som eksempel p\u00e5 kun \u00e9n af dem \u2014 tabellen history<\/code>.<\/p>\n
S\u00e5 lad os oprette en tom tabel history_tmp <\/code>baseret p\u00e5 strukturen af tabellen history<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nVi opretter de partitioner, vi har brug for. For eksempel vil vi g\u00f8re dette for en m\u00e5ned. Hver partition oprettes baseret p\u00e5 en partitioneringsregel, der er baseret p\u00e5 v\u00e6rdien af feltet clock<\/b>, som vi sammenligner med tidsstemplet:<\/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
\nDenne operator tilf\u00f8jer partitionering til den tabel, vi har oprettet history_tmp<\/code>. Lad os pr\u00e6cisere, at de data, hvis feltv\u00e6rdi clock <\/b>er mindre end \"2019-02-01 00:00:00\", vil falde ind under partitionen p20190201<\/i>, derefter vil data, hvis feltv\u00e6rdi clock<\/b> er st\u00f8rre end \"2019-02-01 00:00:00\", men mindre end \"2019-02-07 00:00:00\", falde ind under partitionen p20190207 <\/i>og s\u00e5 videre.<\/p>\n
Vigtig bem\u00e6rkning:<\/b> Hvad sker der, hvis vi f\u00e5r data i den partitionerede tabel, hvor feltv\u00e6rdien clock er st\u00f8rre end eller lig med \"2019-03-01 00:00:00\"? Da der ikke er en passende partition for disse data, vil de ikke blive indsat i tabellen og g\u00e5 tabt. Derfor er det n\u00f8dvendigt, at du husker at oprette yderligere partitioner i tide for at undg\u00e5 s\u00e5danne datatab (som n\u00e6vnt nedenfor).<\/p><\/blockquote>\n
 S\u00e5, den midlertidige tabel er klar. Vi indl\u00e6sser data. Processen kan tage et stykke tid, men heldigvis blokere den ikke for andre foresp\u00f8rgsler, s\u00e5 du skal blot have lidt t\u00e5lmodighed:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nN\u00f8gleordet IGNORE ved den f\u00f8rste indl\u00e6sning er ikke obligatorisk, da der alligevel ikke er nogen data i tabellen, men det vil v\u00e6re nyttigt ved forl\u00e6ngelsen af data. Desuden kan det v\u00e6re nyttigt, hvis du m\u00e5tte afbryde indl\u00e6sningsprocessen og starte den forfra.<\/p>\n
Efter et stykke tid (m\u00e5ske endda flere timer) er den f\u00f8rste dataindl\u00e6sning blevet gennemf\u00f8rt. Som du forst\u00e5r, indeholder tabellen history_tmp <\/code>ikke alle data fra tabellen history<\/code>, men kun dem, der var i den p\u00e5 det tidspunkt, hvor foresp\u00f8rgslen blev udf\u00f8rt. Her har du faktisk et valg: enten laver vi endnu et fors\u00f8g (hvis indl\u00e6sningsprocessen tog lang tid), eller s\u00e5 g\u00e5r vi straks videre til omd\u00f8bning af tabellerne, som n\u00e6vnt tidligere. Lad os f\u00f8rst tale om den anden gennemgang. F\u00f8rst skal vi forst\u00e5 tidspunktet for den seneste indsatte post i history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nAntag, at du har f\u00e5et: 1551045645<\/b>. Nu bruger vi den opn\u00e5ede v\u00e6rdi til den anden datainds\u00e6ttelsesrunde:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nDenne runde b\u00f8r afsluttes betydeligt hurtigere. Men hvis den f\u00f8rste runde tog timer, og den anden ogs\u00e5 tager lang tid, kan det v\u00e6re fornuftigt at lave en tredje runde, der udf\u00f8res p\u00e5 samme m\u00e5de som den anden.<\/p>\n
Til sidst udf\u00f8rer vi igen operationen for at f\u00e5 tidspunktet for den seneste inds\u00e6ttelse af en post i history_tmp<\/code>, ved at udf\u00f8re:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nLad os antage, at du har f\u00e5et 1551085645<\/b>. Gem denne v\u00e6rdi \u2014 vi f\u00e5r brug for den til yderligere inds\u00e6ttelse.<\/p>\n
Og nu, n\u00e5r den prim\u00e6re datainds\u00e6ttelse i history_tmp <\/code>er afsluttet, g\u00e5r vi videre til at omd\u00f8be tabellerne:<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nVi har formateret denne blok som en enkelt transaktion for at undg\u00e5 situationen med at inds\u00e6tte data i en ikke-eksisterende tabel, da tabellen efter det f\u00f8rste RENAME ikke vil eksistere f\u00f8r det andet RENAME udf\u00f8res. history <\/code>Men selv hvis der kommer data til tabellen mellem RENAME-operationerne, og selve tabellen ikke er der endnu (p\u00e5 grund af omd\u00f8bningen), vil vi f\u00e5 et lille antal inds\u00e6tningsfejl, som vi kan ignorere (vi har overv\u00e5gning, ikke en bank). history <\/code>Nu har vi en ny tabel<\/p>\n
med partitionering, men den mangler data, som blev indsamlet under den seneste datainds\u00e6ttelse i tabellen history<\/code> . Men vi har disse data i tabellen history_tmp<\/code>og vi vil nu overf\u00f8re dem derfra. Til dette skal vi bruge den tidligere gemte v\u00e6rdi 1551085645. Hvorfor gemte vi denne v\u00e6rdi i stedet for at bruge det maksimale tidspunkt for inds\u00e6ttelse fra den nuv\u00e6rende tabel 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 afslutningen af denne operation har vi i den nye, partitionerede tabel<\/code><\/pre>\n
\nalle de data, der var i den gamle, plus dem, der allerede er kommet efter omd\u00f8bningen af tabellen. Tabel history <\/code>er ikke l\u00e6ngere n\u00f8dvendig. Den kan enten slettes med det samme, eller man kan lave en backup af den inden sletning (hvis man er paranoid). history_old <\/code>Hele den ovenfor beskrevne proces skal gentages for tabellerne<\/p>\n
Hvad der skal rettes i indstillingerne for Zabbix Server history_str<\/code>, history_text <\/code>og history_uint<\/code>.<\/p>\n
Hvad skal rettes i indstillingerne for Zabbix Server<\/h3>\n
\nNu ligger vedligeholdelse af databasen og dathistorikken p\u00e5 vores skuldre. Det betyder, at Zabbix ikke l\u00e6ngere skal slette gamle data \u2014 vi h\u00e5ndterer det selv. For at s\u00f8rge for, at Zabbix Server ikke fors\u00f8ger at rense dataene selv, skal du g\u00e5 ind i Zabbix webinterface, v\u00e6lge \u00abAdministration\u00bb i menuen, derefter undermenuen \u00abGenerelt\u00bb, og i dropdown-menuen til h\u00f8jre v\u00e6lge \u00abRens historie\u00bb. P\u00e5 den fremkomne side skal du fjerne alle flueben for gruppen \u00abHistorie\u00bb og trykke p\u00e5 knappen \u00abOpdater\u00bb. Dette vil forhindre un\u00f8dvendig rensning af tabeldata. history*<\/code> via housekeeper.<\/p>\n
Bem\u00e6rk ogs\u00e5 gruppen \u00ab\u00c6ndringsdynamik\u00bb p\u00e5 denne side. Det er netop tabel trends<\/code>, som vi lovede at vende tilbage til. Hvis den ogs\u00e5 er blevet for stor og har brug for partitionering, skal du fjerne fluebenene i denne gruppe, og derefter behandle denne tabel p\u00e5 samme m\u00e5de som for tabellerne history*<\/code>.<\/p>\n
Fremtidig vedligeholdelse af databasen<\/h3>\n
\nSom n\u00e6vnt tidligere, for korrekt funktion p\u00e5 partitionerede tabeller, er det vigtigt at oprette partitioner til tiden. Det kan g\u00f8res p\u00e5 f\u00f8lgende m\u00e5de:<\/p>\n
ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\nDerudover, da vi har oprettet partitionerede tabeller og forbudt Zabbix Server at rense dem, er det nu vores ansvar at fjerne gamle data. Heldigvis er der slet ingen problemer med dette. Det g\u00f8res enkelt ved at fjerne den partition, hvis data vi ikke l\u00e6ngere har brug for. <\/p>\n
For eksempel:<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nI mods\u00e6tning til DELETE FROM operatorer med angivelse af datointerval, udf\u00f8res DROP PARTITION p\u00e5 et par sekunder, belaster slet ikke server<\/a> og fungerer liges\u00e5 problemfrit i tilf\u00e6lde af brug af MySQL replikation.<\/p>\n
Konklusion<\/h3>\n
\nDen beskrevne l\u00f8sning er blevet testet over tid. M\u00e6ngden af data vokser, men der er ikke bem\u00e6rket nogen m\u00e6rkbar neds\u00e6ttelse af ydeevnen.
\n
Kilde: 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\udd47Brug af partitionering i MySQL til Zabbix med et stort antal overv\u00e5gningsobjekter | ProHoster","description":"Til overv\u00e5gning af servere og tjenester har vi l\u00e6nge og stadig med succes brugt en kombination af Nagios og Munin.","canonical_url":"https:\/\/prohoster.info\/da\/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":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/53966","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=53966"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/53966\/revisions"}],"predecessor-version":[{"id":172868,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/53966\/revisions\/172868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=53966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=53966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=53966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}