Je MM réplication MySQL, et je veux presser un peu d' espace libre dans la zone soit la suppression des fichiers inutiles, je suis tombé sur ces mysql-binfichiers à l' intérieur /var/db/mysql/Il y a des centaines de ces fichiers comme mysql-bin.000123, mysql-bin.000223etc. J'ai vérifié la réplication MySQL en faisant show master statuset show slave statusils sont utiliser certains fichiers mysql-bin à certaines positions, mais je suppose que tous les autres fichiers bin sont des restes qui ne seront plus utilisés. Dans ce cas, est-il prudent de supprimer tous les fichiers mysql-bin sauf ceux sur lesquels la réplication pointe actuellement?

Si la suppression est sûre, puis-je faire quelque chose pour supprimer automatiquement 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 le faire 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 journaux de travaux associés mysql-bin.[index]sont les suivants:

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

Ceci effacera 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 tu cours

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 disparaisse automatiquement et tourne pendant 3 jours, définissez simplement ceci:

mysql> SET GLOBAL expire_logs_days = 3;

puis ajoutez ceci à /etc/my.cnf

[mysqld]
expire_logs_days=3

et mysqld les effacera pour vous

AFFICHER LE STATUT SLAVE \ G

C'est critique. Lorsque vous exécutez 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, elles ont généralement la même valeur. Lorsqu'il y a beaucoup de retard de réplication, ces valeurs sont différentes. Simplement pour simplifier les choses, choisissez ce qui Relay_Master_Log_Fileest, puis retournez voir le Maître et exécutez

PURGE BINARY LOGS TO 'Whatever Relay_Master_Log_File Is';

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

Cela dépend vraiment de votre stratégie de sauvegarde. L'une des principales raisons de conserver les journaux binaires est de restaurer votre base de données à un «point dans le temps». Si votre base de données tombe en panne et nécessite une restauration, vous devez restaurer la dernière sauvegarde complète, puis lire les journaux binaires en commençant par la position de la sauvegarde complète.

Ainsi, si vous effectuez une sauvegarde complète tous les jours et que vous disposez de 7 journaux binaires, il est probable que vous puissiez supprimer les journaux des 4 ou 6 derniers jours. Vous pouvez contrôler combien de jours de journaux binaires sont conservés avec le expire_logs_daysparamètre.

Vous pouvez supprimer les journaux binaires dont vous n'avez pas besoin en consultant d'abord le journal le plus ancien que vous souhaitez conserver:

ls -lh /path/to/binary/logs/mysql-bin.0*

et ensuite dans mysql:

mysql> PURGE BINARY LOGS TO 'mysql-bin.XXXXX';

Essaye ça:

RESET MASTER;

comme le dit le document :

RESET MASTER vous permet de supprimer tous les fichiers journaux binaires et leur fichier d’index de journal binaire associé, ramenant ainsi le maître à son état précédent le démarrage de la journalisation binaire.

Cela supprimera tous les fichiers journaux binaires associés, ce qui peut ne pas être ce que vous voulez.