{"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\/pt\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","title":{"rendered":"Uso de particionamento no MySQL para Zabbix com um grande n\u00famero de objetos de monitoramento","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Para monitoramento de servidores e servi\u00e7os, h\u00e1 muito tempo utilizamos com sucesso uma solu\u00e7\u00e3o combinada baseada no Nagios e Munin. No entanto, essa combina\u00e7\u00e3o apresenta v\u00e1rias desvantagens, portanto, como muitos, estamos explorando ativamente Zabbix<\/a><\/noindex>. Neste artigo, vamos explicar como, com um esfor\u00e7o m\u00ednimo, \u00e9 poss\u00edvel resolver o problema de desempenho \u00e0 medida que o n\u00famero de m\u00e9tricas coletadas aumenta e os volumes do banco de dados MySQL crescem.
\n<\/a><\/noindex><\/p>\n

Problemas ao usar o banco de dados MySQL em conjunto com o Zabbix<\/h3>\n

\nEnquanto o banco de dados era pequeno e o n\u00famero de m\u00e9tricas armazenadas nele era reduzido, tudo estava \u00f3timo. O processo padr\u00e3o housekeeper, que \u00e9 iniciado pelo pr\u00f3prio Zabbix Server, exclu\u00eda com sucesso os registros antigos do banco de dados, evitando que ele crescesse. No entanto, assim que o n\u00famero de m\u00e9tricas coletadas aumentou e o volume do banco de dados atingiu um determinado tamanho, a situa\u00e7\u00e3o come\u00e7ou a piorar. O housekeeper n\u00e3o conseguia mais excluir dados dentro do intervalo de tempo permitido, resultando na perman\u00eancia de dados antigos no banco. Durante a execu\u00e7\u00e3o do housekeeper, houve uma carga elevada no Zabbix Server, que poderia durar bastante tempo. Ficou claro que algo precisava ser feito para resolver a situa\u00e7\u00e3o.<\/p>\n

Esse \u00e9 um problema conhecido; praticamente todos que trabalharam com grandes volumes de monitoramento no Zabbix enfrentaram o mesmo desafio. Havia v\u00e1rias solu\u00e7\u00f5es, como substituir o MySQL pelo PostgreSQL ou at\u00e9 mesmo Elasticsearch, mas a solu\u00e7\u00e3o mais simples e testada foi a migra\u00e7\u00e3o para o particionamento das tabelas que armazenam dados de m\u00e9tricas no banco de dados MySQL. Decidimos seguir exatamente por esse caminho.<\/p>\n

Transi\u00e7\u00e3o de tabelas MySQL convencionais para tabelas particionadas<\/h3>\n

\nO Zabbix \u00e9 bem documentado e as tabelas onde ele armazena m\u00e9tricas s\u00e3o conhecidas. Estas tabelas s\u00e3o: hist\u00f3rico<\/code>, onde s\u00e3o armazenados valores float, history_str<\/code>, onde s\u00e3o armazenados valores curtos em string, history_text<\/code>, onde s\u00e3o armazenados valores longos de texto e history_uint<\/code>, onde s\u00e3o armazenados valores inteiros. H\u00e1 tamb\u00e9m a tabela trends<\/code>, que armazena a din\u00e2mica das mudan\u00e7as, mas optamos por n\u00e3o alter\u00e1-la, pois seu tamanho \u00e9 pequeno e mais tarde voltaremos a ela.<\/p>\n

Em geral, est\u00e1vamos cientes de quais tabelas deveriam ser processadas. Decidimos criar parti\u00e7\u00f5es para cada semana, com exce\u00e7\u00e3o da \u00faltima, com base nos dias do m\u00eas, ou seja, quatro parti\u00e7\u00f5es por m\u00eas: de 1 a 7, de 8 a 14, de 15 a 21 e de 22 a 1 (do m\u00eas seguinte). A dificuldade estava em transformar as tabelas necess\u00e1rias em parti\u00e7\u00f5es \"em tempo real\", sem interromper o funcionamento do Zabbix Server e a coleta de m\u00e9tricas.<\/p>\n

Stranhamente, a pr\u00f3pria estrutura dos dados das tabelas nos ajudou. Por exemplo, a tabela hist\u00f3rico <\/code>possui a seguinte estrutura:<\/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
\nneste caso,<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nComo podemos ver, cada m\u00e9trica \u00e9 finalmente armazenada em uma tabela com dois campos muito importantes e convenientes para n\u00f3s: itemid<\/b> e clock<\/b>. Assim, podemos facilmente criar uma tabela tempor\u00e1ria, por exemplo, com o nome history_tmp<\/code>, configurar a parti\u00e7\u00e3o para ela e, em seguida, transferir todos os dados da tabela hist\u00f3rico<\/code>, e depois renomear a tabela hist\u00f3rico<\/code> em history_old<\/code>, enquanto a tabela history_tmp<\/code> em hist\u00f3rico<\/code>, ap\u00f3s o que podemos adicionar novamente os dados que n\u00e3o foram transferidos de history_old<\/code> em hist\u00f3rico <\/code>e excluir history_old<\/code>. Podemos fazer isso de forma completamente segura, n\u00e3o perderemos nada, pois os campos mencionados acima itemid <\/b>e clock <\/b>garantem a liga\u00e7\u00e3o de uma m\u00e9trica espec\u00edfica a um hor\u00e1rio espec\u00edfico, e n\u00e3o a um n\u00famero sequencial.<\/p>\n
O pr\u00f3prio procedimento de transi\u00e7\u00e3o<\/h3>\n
<\/p>\n
Aten\u00e7\u00e3o! \u00c9 altamente recomend\u00e1vel, antes de iniciar qualquer a\u00e7\u00e3o, fazer uma c\u00f3pia de seguran\u00e7a completa do banco de dados. Todos n\u00f3s somos humanos e podemos cometer um erro ao digitar comandos, o que pode levar \u00e0 perda de dados. Sim, a c\u00f3pia de seguran\u00e7a pode n\u00e3o garantir a m\u00e1xima atualidade, mas \u00e9 melhor ter uma do que nenhuma.<\/p><\/blockquote>\n
 Ent\u00e3o, n\u00e3o desligamos nem interrompemos nada. O principal \u00e9 garantir que no servidor MySQL haja espa\u00e7o suficiente dispon\u00edvel em disco, ou seja, que haja espa\u00e7o suficiente para cada uma das tabelas mencionadas acima hist\u00f3rico<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, ao menos o suficiente para criar uma tabela com o sufixo \"_tmp\", considerando que ela ter\u00e1 o mesmo volume que a tabela original.<\/p>\n
N\u00e3o iremos descrever tudo v\u00e1rias vezes para cada uma das tabelas mencionadas acima e examinaremos tudo apenas pelo exemplo de uma delas \u2014 a tabela hist\u00f3rico<\/code>.<\/p>\n
Portanto, criamos uma tabela vazia history_tmp <\/code>com base na estrutura da tabela hist\u00f3rico<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nCriamos as parti\u00e7\u00f5es necess\u00e1rias. Para um exemplo, faremos isso por um m\u00eas. Cada parti\u00e7\u00e3o \u00e9 criada com base em uma regra de particionamento, baseada no valor do campo clock<\/b>, que comparamos com o carimbo de data\/hora:<\/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
\nEste comando adiciona particionamento \u00e0 tabela que criamos history_tmp<\/code>. Esclarecendo, os dados cujo valor do campo clock <\/b>\u00e9 menor que \"2019-02-01 00:00:00\" ir\u00e3o para a parti\u00e7\u00e3o p20190201<\/i>, em seguida, os dados cujo valor do campo clock<\/b> \u00e9 maior que \"2019-02-01 00:00:00\" mas menor que \"2019-02-07 00:00:00\" ir\u00e3o para a parti\u00e7\u00e3o p20190207 <\/i>e assim por diante.<\/p>\n
Nota importante:<\/b> E o que acontece se tivermos dados na tabela particionada cujo valor do campo clock for maior ou igual a \"2019-03-01 00:00:00\"? Como n\u00e3o h\u00e1 parti\u00e7\u00e3o adequada para esses dados, eles n\u00e3o ser\u00e3o inseridos na tabela e ser\u00e3o perdidos. Portanto, voc\u00ea deve n\u00e3o esquecer de criar parti\u00e7\u00f5es adicionais a tempo, para evitar tais perdas de dados (como descrito abaixo).<\/p><\/blockquote>\n
 Assim, a tabela tempor\u00e1ria est\u00e1 pronta. Vamos carregar os dados. O processo pode levar um tempo consider\u00e1vel, mas, felizmente, ele n\u00e3o bloqueia quaisquer outras consultas, ent\u00e3o s\u00f3 precisamos ter paci\u00eancia:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nA palavra-chave IGNORE durante o carregamento inicial n\u00e3o \u00e9 obrigat\u00f3ria, j\u00e1 que a tabela est\u00e1 vazia, mas voc\u00ea precisar\u00e1 dela ao adicionar dados adicionais. Al\u00e9m disso, ela pode ser \u00fatil se voc\u00ea teve que interromper esse processo e recome\u00e7ar.<\/p>\n
Assim, depois de algum tempo (talvez at\u00e9 v\u00e1rias horas), o primeiro carregamento de dados foi conclu\u00eddo. Como voc\u00ea sabe, agora a tabela history_tmp <\/code>n\u00e3o cont\u00e9m todos os dados da tabela hist\u00f3rico<\/code>, mas apenas aqueles que estavam nela no momento em que a consulta come\u00e7ou a ser executada. Aqui voc\u00ea realmente tem uma escolha: ou fazemos mais uma passagem (se o processo de carregamento demorou muito), ou vamos direto para a renomea\u00e7\u00e3o das tabelas, como mencionado acima. Vamos primeiro falar sobre a segunda passagem. Para come\u00e7ar, precisamos entender o hor\u00e1rio da \u00faltima grava\u00e7\u00e3o inserida em history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nSuponha que voc\u00ea obteve: 1551045645<\/b>. Agora usamos o valor obtido na segunda passagem de inser\u00e7\u00e3o de dados:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nEssa passagem deve terminar significativamente mais r\u00e1pido. Mas se a primeira passagem levar horas e a segunda tamb\u00e9m demorar, pode ser certo fazer uma terceira passagem, que ser\u00e1 executada de maneira id\u00eantica \u00e0 segunda.<\/p>\n
No final, novamente executamos a opera\u00e7\u00e3o para obter o tempo da \u00faltima inser\u00e7\u00e3o de registro em history_tmp<\/code>, executando:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nSuponhamos que voc\u00ea obteve 1551085645<\/b>. Salve este valor \u2014 n\u00f3s precisaremos dele para a nova inser\u00e7\u00e3o.<\/p>\n
Agora, de fato, quando a carga inicial de dados em history_tmp <\/code>terminou, come\u00e7amos a renomear as tabelas:<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nAgrupamos este bloco como uma \u00fanica transa\u00e7\u00e3o, para evitar o momento da inser\u00e7\u00e3o de dados em uma tabela inexistente, pois ap\u00f3s o primeiro RENAME at\u00e9 o momento da execu\u00e7\u00e3o do segundo RENAME, a tabela hist\u00f3rico <\/code>n\u00e3o existir\u00e1. Mas mesmo que entre opera\u00e7\u00f5es RENAME alguns dados sejam inseridos na tabela, e a tabela em si ainda n\u00e3o estiver presente (devido ao renomeio), teremos um pequeno n\u00famero de erros de inser\u00e7\u00e3o que podemos ignorar (estamos monitorando, n\u00e3o \u00e9 um banco). hist\u00f3rico <\/code>Agora temos uma nova tabela<\/p>\n
com particionamento, mas faltam dados que foram obtidos durante a \u00faltima passagem de inser\u00e7\u00e3o de dados na tabela hist\u00f3rico<\/code> . Mas esses dados est\u00e3o na tabela history_tmp<\/code>e vamos inseri-los agora. Para isso, precisamos do valor anteriormente salvo 1551085645. Por que salvamos esse valor e n\u00e3o usamos o tempo m\u00e1ximo de inser\u00e7\u00e3o j\u00e1 da tabela atual? history_old <\/code>INSERT IGNORE INTO `history` SELECT * FROM history_old WHERE clock>=1551045645; hist\u00f3rico<\/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
Ap\u00f3s a conclus\u00e3o desta opera\u00e7\u00e3o, teremos na nova tabela particionada<\/code><\/pre>\n
\ntodos os dados que estavam na antiga, al\u00e9m daqueles que j\u00e1 chegaram ap\u00f3s o renomeio da tabela. A tabela hist\u00f3rico <\/code>n\u00e3o \u00e9 mais necess\u00e1ria. Podemos delet\u00e1-la imediatamente ou, se voc\u00ea estiver paranoico, fazer um backup antes de remov\u00ea-la. history_old <\/code>Todo o processo descrito acima deve ser repetido para as tabelas<\/p>\n
O que precisa ser ajustado nas configura\u00e7\u00f5es do Zabbix Server history_str<\/code>, history_text <\/code>e history_uint<\/code>.<\/p>\n
O que precisa ser corrigido nas configura\u00e7\u00f5es do Zabbix Server<\/h3>\n
\nAgora, o gerenciamento do banco de dados na parte da hist\u00f3ria dos dados ficar\u00e1 sob nossa responsabilidade. Isso significa que o Zabbix n\u00e3o precisar\u00e1 mais excluir dados antigos \u2014 n\u00f3s faremos isso. Para evitar que o Zabbix Server tente limpar os dados sozinho, voc\u00ea precisa acessar a interface web do Zabbix, selecionar no menu 'Administra\u00e7\u00e3o', depois a subcategoria 'Geral', e em seguida, no menu suspenso \u00e0 direita, escolher 'Limpeza da hist\u00f3ria'. Na p\u00e1gina que aparecer, desmarque todas as caixas para o grupo 'Hist\u00f3ria' e clique no bot\u00e3o 'Atualizar'. Isso evitar\u00e1 a limpeza indesejada de tabelas. hist\u00f3ria*<\/code> via housekeeper.<\/p>\n
Note nesta mesma p\u00e1gina o grupo 'Din\u00e2mica de Mudan\u00e7as'. Esta \u00e9 a tabela trends<\/code>, \u00e0 qual prometemos voltar. Se ela tamb\u00e9m se tornou muito grande e precisa de particionamento, desmarque as caixas neste grupo tamb\u00e9m, e ent\u00e3o processe esta tabela exatamente como foi feito para as tabelas hist\u00f3ria*<\/code>.<\/p>\n
Manuten\u00e7\u00e3o cont\u00ednua do banco de dados<\/h3>\n
\nComo mencionado anteriormente, para o funcionamento normal em tabelas particionadas, \u00e9 necess\u00e1rio criar as parti\u00e7\u00f5es a tempo. Isso pode ser feito da seguinte forma:<\/p>\n
ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\nAl\u00e9m disso, como criamos tabelas particionadas e proibimos o Zabbix Server de limp\u00e1-las, agora a exclus\u00e3o de dados antigos \u00e9 nossa responsabilidade. Felizmente, isso n\u00e3o apresenta nenhum problema. \u00c9 feito simplesmente excluindo a parti\u00e7\u00e3o cujos dados n\u00e3o precisamos mais. <\/p>\n
Por exemplo:<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nDiferente dos comandos DELETE FROM com intervalo de datas, o DROP PARTITION \u00e9 executado em poucos segundos, sem sobrecarregar servidor<\/a> e funciona igualmente sem problemas em caso de uso de replica\u00e7\u00e3o MySQL.<\/p>\n
Conclus\u00e3o<\/h3>\n
\nA solu\u00e7\u00e3o descrita \u00e9 comprovada pelo tempo. O volume de dados est\u00e1 crescendo, mas n\u00e3o h\u00e1 uma desacelera\u00e7\u00e3o significativa no desempenho.
\n
Fonte: 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\udd47Uso de particionamento no MySQL para Zabbix com um grande n\u00famero de objetos de monitoramento | ProHoster","description":"Para monitoramento de servidores e servi\u00e7os, temos utilizado com sucesso uma solu\u00e7\u00e3o combinada baseada em Nagios e Munin h\u00e1 bastante tempo.","canonical_url":"https:\/\/prohoster.info\/pt\/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":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/53966","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=53966"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/53966\/revisions"}],"predecessor-version":[{"id":172868,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/53966\/revisions\/172868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=53966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=53966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=53966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}