MySQL *

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

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

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

Перейдем к делу.

Если вы интересуетесь ИТ, то вам, скорее всего, не нужно объяснять, что такое MySQL. А если вы знаете про MySQL, то наверняка вам знакомо имя Майкла Монти Видениуса. Для всех остальных и тех, кто подзабыл, напоминаем: MySQL – самая популярная в мире система управления базами данных, а Монти – её создатель, основатель компании MySQL AB, знаменитый ИТ-гуру и просто горячий финский парень.



25 мая, то есть в ближайший понедельник, Монти будет в Москве и проведёт мастер-класс, на котором поделится секретами вывода софтверных проектов на рынок, расскажет о том, как построить карьеру в ИТ, как продать компанию за миллиард долларов и начать всё сначала, приоткроет свои планы на будущее.

Предисловие

Будучи студентом третьего курса, я выбрал тему для курсовой роботы: «Графовые базы данных на примере Neo4j». Так как до того времени я изучал и использовал исключительно реляционные БД, мне было интересно, зачем вообще графовая БД и когда ее способности лучше применять? После просмотра множества сайтов в интернете я обнаружил только теорию и не больше. Так как теория не всегда убедительная и хотелось бы увидеть какую либо статистику, у меня разыгралось любопытство и я решил, что в своей курсовой я этим займусь, а в качестве противника Neo4j я выбрал MySQL.

Итак, кто же выиграет это противостояние?

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

Вместо дисклеймера

На Хабре уже есть множество статей на тему работы с Hibernate, однако, как мне показалось, все они довольно сложные для новичков. Эта статья направлена на разъяснение основ работы с ORM и будет полезна в первую очередь тем, кто только начинает разрабатывать собственные приложения и имеет мало опыта работы с базами данных в общем, и с инструментами, вроде Hibernate, в частности. Матерые разработчики вряд ли найдут в статье для себя что-то новенькое; всех остальных прошу под кат.

Статья является продолжением моей публикации, где рассматривалась возможность установки не нативных для pfsense пакетов на примере FAMP. Такая возможность не лишена недостатков:
1. после инсталляции неродных php-пакетов меняются нативные библиотеки и зависимости, что вызывает php варнинги (можно отключить) и наблюдаются глюки при попытке поставить родное приложение большого размера на этапе проверки контрольной суммы. Причем мелкие приложение pfsense устанавливались без проблем.
2. приходилось создавать недостающие стартовые BSD-скрипты, которые вызывали варнинги в шелле.
3. отсутствие интеграции с вебмордой pfsense.

В данной теме я затрону 6 нормальных форм и методы приведения таблиц в эти формы.

Процесс проектирования БД с использование метода НФ является итерационным и заключается в последовательном переводе отношения из 1НФ в НФ более высокого порядка по определенным правилам. Каждая следующая НФ ограничивается определенным типом функциональных зависимостей и устранением соответствующих аномалий при выполнении операций над отношениями БД, а также сохранении свойств предшествующих НФ.

Здравствуй, Хабрахабр! Меня зовут Бабичев Максим. Это моя первая статья на Хабрахабр, прошу строго не судить.

Нашел на Хабре статью, в которой были базы в двух модификациях: Страны и города и только страны. Также в этих архивах есть небольшие примеры использования таблиц на php.

Сразу хочу сказать, что эта статья рассчитана на новичков, а не на продвинутых гуру.

Очередной пост в рамках нашей постоянной рубрики «Лекции Технопарка». В этот раз предлагаем вашему вниманию лекции, посвящённые базам данных. Цель курса — получение студентами знаний в области проектирования реляционных баз данных, эффективной работы с базами данных, оптимизации запросов и схем данных, изучение особенностей использования баз данных в проектах с высокой нагрузкой и/или использующих большие массивы данных, noSQL и его применение для решения прикладных задач в WWW.

В продолжение цикла статей об «Идеальном» кластере хочу поделиться моим опытом развертывания и настройки Multi-Master кластеров MySQL.

Наш стартап Olery был основан почти 5 лет назад. Мы начали с единственного продукта, Olery Reputation, который был создан агентством, занимавшимся разработкой на Ruby. Всё это выросло в набор различных продуктов. Сегодня у нас есть ещё Olery Feedback, API для Hotel Review Data, виджеты для вставки на сайты и многое другое.

Всего у нас работает 25 приложений (все на Ruby) – некоторые из них в вебе (Rails или Sinatra), но в основном это фоновые приложения для обработки данных.

Хотя нам есть, чем гордиться, есть у нас одна проблема, которая всё время висела где-то в фоне – база данных. Изначально мы использовали MySQL для важных данных (пользователи, контракты, и т.д.) и MongoDB для хранения обзоров и других данных, которые легко можно было бы восстановить в случае утери. Сначала всё работало неплохо, но по мере роста мы начали испытывать проблемы, в особенности с MongoDB. Некоторые из них возникали в сфере взаимодействия БД с приложениями, некоторые – непосредственно у самой БД.

К примеру, в какой-то момент нам надо было удалить миллион документов из MongoDB, а позже вставить. В результате работа базы застопорилась на несколько часов. Потом нам пришлось запускать repairDatabase. И сама починка тоже заняла несколько часов.

Я хочу поделиться со всеми читателями интересной темой, с которой столкнулся совсем недавно, и мне она понравилась. Развитие этой темы доставило мне удовольствие и добавило немного опыта в копилку. Вероятно, многие, а может и нет, сталкивались с пулом соединений БД. После ознакомления с этой интересной опцией мне захотелось написать статью и поделиться ею с вами. Возможно, статья получится немного длинной, но я думаю, что данный пост кому-то все же будет интересно почитать, и его заинтересует данная тема. Может быть наработки с этой статьи кто-то использует в своем проекте, в любом случае, мне будет интересно ее писать и рассказывать ее вам.

Хочу поделиться еще одним способом решения такой проблемы, как запуск более одного mysql-server на одном linux-сервере. Я думаю, что некоторые из вас уже пробовали это делать, запуская руками, например, вот так:

 mysqld_safe --defaults-file=...my2.cnf... &

Я считаю этот подход не совсем правильным хотя бы потому, что корректно завершить такой запущенный mysql-сервер получится не всегда. Можно ещё, конечно, использовать mysqld_multi, но лично я предпочитаю полностью «изолировать» друг от друга инстансы. Именно поэтому я и предлагаю вам в своей публикации использовать в помощь систему инициализации.

Всем привет!

У нас большая удача! Нам удалось договориться с Дмитрием Леневым, уникальным специалистом, разработчиком MySQL Server с 11-летним стажем, о выступлении на CodeFreeze. Москвичи, обязательно приходите!

Итак, в четверг, 19 февраля, в 20:00 в московском офисе Mail.Ru состоится встреча CodeFreeze с Дмитрием Леневым, разработчиком MySQL Server в компании Oracle. Доклад будет посвящен обзору менеджеров блокировок данных в MySQL (включая блокировки метаданных, таблиц и блокировок InnoDB). Будут обсуждаться предназначение каждого из видов и архитектура этих менеджеров.

Коллеги, хочу предложить вам описание решений которые помогли в проекте по миграции большого приложения с SQL Server на MariaDB / MySQL.

Возможно, это кому то поможет в аналогичном проекте.

В преддверии своего доклада на конференции PGCONF.RUSSIA 2015 я поделюсь некоторыми наблюдениями о важных различиях между СУБД MySQL и PostgreSQL. Этот материал будет полезен всем тем, кого уже не устраивают возможности и особенности MySQL, а также тем, кто делает первые шаги в Postgres. Конечно, не стоит рассматривать этот пост как исчерпывающий список различий, но для принятия решения в пользу той или иной СУБД его будет вполне достаточно.

Не так давно я начал изучать фреймворк Spring и понял, что количество материала на русском языке ограниченно буквально парой стоящих статей. По быстрому пробежав, я захотел сделать что-то более интересное, но с наскоку взять не удалось. Пришлось погуглить по поводу нескольких вопросов касательно взаимодействия Spring и Hibernate. Неожиданно я наткнулся на блог достаточно интересного разработчика Mark Serrano aka krams. Теперь вместе с вами я хотел бы начать цикл статей-переводов, а так же свое обучение в мире Spring.
Spring — Hibernate: ассоциация один ко многим
Приступим…

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

Начнем с такого интересного типа, как ENUM.

mysql> CREATE TABLE enums(a ENUM('c', 'a', 'b'), b INT, KEY(a));
Query OK, 0 rows affected (0.36 sec)

mysql> INSERT INTO enums VALUES('a', 1), ('b', 1), ('c', 1);
Query OK, 3 rows affected (0.05 sec)
Records: 3  Duplicates: 0  Warnings: 0

Итак, у нас есть таблица, в ней есть два столбца. У первого, a, тип ENUM, у второго, b, INT. В таблице три строки, у всех трех значение b равно 1. Интересно, чему равны минимальный и максимальный элементы в столбце a?

mysql> SELECT MIN(a), MAX(a) FROM enums;
+--------+--------+
| MIN(a) | MAX(a) |
+--------+--------+
| c      | b      |
+--------+--------+
1 row in set (0.00 sec)

Кажется странным, было бы разумно, если бы самым маленьким был 'a', а самым большим — 'c'.
А что если выбрать минимум и максимум только среди тех строк, где b = 1? То есть, среди всех строк?

mysql> SELECT MIN(a), MAX(a) FROM enums WHERE b = 1;
+--------+--------+
| MIN(a) | MAX(a) |
+--------+--------+
| a      | c      |
+--------+--------+
1 row in set (0.00 sec)

Вот так мы заставили MySQL поменять свое мнение о том, как сравнивать поля в ENUM, просто добавив предикат.
Разгадка такого поведения заключается в том, что в первом случае MySQL использует индекс, а во втором нет. Это, конечно, не объясняет, почему MySQL сравнивает ENUMы по разному для сортировки в индексе, и при обычном сравнении.

Второй пример проще и лаконичнее:

mysql> (SELECT * FROM moo LIMIT 1) LIMIT 2;
+------+
| a    |
+------+
|    1 |
|    2 |
+------+
2 rows in set (0.00 sec)

Когда я показал этот запрос своему коллеге, который занимается разработкой парсера SQL, его вопрос был не «почему этот запрос возвращает две строки», а «как надо написать SQL парсер так, чтобы такой запрос был валидным, без того, чтобы написать правило, специально разрешающее такой запрос».

Интересно, что далеко не любой SELECT в скобках сработает, в частности, UNION в скобках — это синтаксическая ошибка:

mysql> (SELECT * FROM moo UNION ALL SELECT * FROM hru) LIMIT 2;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'UNION ALL SELECT * FROM hru) LIMIT 2' at line 1

Еще несколько интересных примеров под катом

Введение

Назрел апгрейд системы web сервера, на котором с 2007 года крутился сайт интернет-магазина на самописном движке mysql 5.1 + perl + apache + nginx.

Как обычно, при росте посещаемости все стало упираться в базу данных. Стал выбирать новую базу данных, совместимую с текущей. Выбирал из Mysql 5.5, Mysql 5.6, MariaDB 10, Percona Sever 5.6.

После длительного изучения бенчмарков стало понятно, что нужно тестировать производительность на реальных данных. Во-первых, в большинстве случаев сравнивали InnoDB и XtraDB, во-вторых — тестировали в основном бешеные нагрузки на монстр-серверах, интересные мне показатели находились на узеньком участке графика, где обычно ничего не было понятно.

Предисловие

Как многие помнят, в этом году был принят закон, в связи с которым поменялись часовые пояса в России с 26 октября 2014 г. Само собой, сразу после принятия закона я поставил в календарь напоминалку на начало октября «обязательно обновить tzdata». Каково же было моё удивление, когда я не обнаружил апдейтов tzdata в debian и ubuntu. Решил подождать еще немного, наткнулся на открытые баги в дистрибутивах (Ubuntu #1377813, #1371758, Debian #761267). Коллеги усиленно напоминали о необходимости апдейтов, но мейнтейнеры не реагировали. Чтобы не устроить себе аврал к концу месяца, решил собрать пакеты и проапдейтить вручную. Важно отметить, что информацию о зонах в некотором софте, например, в MySQL, потребуется обновить вручную. Далее последует короткий мануал.