MySQL *

Резервное копирование базы данных — это такая штука, которую вечно приходится настраивать для уже работающих проектов прямо на «живых» production-серверах.
Подобная ситуация легко объяснима. В самом начале любой проект еще пуст и там просто нечего копировать. В фазе бурного развития головы немногочисленных разработчиков заняты исключительно прикручиванием фишек и рюшек, а также фиксом критических багов с дедлайном «позавчера». И только когда проект «взлетит», приходит осознание, что главная ценность системы — это накопленная база данных, и её сбой станет катастрофой.
Эта обзорная статья — для тех, чьи проекты уже достигли этой точки, но жареный петух ещё не клюнул.

Введение. В современном мире существует большое количество задач, в рамках которых приходится обрабатывать большие массивы однотипных данных. Яркими примерами являются системы для анализа биржевых котировок, погодных условий, статистики сетевого трафика. Многие из этих систем используют различные реляционные базы данных, в таблицах которых содержатся такие объемы данных, что правильное составление и оптимизация запросов к этим таблицам становится просто необходимым для нормального функционирования системы. В этой статье описаны методы решения ( и сравнительные временные характеристики используемых методов ) нескольких задач по получению данных из таблиц СУБД MySQL, содержащих статистику о проходящем через маршрутизаторы одного из крупных российских сетевых провайдеров сетевом трафике. Интенсивность потока данных, поступающего с главного маршрутизатора такова, что ежесуточно в таблицы базы данных используемой системы мониторинга сетевого трафика поступает в среднем от 400 миллионов до миллиарда записей, содержащих информацию о транзакциях TCP/IP (рассматриваемый маршрутизатор экспортирует данные по протоколу netflow). В качестве СУБД для системы мониторинга используется MySQL.

На Хабре уже писалось, что в MySQL появилась возможность подменять встроенную процедуру аутентификации, загрузив соответствующий плагин. В таком плагине можно реализовать совершенно произвольную политику аутентификации пользователей, полностью уходя от традиционной в MySQL схемы username/password в таблице mysql.user.

А недавно Оракл выпустил PAM authentication plugin. При использовании которого сервер не ищет пароли в mysql.user, а перекладывает задачу аутентификации на PAM, подсистему специально разработанную для решения задач аутентификации в различных приложениях и контекстах, с гибко настраиваемыми правилами и на лету подключаемыми модулями.

К сожалению, у этого плагина есть несколько недостатков. Во-первых, он распространяется только с коммерческой версией MySQL и его исходники закрыты. Во-вторых, он не поддерживает коммуникацию между пользователем и pam-модулем, и единственно возможной остается аутентификация по паролю. Что, как-бы, убивает всю идею.

«А почему-бы...» — подумал я. «Я напишу свой pam-плагин, с блэкджеком и шлюхами!»

Предисловие.

Понадобилось сделать репликацию несколькими мастер-серверами с mysql, чтобы данные со всех них грузились на один слэйв-сервер. Готового решения стандартными средствами не нашлось. Но так как проблема оставалась актуальной, со временем подоспел немного усложненный, но работоспособный вариант c использованием средств самой mysql.

Начиная с версии 5.1 в MySQL появилась такая полезная фича как партиции. Конечно же большинство разработчиков БД сразу не побрезговали ей воспользоваться. Спустя пару лет работы я наконец пожал плоды всей ущербности реализации этой технологии специалистами MySQL AB …

Введение

В жизни любого крупного веб-проекта, особенно на PHP, но, в целом, это касается любого серверного ЯП, пригодного для веб-разработки, обычно наступает понимание, что «так дальше жить нельзя», и что настал момент, когда нужно провести оптимизацию работы сайта, чтобы он перестал тормозить (хотя бы на production).

Интересно, что, как правило, даже тяжелые фреймворки (вроде Symfony или RoR) на «медленных» языках, в production-окружении работают достаточно сносно по скорости, а основные «тормоза» вызываются SQL-запросами и неграмотным кешированием (к примеру, инициализация достаточно сложной и большой конфигурации проекта на Symfony занимает около 80 мс, а времена исполнения страницы, при этом, иногда достигают секунды и более).

Если вы смогли определить, что это — ваш случай, и ваш проект на MySQL, то эта статья может вам помочь принять конкретные меры и исправлению ситуации с закреплением результата и предотвращением возникновения откровенных проблем с СУБД впоследствии.

Периодически( а иногда и достаточно часто) возникает необходимость в тестовых, или иных других целях, поднять пару mysql серверов, а можно и с реплицированием, для откатки или отладки того или иного процесса.
Автоматизировать самому данное телодвижение зачастую нет смысла, поскольку это не так часто необходимо, как хочется.

В недрах документации MySQL на dev.mysql.com я как-то обнаружил упоминание о том, что в случае, если используется MyISAM, можно получить прирост в скорости чтения из таблицы в 5-7 раз, если читать данные из таблицы самостоятельно. Мне довольно долго хотелось проверить этот факт и вот, наконец, у меня дошли руки до того, чтобы это попробовать. Что из этого вышло, читайте под катом

Сегодня во время перевода одного сайта с таблиц MyISAM на InnoDB, у последних выяснилась одна интересна особенность. Запрос на изменение движка для двух таблиц возвращал странную ошибку «Got error 139 from storage engine». После поиска информации на эту тему, было выяснено, что данная ошибка возникает тогда, когда какая-либо строка таблицы не вмещается в половину страницы памяти, с которыми работает MySQL. Страницы эти равны 16 Кб, а половина, стало быть, 8 Кб.

Само по себе ограничение довольно странное, но на первый взгляд кажется трудно достижимым, ведь как известно, MySQL хранят текстовые данные в хранилище, отдельном от табличных строк. Оказалось, что это верно только на половину. На самом деле InnoDB хранит в отдельном хранилище только «излишки», к коим он не относит первые 768 байтов каждого текстового поля. Т.е. любой текст будет отъедать от длины строки столько байт, сколько он содержит, но не больше 768. Несложно подсчитать, что максимальное число текстовых полей длиной от 768 байт, которое можно безопасно хранить в одной таблице — 10. И действительно, если запустить пример, все пройдет гладко. Но стоит увеличить количество полей хотя бы на одно, и мы получим ту же ошибку, что и в начале.

Много камней было брошено в адрес MySQL, ввиду отсутствия возможности трассировки сессий и снятия stats pack отчетов, показывающих какие именно события нагружают базу данных. Начиная с версии 5.5 MySQL наконец-то озадачился необходимостью решения данной проблемы и выставил прототип, который в будущем, возможно, приведет к созданию аналогичных инструментов в MySQL. Сегодняшний мой рассказ будет о таком мощном (к сожалению пока только для разработчиков MySQL) инструменте как PERFORMANCE_SCHEMA. Итак выставляем performance_schema=ON в конфигурационном файле my.cnf, и приступаем к изучению её ограниченных, но уже крайне интересных возможностей.

Есть задачи, которые в рамках реляционных СУБД не имеют универсальных решений и для того чтобы получить хоть какой-то приемлемый результат, приходится придумывать целый набор костылей, который ты потом гордо называешь “Архитектура”. Не так давно мне как раз встретилась именно такая.

Предположим, имеется некоторые сущности А и Б, связанные между собой по принципу One-to-Many. Количество экземпляров данных сущностей достаточно велико. При отображении сущностей для пользователя необходимо применить ряд независимых критериев, как для сущности А так и для сущности Б. Причем результатом применения критериев являются множества достаточно большой мощности — порядка нескольких миллионов записей. Критерии фильтрации и принцип сортировки задается пользователем. Как (я бы ещё спросил: Зачем им миллионы записей на одном экране? — но говорят надо) показать все это пользователю за время 0 секунд?
Решать такие задачи всегда интересно, но их решение сильно зависит от СУБД, под управлением которой крутится твоя база данных. Если у тебя в рукаве козырной туз в виде Oracle, то есть шанс, что эти костыли он подставит сам. Но спустимся на землю — у нас есть только MySQL, так что придется почитать теорию.

Оптимизация явно не является коньком MySQL сервера. Цель данной статьи объяснить разработчикам, которые плотно не работают с базами данных и иногда не понимают, по какой причине запрос, который успешно отрабатывает в других СУБД, в MySQL безбожно тормозит, каким образом оптимизируется конструкция between в MySQL.
MySQL использует rule based оптимизатор. Зачатки cost based оптимизации в нем конечно присутствуют, но не в должной мере, в какой их хотелось бы видеть. По этой причине часто мощности получаемых после применения фильтров множеств вычисляются неверно. Это приводит к ошибкам оптимизатора и выбору неверного плана выполнения. При чем полученные between оптимизации невозможно изменить явным указанием: индексов для выполнения запроса и порядка соединения таблиц.

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

Для тех, кто активно пользуется MySQL, не секрет, что начиная с версии 5.1, MySQL поддерживает события (events). Если вам нужно выполнять запросы или отдельные процедуры по расписанию, а перейти с запуска консоли на встроенный функционал MySQL было лень не было времени,

У MySQL, как известно, есть два недостатка*. Во-первых, язык запросов — SQL. Это исправляется с помощью HandlerSocket, о котором уже были статьи на хабре. Во-вторых, у него нет встроенного яваскрипта.

_{* — на самом деле, это шутка. недостатков у MySQL вряд ли именно два, но и заключаются они совершенно не в том, в чём я написал. а отсутствие яваскрипта — это, конечно, не недостаток. однако, если представить, что у MySQL нет SQL интерфейса вообще, то сравнивать его (как NoSQL-решение) нам придётся, в частности, с MongoDB, в котором интерпретатор яваскрипта есть.}

Итак, я начал работы по второму направлению и уже получил кое-какой результат:

Началось все с того, что в один прекрасный момент ядро прибило демона mysqld и mysql_safe автоматом его перезапустил и все бы хорошо, да только таблицы в БД использовались MyISAM. В итоге пришлось воспользоваться myisamcheck но это совсем другая история. В процессе проверки и починки индексов пострадала одна таблица и было принято решение восстанавливать из бекапов, хорошо, что раз в сутки делаются.

Исходные данные:

• имеем сервер БД с MySQL на борту;
• поврежденную таблицу логов(статистики) чего угодно, что постоянно заполняется и может например не использоваться какое-то время;
• суточный бекап;
• бинарные логи с последнего суточного(полного) бекапа.

Задача:

• сервер должен быть доступен для работы;
• новые данные должны попадать в таблицу;
• восстановить целостность данных.

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

Я думаю, ни для кого не секрет, что JOIN считается достаточно дорогой операцией, и многих начинающих программистов (которые юзают MySQL) любят запугивать, что JOIN — это плохо, и лучше всего обойтись без них, если есть возможность.

Давайте исследуем этот вопрос более подробно и посмотрим, действительно ли JOIN — это плохо, и когда вообще стоит задумываться об этом.

Если в Вашем проекте есть таблицы размер которых исчисляется гигабайтами, а для того чтобы поменять структуру такой таблицы вам на несколько часов приходится останавливать все сервисы — эта статья будет для Вас.

Дано: таблица размером в несколько десятков гигабайт данных. Задача — изменить структуру таблицы.

В MySQL есть такой специальный режим, предназначенный для введения в базу неправильных данных. Например, чтобы вместо 20000000000 вставлять в INT-поле 2147483647. Или наполнять базу несуществующими датами. Или обрезанными строками. Ну или мало ли для чего этот режим может тебе пригодится.

Режим этот называется «обычный режим».

Офсайт СУБД MySQL вчера взломан двумя злоумышленниками через банальное SQL injection. По ссылке опубликован отчёт о взломе и выложены некоторые части внутренней структуры базы данных, дамп паролей и т.д.

Vulnerable Target : mysql.com/customers/view/index.html?id=1170
Host IP : 213.136.52.29
Web Server : Apache/2.2.15 (Fedora)
Powered-by : PHP/5.2.13
Injection Type : MySQL Blind
Current DB : web

Хуже всего, что пароли юзеров уже пошли в разработку, в том числе уже расшифрован пароль директора по разработке продуктов MySQL (всего четыре символа), пароли многочисленных админов на форуме и т.д. Так что если у вас есть аккаунт на MySQL.com, то рекомендуется срочно сменить данные регистрации.

Кстати, те же два злоумышленника одновременно взломали и Sun.com тем же способом.