Безопасно ли удалять файлы mysql-bin?

У меня есть MM Replication в mysql, и я хочу сжать некоторое свободное место в поле, чтобы удалить ненужные файлы, я наткнулся на эти файлы mysql-bin внутри /var/db/mysql/ Есть сотни таких файлов, как mysql-bin.000123, mysql-bin.000223 и т. д. Я проверил репликацию mysql, выполнив show master status и show slave status, они используют некоторые файлы mysql-bin в определенных позициях, но я думаю, что все остальные файлы bin остатки , которые будут больше не использовать. В этом случае безопасно удалять все эти файлы mysql-bin, кроме тех, на которые в данный момент ссылается репликация?

Если это безопасно удалить, то можно ли что-нибудь сделать, чтобы автоматически удалить эти файлы, когда они не используются?

68 голосов | спросил user18530 27 AMpSat, 27 Apr 2013 00:56:52 +040056Saturday 2013, 00:56:52

3 ответа


108

Пожалуйста, не просто удаляйте их в ОС.

Вы должны позволить mysqld сделать это за вас. Вот как управляет mysqld:

Файл mysql-bin.[index] хранит список всех двоичных журналов, которые mysqld генерировал и автоматически поворачивал. Механизмы для очистки binlogs в сочетании с mysql-bin.[index]:

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

Они очистят все двоичные журналы перед бинлом или меткой времени, которую вы только что указали.

Например, если вы запустите

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

это приведет к удалению всех двоичных журналов до mysql-bin.000223.

Если вы запустите

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

это приведет к удалению всех двоичных журналов до полуночи 3 дня назад.

Если вы хотите, чтобы binlog автоматически повернулся и сохранил 3 дня, просто установите это:

mysql> SET GLOBAL expire_logs_days = 3;

затем добавьте это в /etc/my.cnf

[mysqld]
expire_logs_days=3

и mysqld удалит их для вас

ПОКАЗАТЬ СОБСТВЕННОЕ СОСТОЯНИЕ \ G

Это очень важно. Когда вы запустите SHOW SLAVE STATUS\G, вы увидите два бинарных журнала от мастера:

  • Master_Log_File
  • Relay_Master_Log_File

Когда репликация имеет мало или вообще не отстает, это обычно одно и то же значение. Когда есть много отставаний в репликации, эти значения различны. Просто, чтобы сделать это простым, выберите любой Relay_Master_Log_File и вернитесь к Мастеру и запустите

PURGE BINARY LOGS TO 'Whatever Relay_Master_Log_File Is';

Таким образом, репликация не прерывается.

Дайте ему попробовать !!!

ответил RolandoMySQLDBA 27 AMpSat, 27 Apr 2013 01:57:02 +040057Saturday 2013, 01:57:02
19

Это зависит от стратегии резервного копирования. Одной из основных причин сохранения двоичных журналов является восстановление базы данных «точно в срок». Если ваша база данных сбой и требует восстановления, вы должны восстановить последнюю полную резервную копию, а затем воспроизвести двоичные журналы, начиная с позиции полной резервной копии.

Итак, если вы делаете полную резервную копию каждый день, и у вас есть бинарные журналы на 7 дней, вполне вероятно, что вы можете удалить бинарные журналы за последние 4-6 дней. Вы можете контролировать, сколько дней бинарных журналов хранится в настройках expire_logs_days.

Вы можете удалить двоичные журналы, которые вам не нужны, сначала посмотрев, что является самым старым журналом, который вы хотите сохранить:

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

, а затем в mysql:

mysql> PURGE BINARY LOGS TO 'mysql-bin.XXXXX';
ответил Derek Downey 27 AMpSat, 27 Apr 2013 01:57:13 +040057Saturday 2013, 01:57:13
0

Попробуйте следующее:

RESET MASTER;

, как документ сказал:

  

RESET MASTER позволяет удалять любые файлы двоичных журналов и связанный с ними файл индекса двоичного журнала, возвращая мастер в свое состояние до запуска двоичного журнала.

Это приведет к удалению всех связанных файлов двоичного журнала, которые могут не соответствовать тем, что вы хотите.

ответил Morris 9 J000000Monday18 2018, 04:12:01

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132