1 votes

Format de journalisation binaire de MySQL - Remplissage du disque

J'ai une instance de serveur MySQL configurée avec la journalisation binaire activée. Je ne fais pas de réplication, mais les journaux binaires font partie de notre plan de récupération - pour pouvoir rejouer toutes les transactions depuis la dernière sauvegarde complète.

Il n'y a pas si longtemps, on a remarqué sur un système qui fonctionnait depuis quelques semaines que le journal des erreurs MySQL avait atteint la taille incontrôlée de plus de 5 Go. En regardant dans le journal, presque chaque ligne écrite était un avertissement concernant une "déclaration non sécurisée écrite dans le journal binaire".

Comme je ne contrôle pas l'application qui utilise la base de données, je ne suis pas en mesure d'essayer de rendre ces déclarations "sûres". Ainsi, en guise de "solution", j'ai configuré l'application binlog_format a MIXTE plutôt que DÉCLARATION . Ceci indique à MySQL d'utiliser DÉCLARATION dans la mesure du possible, mais se rabattent sur ROW la journalisation avec des déclarations non sécurisées. En procédant ainsi, nous avons réussi à maintenir la taille du journal des erreurs à un niveau gérable.

CEPENDANT, maintenant les journaux binaires augmentent beaucoup plus rapidement qu'avant (j'ai vu 3 GO de fichiers journaux en quelques heures aujourd'hui), sans doute parce que le système écrit maintenant dans le journal pour chaque ligne affectée (pour les instructions "non sûres"), et pour les instructions qui affectent un grand nombre de lignes, eh bien, vous voyez le tableau.

Je me trouve donc entre le marteau et l'enclume. Si j'utilise le DÉCLARATION les journaux binaires sont gérables, mais je reçois un nombre insensé d'avertissements dans le journal des erreurs. Si j'utilise le format MIXTE le journal des erreurs est correct, mais les journaux binaires se développent suffisamment vite pour remplir la partition en une seule journée.

Ce qui m'amène à ma question : quelle est la répercussion exacte de ces déclarations "non sécurisées" ? Comme je l'ai dit, je n'ai pas de réplication en cours, donc je n'ai pas besoin de m'inquiéter qu'un serveur soit exactement le même qu'un autre. Je dois simplement m'assurer que, dans le cas où nous devrions restaurer une sauvegarde, toutes les données sont présentes. L'enregistrement des instructions "non sûres" entraînera-t-il une perte de données, ou y aura-t-il simplement une situation où certaines lignes seront dans un ordre différent (et éventuellement avec des identifiants de clé primaire différents) ? Si ce n'est pas un problème majeur, je peux désactiver les avertissements dans le journal des erreurs (bien que cela semble lourd).

Sinon, je risque d'être obligé de supprimer complètement la journalisation binaire et de me contenter de sauvegardes complètes potentiellement périmées pour le plan de récupération.

Un conseil dans cette situation ?

1voto

silviud Points 2667

Le format de réplication basé sur les rangées utilise en fait plus d'espace disque que celui basé sur les déclarations. C'est simple, car dans le binlog, vous avez toutes les données qui ont été insérées/mises à jour et pas seulement la déclaration. Ainsi, si une instruction demande d'insérer 100 lignes, si binlog_format=STATEMENT n'insérera qu'une seule instruction, mais s'il est ROW, il contiendra toutes les entrées.

Ainsi, pour économiser de l'espace disque, vous devez revenir au mode STATEMENT. En mode mixte, mysql essaiera d'écrire comme une déclaration dans le binlog, mais en cas de déclaration non sécurisée, il reviendra à la base ROW. Dans votre cas, il semble que vous ayez beaucoup d'instructions non sûres et que vous vous retrouviez avec des binlogs basés sur ROW.

Vous pouvez faire plusieurs choses

  • laissez-le en tant que ROW et mettez en place un travail de nettoyage qui purgera les journaux après une période de temps, ceci vous devez calculer ce qui est approprié pour votre système. Avant de supprimer les journaux, vous devez les copier ailleurs pour ne pas les perdre.

  • mettre en œuvre la réplication via un second système et effectuer un travail de nettoyage sur le maître (assurez-vous que l'esclave est synchronisé ou vous risquez de perdre des données).

  • examinez attentivement les déclarations qui sont potentiellement dangereuses, ce qui peut nécessiter une collaboration avec les développeurs de votre application.

0 votes

Merci pour votre contribution. Il semble que la meilleure option pour moi soit d'essayer de les nettoyer périodiquement. Heureusement, j'ai découvert que je peux (généralement) compresser un fichier journal binaire de 1 giga à environ 70 mégas, donc je ne suis pas trop inquiet de manquer d'espace sur ma machine de sauvegarde.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X