MySQL *

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

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

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

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

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



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

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

Очередной пост в рамках нашей постоянной рубрики «Лекции Технопарка». В этот раз предлагаем вашему вниманию лекции, посвящённые базам данных. Цель курса — получение студентами знаний в области проектирования реляционных баз данных, эффективной работы с базами данных, оптимизации запросов и схем данных, изучение особенностей использования баз данных в проектах с высокой нагрузкой и/или использующих большие массивы данных, 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 с 11-летним стажем, о выступлении на CodeFreeze. Москвичи, обязательно приходите!

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

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

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

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

В не очень далеком прошлом мне пришлось покопаться немного в исходном коде 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, потребуется обновить вручную. Далее последует короткий мануал.

(пример работы протокола HandlerSocket на картинке)

Вступление

В предыдущем проекте возникла потребность в разгрузке базы данных, тогда жизнь и столкнула меня с HandlerSocket`ом.

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


Под катом вас ожидает:

• Новая библиотека для работы с HS, написанная на PHP;
• Сравнение производительности существующих решений + нового;
• Symfony2 bundle для работы с HS;
• Плагины к Munin для мониторинга активности HS;
• Разные мысли вслух и рассказы о «шишках».

Здравствуй, Хабр!
Предлагаю всем желающим вспомнить или познать суть блокировок движка InnoDB в MySQL.


КДПВ: deadlock в исполнении тропической фауны

Бэкапы MySQL бывают 2 основных разновидностей это:

Логический бэкап

Создается текстовый дамп из SQL-запросов, как в mysqldump или Sypex Dumper.

Физический бэкап

Делаются точные копии файлов таблиц, типичный представитель mysqlhotcopy.

В процессе работы над новой версией Sypex Dumper и Sypex Backuper, пришел к еще одному интересному варианту горячего бэкапа MySQL. Который представляет собой, что-то среднее между двумя этими вариантами.

Но для начала рассмотрим основные достоинства и недостатки. Кто вместо теории хочет сразу перейти к практике — внизу поста найдете ссылку на тестовый скрипт.

Расширение mysqlnd появилось ещё в PHP 5.3, но до сих пор малоизвестно среди разработчиков. Однако оно незаменимо, если ваша система основана на MySQL. Если вы хотите узнать, почему это расширение так важно, что оно собой представляет, как его использовать и какие оно даёт преимущества — читайте статью.

Данная статья является переводом первой статьи Rachel McCollin из цикла о данных в WordPress. В ней по полочкам разложена структура данных, типы контента и их взаимосвязь в WordPress. Будет полезна в первую очередь новичкам, но и профессионалы могут найти для себя что-либо новое.

Тема шардинга довольно обширная как с точки зрения программиста, так и с точки зрения администратора БД. Я сейчас хочу коснуться только вопросов генерации уникального ID сущности и алгоритмов выбора шарда.

Здравствуй Хабр!

Периодически возникает необходимость отследить запросы, которые отправляет Ваше приложение к базе данных. К примеру:
— Вам нужно отладить/доработать чужой код;
— Запросы генерируются с помощью сторонней библиотеки (к примеру ActiveRecord), не понятно, какие именно и сколько их;
— Нужно оптимизировать приложение: посмотреть какие запросы и сколько их, посмотреть explain этих запросов.

В этих ситуациях на помощь приходит Beaver mysql logger.

Высокая распространенность баз данных MySQL приводит к её использованию в разнообразных проектах, в том числе, которые требуют безостановочной работы и минимального времени восстановления. Стандартные инструменты, такие как mysqldump неудобен для использования баз данных размер, которых измеряется десятками гигабайт. К сожалению mysqldump вызывает блокировку таблиц, и операция снятия дампа или восстановления базы может занимать далеко не один час, а порой и 5-10 часов.

Благо, к нам на помощь приходит Percona XtraBackup.