Почему MySQL записывает сотни 125-байтовых двоичных файлов журнала?
MySQL Master (без подключенных подчиненных) прямо сейчас записывает 125-байтовый файл каждую минуту или около того:
-rw-rw---- 1 mysql mysql 125 2012-12-28 16:46 snapshot-mysql-v2-bin.004876
-rw-rw---- 1 mysql mysql 125 2012-12-28 16:45 snapshot-mysql-v2-bin.004875
-rw-rw---- 1 mysql mysql 125 2012-12-28 16:43 snapshot-mysql-v2-bin.004874
-rw-rw---- 1 mysql mysql 125 2012-12-28 16:41 snapshot-mysql-v2-bin.004873
при записи фактического содержимого двоичного журнала в файл с гораздо меньшим числом:
-rw-rw---- 1 mysql mysql 330755915 2012-12-28 16:48 snapshot-mysql-v2-bin.004472
(и когда этот файл заполняется, он переходит к следующему файлу).
Кроме того, MySQL не записывает имя фактического файла с содержимым (выше 004472) в файл.index, поэтому, когда я подключаю ведомое устройство, оно не может реплицироваться, пока я не отредактирую файл.index вручную.
Версия MySQL 5.1.41-3ubuntu12.10-log.
Есть идеи?
1 ответ
Проблема, по-видимому, заключалась в том, что файл /var/lib/mysql/ibdata1 был заблокирован и недоступен для записи MySQL. Я нашел много записей на этот счет в файле mysql.err, несмотря на то, что сервер MySQL функционировал нормально (и в таблицы InnoDB было добавлено много строк).
Чтобы исправить, мне пришлось убить все экземпляры mysqld (выключения mysqladmin было недостаточно, чтобы их получить), а затем я запустил:
cp -a ibdata1 ibdatanew1
и я отредактировал my.cnf, чтобы он указывал на файл ibdatanew1. Я снова запустил MySQL, сбросил мастер, сбросил логи, и все прошло хорошо за последние 6 часов.
Я до сих пор не понимаю, как заблокированный файл ibdata1 позволил бы MySQL продолжить работу, но, возможно, проблема ibdata1 только возникала в отношении записи двоичного журнала? (Следует отметить, что я привык видеть проблемы с ibdata1 в mysqld.log, а не в журнале mysql.err).