MySQL *

Имеем MSSQL 2008
Хотим MySQL версии 5.х

Зачем это может быть нужно?

Для разработчиков на .NET променять MSSQL на MySQL это наверное все равно, что пересесть с мерседеса на что-то по-проще. Как говорится, к хорошему быстро привыкаешь.
Но есть как минимум две причины сделать это

• Сэкономить на лицензиях
• Получить простую master-slave репликацию

Работа с базой MSSQL в нашем случае осуществляется через LINQ провайдер.
При переходе, не хотелось бы терять эту возможность, поэтому для работы с MySQL выбор пал на BLToolkit.

Мигрируем

Самое простое — это переписать код. BLToolkit в отличие от MS-провайдера относится к классу легких ORM, поэтому там немного другие конструкции подключения к базе, но LINQ-выражения останутся теми же.

Думаете осталось перенести данные и все заработает?
Как бы не так.

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

В опубликованной накануне (февраль, 2012) статье озаглавленной «Определение страны по IP: тестируем скорость алгоритмов» сравнивались реализации на уровне БД и нативной реализации. Мы же предлагаем рассмотреть ещё более оптимальный и простой алгоритм, который может быть реализован как в БД, так и в нативном варианте – плоские диапазоны.

Oracle пытается вернуть утраченную карму. Последний релиз MySQL Cluster 7.2 GA вышел под GPL, а 8-нодовый кластер MySQL обрабатывает 1,05 млрд запросов в минуту (17,6 млн в секунду).

Разработчики также заявляют о 70-кратном росте производительности на сложных запросах (JOIN), на самом деле в бэкенде 7.2 интегрирован модуль Memcached и реализованы нативные Memcached API.

Благодаря Memcached теперь MySQL Cluster 7.2 GA способен также получать запросы через NoSQL C++ NDB API.

На тему оптимизации MySQL запросов написано очень много, все знают как оптимизировать SELECT, INSERT, что нужно джоинить по ключу и т.д. и т.п.

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

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

Написание этой статьи навеяно вот этой трилогией: один, два, три. Захотелось добавить свои 0.02$, по использованию трюков и особенностей.

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

В компании, где я работаю, мы используем деперсонализированную базу с Production-a. Ее суммарный объем на данный момент около 30 ГБ. Обфускация ruby скриптом занимала около 6 часов. Ускорение обработки можно добиться, если переписать это все в хранимую процедуру (stored procedure). Но у нас в проекте они запрещены… Увы и ах.

Тогда я задался вопросом: можно ли ускорить процесс по максимуму, деперсонализировать всю базу (или хотя бы полностью одну таблицу) используя только один оператор update? Проблема в том, что некоторые поля д.б. уникальными, а некоторые случайными значениями из списка.

На Хабре уже писалось, что в 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, то эта статья может вам помочь принять конкретные меры и исправлению ситуации с закреплением результата и предотвращением возникновения откровенных проблем с СУБД впоследствии.

Приветствую.
Когда перед мной встал вопрос о переходе с phpmyadmin на любой другой клиент, поддерживающий ssh туннели, я перепробовал много что. Остановился на sqlyog`е. Помимо более менее понятного интерфейса, он умел синхронизировать структуры баз данных. И в общем мирился со всеми его странностями и неудобствами. Однако столкнувшись с тем, что для timestamp полей он ставит по дефолту не «DEFAULT CURRENT_TIMESTAMP», а «DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP» и при этом постоянно врёт, что это просто «DEFAULT CURRENT_TIMESTAMP» (т.е. визуально ON UPDATE нигде не отображает), моё терпение лопнуло. В поисках нового клиента, я открыл для себя гениальное, необычное, удобное и простое решение — HeidiSQL.

Продолжение. Начало тут.

Множественные песочницы.
Вы можете создавать множественные песочницы командой
$ make_multiple_sandbox /path/to/tarball
Будут созданы 3 песочницы, одной версии, без репликации.
При необходимости, также есть возможность создания множественной (3 шт) пeсочницы с использованием разных версий mysql

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

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

Сегодня я расскажу как сделать вашу СУБД MySQL ближе к стандартам PCI DSS. Для начала вот что у нас получится:
Консоль админ пользователя mcshadow

mcshadow:~$mysql --user=mcshadow --password=mike
mysql> select current_user();
+----------------+
| current_user() |
+----------------+
| mike@localhost |
+----------------+
mcshadow:~$mysql --user=mcshadow --password=root
mysql> select current_user();
+----------------+
| current_user() |
+----------------+
| root@localhost |
+----------------+

Доступ возможен как с правами рута, так и с правами смертного пользователя mike.

---

Консоль смертного пользователя mike

mike:~$mysql --user=mcshadow --password=mike
ERROR 1698 (28000): Access denied for user 'mcshadow'@'localhost'

Доступ к БД под администратором невозможен.

---

А тем временем в syslog

^{mysqld: User:mcshadow TRY access from:localhost with privileges:mike
mysqld: User:mcshadow SUCCESS access from:localhost with privileges:mike
mysql: SYSTEM_USER:'mcshadow', MYSQL_USER:'mcshadow', CONNECTION_ID:5, DB_SERVER:'--', DB:'--', COMMAND_RESULT:SUCCESS, QUERY:'select current_user();'
mysqld: User:mcshadow TRY access from:localhost with privileges:root
mysqld: User:mcshadow SUCCESS access from:localhost with privileges:root
mysql: SYSTEM_USER:'mcshadow', MYSQL_USER:'mcshadow', CONNECTION_ID:6, DB_SERVER:'--', DB:'--', COMMAND_RESULT:SUCCESS, QUERY:'select current_user();'
mysqld: User:mcshadow TRY access from:localhost with privileges:mike
mysqld: User:mcshadow FAILED access from:localhost with privileges:mike}

Сегодня во время перевода одного сайта с таблиц 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, и приступаем к изучению её ограниченных, но уже крайне интересных возможностей.