Est-il sûr de supprimer les fichiers mysql-bin?

  • J'ai MM Replication dans mysql, et je veux gagner de l'espace libre dans la boîte pour supprimer les fichiers inutiles, je suis tombé sur ceux-ci mysql-bin fichiers à l'intérieur /var/db/mysql/ Il y a des centaines de ces fichiers comme mysql-bin.000123, mysql-bin.000223 etc. J'ai vérifié la réplication mysql en faisant show master status et show slave status ils utilisent des fichiers mysql-bin à certaines positions, mais je suppose que tous les autres fichiers bin sont les restes qui ne sera plus utilisé. Dans ce cas, est-il sûr de supprimer tous ces fichiers mysql-bin à l'exception de ceux vers lesquels la réplication pointe actuellement?

    S'il est sûr de supprimer, puis-je faire quelque chose pour automatiquement supprimer ces fichiers une fois qu'ils ne sont pas utilisés?

  • Veuillez ne pas simplement les supprimer dans le système d'exploitation.

    Vous devez laisser mysqld faire cela pour vous. Voici comment mysqld le gère:

    Le fichier mysql-bin.[index] conserve une liste de tous les journaux binaires que mysqld a générés et tournés automatiquement. Les mécanismes de nettoyage des binlogs en conjonction avec mysql-bin.[index] sont:

    PURGE BINARY LOGS TO 'binlogname';
    PURGE BINARY LOGS BEFORE 'datetimestamp';
    

    Ceux-ci effaceront tous les journaux binaires avant le binlog ou l'horodatage que vous venez de spécifier.

    Par exemple, si vous exécutez

    PURGE BINARY LOGS TO 'mysql-bin.000223';
    

    cela effacera tous les journaux binaires avant mysql-bin.000223.

    Si vous courez

    PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 3 DAY) + INTERVAL 0 SECOND;
    

    cela effacera tous les journaux binaires avant minuit il y a 3 jours.

    Si vous voulez que binlog tourne automatiquement et conserve 3 jours avec, définissez simplement ceci:

    mysql> SET GLOBAL expire_logs_days = 3;
    

    puis ajoutez ceci à /etc/my.cnf

    [mysqld]
    expire_logs_days=3
    

    et mysqld supprimera les journaux pour vous

    AFFICHER LE STATUT DE L'ESCLAVE \ G

    C'est essentiel. Quand tu cours SHOW SLAVE STATUS\G, vous verrez deux journaux binaires du maître:

    • Master_Log_File
    • Relay_Master_Log_File

    Lorsque la réplication a peu ou pas de retard, il s'agit généralement de la même valeur. Lorsqu'il y a beaucoup de retard de réplication, ces valeurs sont différentes. Juste pour faire simple, choisissez ce que vous voulez Relay_Master_Log_File est, et retourne vers le maître et cours

    PURGE BINARY LOGS TO 'Whatever Relay_Master_Log_File Is';
    

    De cette façon, la réplication n'est pas interrompue.

    Veuillez noter une faute de frappe - des traits de soulignement, pas des tirets: `[mysqld] expire_logs_days = 3` (et vous devez inclure la section `[mysqld]`

    @changokun Ce n'est pas une faute de frappe. my.cnf acceptera les tirets. Lancer `SET GLOBAL expire_logs_days = 3;` à partir du client mysql ne les acceptera pas. Exemple dans la documentation MySQL: http://dev.mysql.com/doc/refman/5.5/en/mysqld-option-tables.html

    Cela fonctionne pour moi. Question, quelle est la différence entre ... `mysql> SET GLOBAL expire_logs_days = 3;` et `expire-logs-days = 3` dans` / etc / my.cnf` .. Sont-ils identiques? Est-ce redondant ou non? Ou, il est important d'exécuter `SET GLOBAL ...` puis d'ajouter `expire-logs-days = ..`? Merci.

    Supprimez rapidement tous les journaux, évidemment: `` PURGE BINARY LOGS BEFORE DATE (NOW ()); `` `` pourquoi n'y a-t-il pas de valeurs par défaut saines pour cela? Je n'ai nulle part, jamais explicitement changé la taille du fichier journal à un montant gigantesque. J'avais 10,0 Go de fichiers journaux, après avoir exécuté cette commande, la taille de mon dossier mysql.bin a diminué à 1,6 Go.

Licence sous CC-BY-SA avec attribution


Contenu daté avant 26/06/2020 09:53