файл отрицательного размера

Сегодня на одной машине с MySQL-сервером файловая система оказалась забита более 90%..
Зашёл туда, проверил, и оказалось, что почти всё место занято самим MySQL’ем – в директории /var/lib/mysql/ .
Но не просто базой данных, а binlog’ами. Их буквально за сегодня собралось слишком много, и каждый больше гигабайта..

В /etc/my.cnf удаление binlog’ов сконфигурировано через 5 дней:

expire_logs_days=5

Решил удалить все ненужные файлы, но, типа, это не рекомендуется делать вручную в файловой системе, а предлагается удалять из самого MySQL командой

PURGE BINARY LOGS TO 'файл_до_которого_удалить';

Проверил, который из этих файлов используется сейчас самим master-сервером, и какие ещё считываются с него slave-серверами. Везде оказался один и тот же файл, и тогда все прежние я удалил. Теперь в файловой системе занято всего 27%. Выходит, что сама база данных не сильно большая, но почему-то очень много непростых операций сегодня над ней производили..

Оригинал этой записи в личном блоге.

Единственная программа, написанная на похапе, которая мне нравится – это Zabbix!
Сегодня утром он прислал уведомление, что на одном mysql-slave-сервере слишком большая задержка относительно master’а, более двух часов:

Причём там и Slave_IO (скачивание логов с master’а и сохранение их у себя), и Slave_SQL (выполнение операторов из тех логов) всё время работали:

Оригинал этой записи в личном блоге.

Попросили меня сапгрейдить машинку, где живёт крупная база под MySQL, со старенькой 32-битовой CentOS, до 64-битовой. Ну, поставил новую VM, установил туда 64-битовую систему, поставил mysql-server, запустил, всё работает. Потом скопировал конфиг со старой машинки, и тут, как всегда, загадочные грабли:
161130 11:11:54 [ERROR] Can't start server: Bind on TCP/IP port: Permission denied
161130 11:11:54 [ERROR] Do you already have another mysqld server running on port: 3307 ?
161130 11:11:54 [ERROR] Aborting

Проверил netstat’ом – нету никого на 3307. Запустил ещё раз — та же фигня, не работает.

Посмотрел на старую машинку, там mysqld действительно на порту 3307. А поменять на 3306 нельзя, слишком много клиентов придётся переконфигурировать.

Попробовал закомментировать опцию port в конфиге, mysqld нормально запустился на дефолтовом 3306. Вписал port 3306 явно, тоже работает. А если поменять на какой-нибудь другой — 3307, 3308, 4096 — фигвам, не работает, хотя эти порты никакими другими программами не используются.

Ну, кто сразу угадал, что это за хрень, и как её исправить?
Отгадка под катом

Оригинал этой записи в личном блоге.

Как обычно, нарисовалась из практики. Рассмотрим простенькую базу данных типа “классный журнал”. Не в смысле “очень хороший”, а в который школьникам оценки ставят.

Три таблицы. Ученики: students(stud_id, stud_name), предметы: subjects(subj_id, subj_name) и оценки, полученные учениками: scores(stud_id, subj_id, date, score). В реальности тут ещё должна быть таблица классов, привязка учеников к этим классам типа, привязка предметов к классам, но для простоты примера я эти усложнения убрал. Будем считать, что эта база для одного класса, и каждый ученик может получить не более одной оценки в день по данному  предмету.

Задача: для конкретного ученика (по его stud_id) и конкретной даты вывести _полный_ список предметов и оценки, полученные этим учеником за эту дату. То есть, если оценка по данному предмету в этот день есть — вывести её, если нет — вывести прочерк, NULL или ещё что-нибудь, обозначающее отсутствие оценки.

Ограничение: это надо сделать одним запросом. Можно, конечно, сначала взять полный список предметов и для каждого послать отдельный запрос, но это крайне неэффективно. База для конкретности пусть будет MySQL.

На первый взгляд такие задачи решаются с помощью subjects LEFT OUTER JOIN scores. Но… он нормально работает только когда таблицы объединяются по уникальному полю, а в данном случае в таблице scores поле subj_id не уникально. Соответственно, если там есть хоть одна запись для данного предмета (длялюбого ученика за любую дату), то в результате JOIN’а не окажется строк, где score, stud_id и date есть NULL. А если потом к этому результату применить ещё WHERE stud_id=… AND date=…, то даже те строки, где NULLы могли случайно оказаться, будут удалены, поскольку не соответствуют условию.

Вот и как это сделать? Подсказка: это возможно. И на самом деле, оказалось очень просто.

Оригинал этой записи в личном блоге.
Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме.

А вот кто может пояснить, почему вот на такой синтаксис MySQL ругается:

CREATE TABLE `foo` (
  `bar` varchar(32) NOT NULL,
  UNIQUE KEY `bar` (`bar`) USING BTREE
);

а вот такой спокойно принимает:

CREATE TABLE `foo` (
  `bar` varchar(32) NOT NULL,
  UNIQUE KEY `bar` USING BTREE (`bar`)
);

?

Сервер 5.0.51a. Документация говорит нам, что index_type может присутствовать как до списка (index_col_name,…), так и после. Самое смешное, что первый вариант синтаксиса был выдан командой show create table из другого mysql-сервера (5.1.36). Как же так, наши пластинки и к нашему же проигрывателю не подходят?

Оригинал этой записи. Комментировать можно тут или там.