{"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\/fr\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","title":{"rendered":"Utilisation du partitionnement dans MySQL pour Zabbix avec un grand nombre d'objets de surveillance","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pour le monitoring des serveurs et des services, nous utilisons depuis longtemps et avec succ\u00e8s une solution combin\u00e9e bas\u00e9e sur Nagios et Munin. Cependant, cette combinaison pr\u00e9sente un certain nombre d'inconv\u00e9nients, c'est pourquoi nous, comme beaucoup d'autres, exploitons activement Zabbix<\/a><\/noindex>. Dans cet article, nous allons expliquer comment, avec un minimum d'efforts, r\u00e9soudre le probl\u00e8me de performance lors de l'augmentation du nombre de m\u00e9triques collect\u00e9es et de la croissance des volumes de la base de donn\u00e9es MySQL.
\n<\/a><\/noindex><\/p>\n

Probl\u00e8mes d'utilisation de la base de donn\u00e9es MySQL avec Zabbix<\/h3>\n

\nTant que la base de donn\u00e9es \u00e9tait petite et que le nombre de m\u00e9triques stock\u00e9es \u00e9tait limit\u00e9, tout allait tr\u00e8s bien. Le processus de nettoyage automatique, qui est lanc\u00e9 par le serveur Zabbix, a r\u00e9ussi \u00e0 supprimer les enregistrements obsol\u00e8tes de la base de donn\u00e9es, emp\u00eachant ainsi sa croissance. Cependant, d\u00e8s que le nombre de m\u00e9triques collect\u00e9es a augment\u00e9 et que le volume de la base de donn\u00e9es a atteint une certaine taille, la situation s'est d\u00e9grad\u00e9e. Le processus de nettoyage a cess\u00e9 de pouvoir supprimer les donn\u00e9es dans le temps imparti, laissant des donn\u00e9es anciennes dans la base de donn\u00e9es. Pendant l'ex\u00e9cution du processus de nettoyage, une charge accrue sur le serveur Zabbix se produisait, qui pouvait persister longtemps. Il est devenu clair qu'il fallait trouver une solution \u00e0 cette situation.<\/p>\n

C'est un probl\u00e8me bien connu, pratiquement tous ceux qui ont travaill\u00e9 avec de grands volumes de surveillance sur Zabbix ont rencontr\u00e9 la m\u00eame chose. Il existait \u00e9galement plusieurs solutions : par exemple, remplacer MySQL par PostgreSQL ou m\u00eame Elasticsearch, mais la solution la plus simple et \u00e9prouv\u00e9e a \u00e9t\u00e9 de passer au partitionnement des tables contenant les donn\u00e9es des m\u00e9triques dans la base de donn\u00e9es MySQL. Nous avons d\u00e9cid\u00e9 de suivre cette voie.<\/p>\n

Passage des tables MySQL classiques aux tables partitionn\u00e9es<\/h3>\n

\nZabbix est bien document\u00e9 et les tables o\u00f9 il stocke les m\u00e9triques sont connues. Ce sont les tables : history<\/code>, qui stocke des valeurs float, history_str<\/code>, qui stockent des valeurs de cha\u00eene courtes, history_text<\/code>, qui contiennent des valeurs de texte longues et history_uint<\/code>, qui stockent des valeurs enti\u00e8res. Il existe aussi une table trends<\/code>, qui conserve la dynamique des changements, mais que nous avons d\u00e9cid\u00e9 de ne pas toucher, car sa taille est petite et nous y reviendrons un peu plus tard.<\/p>\n

En g\u00e9n\u00e9ral, il \u00e9tait clair quelles tables devaient \u00eatre trait\u00e9es. Nous avons d\u00e9cid\u00e9 de cr\u00e9er des partitions chaque semaine, \u00e0 l'exception de la derni\u00e8re, en nous basant sur les chiffres du mois, c'est-\u00e0-dire en formant quatre partitions par mois : du 1er au 7, du 8 au 14, du 15 au 21 et du 22 au 1 (du mois suivant). La difficult\u00e9 r\u00e9sidait dans le fait qu'il fallait transformer les tables dont nous avions besoin en tables partitionn\u00e9es \u00ab \u00e0 la vol\u00e9e \u00bb, sans interrompre le fonctionnement de Zabbix Server et la collecte des m\u00e9triques.<\/p>\n

\u00c9trangement, la structure m\u00eame des donn\u00e9es des tables nous a aid\u00e9s dans ce processus. Par exemple, la table history <\/code>a la structure suivante :<\/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
\nen outre,<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nComme nous le voyons, chaque m\u00e9trique est finalement inscrite dans une table avec deux champs tr\u00e8s importants et utiles pour nous : itemid<\/b> et clock<\/b>. Ainsi, nous pouvons tout \u00e0 fait cr\u00e9er une table temporaire, par exemple, nomm\u00e9e history_tmp<\/code>, configurer la partition pour elle, puis y transf\u00e9rer toutes les donn\u00e9es de la table history<\/code>, puis renommer la table history<\/code> dans history_old<\/code>, et la table history_tmp<\/code> dans history<\/code>, apr\u00e8s quoi nous pourrions ajouter les donn\u00e9es qui n'ont pas \u00e9t\u00e9 transf\u00e9r\u00e9es depuis history_old<\/code> dans history <\/code>et supprimer. history_old<\/code>Cela peut \u00eatre fait en toute s\u00e9curit\u00e9, nous ne perdrons rien, car les champs mentionn\u00e9s ci-dessus itemid <\/b>et clock <\/b>assurent une liaison entre une m\u00e9trique sp\u00e9cifique et un moment pr\u00e9cis, plut\u00f4t qu'\u00e0 un num\u00e9ro d'ordre quelconque.<\/p>\n
La proc\u00e9dure de transition<\/h3>\n
<\/p>\n
Attention ! Il est fortement conseill\u00e9, avant de commencer toute action, de faire une sauvegarde compl\u00e8te de la base de donn\u00e9es. Nous sommes tous des \u00eatres humains et nous pouvons commettre une erreur dans la saisie des commandes, ce qui peut entra\u00eener une perte de donn\u00e9es. Oui, une sauvegarde ne garantira pas une actualit\u00e9 maximale, mais il vaut mieux en avoir une que rien.<\/p><\/blockquote>\n
 Donc, nous n'\u00e9teignons ni n'arr\u00eatons quoi que ce soit. L'essentiel est que le serveur MySQL dispose de suffisamment d'espace libre sur le disque, c'est-\u00e0-dire que pour chacune des tables mentionn\u00e9es ci-dessus history<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, il doit y avoir au minimum de la place pour cr\u00e9er une table avec le suffixe \u00ab _tmp \u00bb, en tenant compte du fait qu'elle sera de taille \u00e9quivalente \u00e0 celle de la table d'origine.<\/p>\n
Nous ne r\u00e9p\u00e9terons pas tout plusieurs fois pour chacune des tables susmentionn\u00e9es et nous examinerons tout uniquement par l'exemple d'une d'entre elles \u2014 la table history<\/code>.<\/p>\n
Alors, cr\u00e9ons une table vide history_tmp <\/code>sur la base de la structure de la table history<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nCr\u00e9ons les partitions dont nous avons besoin. Par exemple, faisons cela pour un mois. Chaque partition est cr\u00e9\u00e9e sur la base de la r\u00e8gle de partitionnement, qui est fond\u00e9e sur la valeur du champ clock<\/b>, que nous comparons \u00e0 l'horodatage :<\/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
\nCette commande ajoute le partitionnement \u00e0 la table que nous avons cr\u00e9\u00e9e history_tmp<\/code>. Pr\u00e9cisons que les donn\u00e9es dont la valeur du champ clock <\/b>est inf\u00e9rieure \u00e0 \u00ab2019-02-01 00:00:00\u00bb iront dans la partition p20190201<\/i>, ensuite les donn\u00e9es dont la valeur du champ clock<\/b> est sup\u00e9rieure \u00e0 \u00ab2019-02-01 00:00:00\u00bb mais inf\u00e9rieure \u00e0 \u00ab2019-02-07 00:00:00\u00bb iront dans la partition p20190207 <\/i>et ainsi de suite.<\/p>\n
Remarque importante :<\/b> Que se passe-t-il si nous avons des donn\u00e9es dans la table partitionn\u00e9e o\u00f9 la valeur du champ clock est sup\u00e9rieure ou \u00e9gale \u00e0 \u00ab2019-03-01 00:00:00\u00bb ? \u00c9tant donn\u00e9 qu'il n'y a pas de partition appropri\u00e9e pour ces donn\u00e9es, elles ne seront pas ins\u00e9r\u00e9es dans la table et seront perdues. Il est donc n\u00e9cessaire de se rappeler de cr\u00e9er \u00e0 temps des partitions suppl\u00e9mentaires afin d\u2019\u00e9viter de telles pertes de donn\u00e9es (comme expliqu\u00e9 ci-dessous).<\/p><\/blockquote>\n
 Ainsi, la table temporaire est pr\u00eate. Nous allons t\u00e9l\u00e9charger les donn\u00e9es. Ce processus peut prendre un certain temps, mais heureusement, il ne bloque aucune autre requ\u00eate, il suffit donc de faire preuve de patience :<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nLe mot-cl\u00e9 IGNORE lors du premier t\u00e9l\u00e9chargement n'est pas obligatoire, car il n'y a de toute fa\u00e7on pas de donn\u00e9es dans la table, mais il sera n\u00e9cessaire lors du t\u00e9l\u00e9chargement suppl\u00e9mentaire. De plus, cela peut \u00eatre utile si vous avez d\u00fb interrompre ce processus et recommencer.<\/p>\n
Apr\u00e8s un certain temps (peut-\u00eatre m\u00eame plusieurs heures), le premier t\u00e9l\u00e9chargement de donn\u00e9es a \u00e9t\u00e9 effectu\u00e9. Comme vous pouvez le comprendre, la table history_tmp <\/code>contient d\u00e9sormais des donn\u00e9es incompl\u00e8tes de la table history<\/code>, mais seulement celles qui \u00e9taient pr\u00e9sentes au moment du d\u00e9but de l'ex\u00e9cution de la requ\u00eate. Vous avez alors le choix : soit nous faisons un autre passage (si le processus de t\u00e9l\u00e9chargement a dur\u00e9 longtemps), soit nous passons imm\u00e9diatement au renommage des tables, comme mentionn\u00e9 ci-dessus. Commen\u00e7ons par le second passage. Pour cela, nous devons comprendre l'heure de la derni\u00e8re inscription dans history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nSupposons que vous ayez obtenu : 1551045645<\/b>. Maintenant, utilisons la valeur obtenue lors du deuxi\u00e8me passage du chargement des donn\u00e9es :<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nCe passage devrait se terminer beaucoup plus rapidement. Mais si le premier passage durait des heures, et que le deuxi\u00e8me dure aussi longtemps, il serait peut-\u00eatre judicieux de faire un troisi\u00e8me passage, qui s'effectue de mani\u00e8re tout \u00e0 fait similaire au second.<\/p>\n
\u00c0 la fin, nous ex\u00e9cutons \u00e0 nouveau l'op\u00e9ration d'obtention de l'heure de la derni\u00e8re insertion du fichier dans history_tmp<\/code>, en ex\u00e9cutant :<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nSupposons que vous ayez obtenu 1551085645<\/b>. Conservez cette valeur, elle nous sera n\u00e9cessaire pour le compl\u00e9ment de chargement.<\/p>\n
Et maintenant, en fait, lorsque le chargement initial des donn\u00e9es dans history_tmp <\/code>est termin\u00e9, nous allons proc\u00e9der au renommage des tables :<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nNous avons form\u00e9 ce bloc en une seule transaction pour \u00e9viter le moment o\u00f9 des donn\u00e9es sont ins\u00e9r\u00e9es dans une table inexistante, car apr\u00e8s le premier RENAME et avant l'ex\u00e9cution du second RENAME, la table history <\/code>n'existera plus. Mais m\u00eame si des donn\u00e9es arrivent dans la table entre les op\u00e9rations RENAME, et que la table n'existe pas encore (en raison du renommage), nous obtiendrons un petit nombre d'erreurs d'insertion, que nous pouvons ignorer (nous faisons du monitoring, pas une banque). history <\/code>Maintenant, nous avons une nouvelle table<\/p>\n
avec partitionnement, mais il manque des donn\u00e9es qui ont \u00e9t\u00e9 obtenues lors du dernier passage d'insertion des donn\u00e9es dans la table history<\/code> . Mais ces donn\u00e9es, nous les avons dans la table history_tmp<\/code>et nous allons les ajouter maintenant. Pour cela, nous aurons besoin de la valeur pr\u00e9c\u00e9demment sauvegard\u00e9e 1551085645. Pourquoi avons-nous conserv\u00e9 cette valeur, et pas utilis\u00e9 l'heure maximale de chargement d\u00e9j\u00e0 dans la table actuelle ? 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
\u00c0 l'issue de cette op\u00e9ration, nous avons dans la nouvelle table partitionn\u00e9e<\/code><\/pre>\n
\ntoutes les donn\u00e9es qui \u00e9taient dans l'ancienne, plus celles qui sont d\u00e9j\u00e0 arriv\u00e9es apr\u00e8s le renommage de la table. La table history <\/code>n'est plus n\u00e9cessaire. Nous pouvons la supprimer imm\u00e9diatement, ou faire une sauvegarde avant de la supprimer (si vous \u00eates parano\u00efaque). history_old <\/code>Tout le processus d\u00e9crit ci-dessus doit \u00eatre r\u00e9p\u00e9t\u00e9 pour les tables<\/p>\n
Ce qu'il faut corriger dans les param\u00e8tres de Zabbix Server history_str<\/code>, history_text <\/code>et history_uint<\/code>.<\/p>\n
Qu'est-ce qu'il faut corriger dans les param\u00e8tres de Zabbix Server<\/h3>\n
\nLa gestion de la base de donn\u00e9es concernant l'historique des donn\u00e9es est d\u00e9sormais de notre responsabilit\u00e9. Cela signifie que Zabbix n'a plus besoin de supprimer les anciennes donn\u00e9es \u2013 nous nous en occuperons nous-m\u00eames. Pour que Zabbix Server ne tente pas de nettoyer les donn\u00e9es automatiquement, vous devez vous connecter \u00e0 l'interface web de Zabbix, s\u00e9lectionner dans le menu \u00ab Administration \u00bb, puis le sous-menu \u00ab G\u00e9n\u00e9ral \u00bb, et enfin dans le menu d\u00e9roulant \u00e0 droite choisir \u00ab Nettoyage de l'historique \u00bb. Sur la page qui s'affiche, vous devez d\u00e9cocher toutes les cases pour le groupe \u00ab Historique \u00bb et cliquer sur le bouton \u00ab Mettre \u00e0 jour \u00bb. Cela emp\u00eachera le nettoyage inutile des tables. history*<\/code> via housekeeper.<\/p>\n
Notez \u00e9galement sur cette m\u00eame page le groupe \u00ab Dynamique des changements \u00bb. C'est pr\u00e9cis\u00e9ment le tableau trends<\/code>, auquel nous avons promis de revenir. S'il est \u00e9galement devenu trop volumineux et n\u00e9cessite une partition, d\u00e9cochez les cases dans ce groupe, puis traitez ce tableau de la m\u00eame mani\u00e8re que pour les tableaux history*<\/code>.<\/p>\n
Maintenance ult\u00e9rieure de la base de donn\u00e9es<\/h3>\n
\nComme mentionn\u00e9 pr\u00e9c\u00e9demment, pour un bon fonctionnement sur des tableaux partitionn\u00e9s, il est n\u00e9cessaire de cr\u00e9er des partitions \u00e0 temps. Voici comment proc\u00e9der :<\/p>\n
ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\nDe plus, puisque nous avons cr\u00e9\u00e9 des tableaux partitionn\u00e9s et interdit \u00e0 Zabbix Server de les nettoyer, la suppression des anciennes donn\u00e9es est maintenant de notre ressort. Heureusement, il n'y a absolument aucun probl\u00e8me \u00e0 cela. Cela se fait simplement en supprimant la partition dont les donn\u00e9es ne nous sont plus n\u00e9cessaires. <\/p>\n
Par exemple :<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nContrairement aux commandes DELETE FROM avec une sp\u00e9cification de plage de dates, DROP PARTITION s'ex\u00e9cute en quelques secondes, sans aucune charge significative serveur<\/a> et fonctionne tout aussi bien en cas d'utilisation de la r\u00e9plication MySQL.<\/p>\n
Conclusion<\/h3>\n
\nLa solution d\u00e9crite a fait ses preuves. Le volume des donn\u00e9es augmente mais aucune d\u00e9gradation notable des performances n'a \u00e9t\u00e9 constat\u00e9e.
\n
Source : 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\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\udd47 Utilisation du partitionnement dans MySQL pour Zabbix avec un grand nombre d'objets de monitoring | ProHoster","description":"Nous utilisons depuis longtemps et avec succ\u00e8s une solution combin\u00e9e bas\u00e9e sur Nagios et Munin pour le monitoring des serveurs et des services.","canonical_url":"https:\/\/prohoster.info\/fr\/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":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/53966","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=53966"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/53966\/revisions"}],"predecessor-version":[{"id":172868,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/53966\/revisions\/172868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=53966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=53966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=53966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}