Все потоки

MySQL *

Свободная реляционная СУБД

СтатьиПостыНовостиАвторыКомпании

unwrecker 18 окт 2012 в 11:34

Percona XtraDB Cluster. Установка и тестирование

8 мин

42K

Туториал

Recovery Mode

Некоторое время назад я задумался о повышении доступности серверов своего проекта. Всё решалось относительно легко за исключением MySQL базы данных. Репликация типа мастер-мастер создаёт проблемы с синхронизацией индексов, а кластерное решение NDBcluster хоть и стремительно развивается, но до сих под не годится для миграции на него готового проекта ввиду большого списка различий и ограничений.

Но есть альтернативное решение под названием Galera Cluster, на котором основан Percona XtraDB Cluster, об установке, настройке и тестировании которого применительно к Ubuntu я и расскажу.

Читать дальше →

+15

DeathCore 15 окт 2012 в 19:55

MySQL. Выбор случайных строк в один запрос

3 мин

19K

Из песочницы

Что имеем?

Есть слабенький ноутбук, таблица на несколько миллионов строк и нужно выбирать разное количество случайных строк в одном запросе. Дальнейшие выборки нас не интересуют.

Таблица(test) имеет следующую структуру:

— pk_id ( первичный ключ )
— id ( поле заполненное разными числами )
— value ( поле заполненной с помощью rand() )

Первичный ключ не имеет дыр и начинается с 1.

Читать дальше →

+36

aeryaguzov 13 окт 2012 в 10:51

mysqlnd

2 мин

49K

mysqlnd — расширение PHP, которое является драйвером для работы с MySQL по умолчанию в PHP 5.4. Оно работает напрямую с MySQL сервером, а значит, MySQL клиент, а также оверхед на работу с ним, больше не требуется!

Читать дальше →

+47

J_o_k_e_R 12 окт 2012 в 13:20

ejabberd: мигрируем с mnesia на mysql

3 мин

12K

Open source * MySQL * Мессенджеры *

Туториал

По мере использования xmpp сервера ejabberd наблюдаю крайний дефицит документации. Каждый чих чуть отклоняющийся от стандартных потребностей приходится придумывать самому, либо собирать по кусочкам из конференций, списков рассылки, комментариев в svn и непосредственно исходников.

С выходом ejabberd 2.1.11, в котором разработчики добавили поддержку ODBC в новых модулях, я столкнулся с проблемой переноса данных из штатной БД mnesia в более подходящую под мои задачи mysql. Когда-то я ее уже решал для других модулей, но лишь отдаленно помню как. Сейчас попробую вспомнить и задокументировать процесс для будущего себя и всех кому это может быть интересно.

Читать дальше →

+14

winduzoid 12 окт 2012 в 05:19

Бесшовная миграция MySQL 5.0 -> Percona Server 5.5 с переразбивкой хранилища

5 мин

19K

Блог компании «Alawar Entertainment»MySQL *

Здравствуйте.

Хочу поделиться опытом миграции боевой базы данных с MySQL 5.0 на Percona Server 5.5 под нагрузкой почти без отрыва от производства.

Опишу вкратце эволюцию нашей базы до текущего состояния

База у нас древняя, пережила несколько апгрейдов MySQL. Начинали с MySQL 3.x. С ростом нагрузки, уже на MySQL 5.0, настроили репликацию и подключили еще один сервер для чтения. Тогда мы это делали стандартными средствами MySQL, без привлечения xtrabackup — полностью блокировали сервер на время создания мастер-дампа и вывешивали на сайтах заглушки.

Затем встала следующая проблема — на томе с данными стало заканчиваться место. Плюс InnoDB-хранилище исторически располагалось в одном файле. Было рассмотрено много вариантов решения. Начиная от размещения базы на iSCSI-томе и заканчивая перетыканием в рейд более емких дисков, расширением на них volume group / logical volume с последующим расширением файловой системы.

В качестве временного варианта решили подключить iSCSI-том из виртуалки под VMWare vCloud (не реклама, честно!). vCloud стоит у нас под боком.

Читать дальше →

+30

0xy 9 окт 2012 в 11:18

DBSlayer прокси на BASH за 5 минут или еще один способ отдать JSON из MySQL

3 мин

9.1K

MySQL * JavaScript *

Туториал

Дело было вечером, делать было нечего, но дурная голова уркам покоя не давала… Данный пост создан как результат чисто-академического интереса. А началось все с того, что при разработке небольшого клиентского приложения для своих нужд, реализованного на Javascript, появилась необходимость взаимодействовать с уже существующей базой, где хранятся искомые данные. База — MySQL. Один из простых способов — реализация серверного скрипта (на PHP или еще каком языке), который по входящим параметрам делает нужный запрос и возвращает результат в JSON виде.

Другой вариант — это DBSlayer-прокси для MySQL. Кто про него не слышал, рассказываю в крадце: был создан в недрах New York Times как средство абстракции и балансирования нагрузки на БД. Подробнее можно почитать на сайте code.nytimes.com/projects/dbslayer/wiki/WhyUseIt. DBSlayer предоставляет API на основе JSON, известен в кругу NodeJS разработчиков.

Но это тоже не наш метод. Под катом приведено простое решение данной задачи на BASH.

Читать дальше →

+38

Milovantsev 9 окт 2012 в 09:50

Оптимизация сложных запросов MySQL

5 мин

70K

Туториал

Из песочницы

Введение

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

Прежде всего хотелось бы ограничить круг рассматриваемых проблем оптимизации «широкими» и большими таблицами. Скажем до 10m записей и размером до 20Gb, с большим количеством изменяемых запросов к ним. Если в вашей в таблице много миллионов записей, каждая размером по 100 байт, и пять несложных возможных запросов к ней — это статья не для Вас. NB: Рассматривается движок MySQL innodb/percona — в дальнейшем просто MySQL.

Читать дальше →

+42

RomanKo 3 окт 2012 в 11:54

Массовая остановка запросов

1 мин

12K

Recovery Mode

В качестве небольшого дополнения к статье Чистка сервера базы данных.

Иногда, в очереди скапливается большое количество запросов к БД, выполнение которых необходимо остановить, не перезапуская MySQL.

Для решения этой проблемы мы используем такой метод:

Получаем список долго выполняемых запросов, в данном случае — SELECTы, выполняемые дольше 100 секунд

SELECT CONCAT('KILL ', id, ';') 
FROM information_schema.processlist 
WHERE 
`info` LIKE('SELECT%') 
AND `time` > 100 
INTO OUTFILE '/tmp/killList.sql';

Собственно, убиваем их:

SOURCE /tmp/killList.sql;

По желанию, можно выбирать запросы по хосту, имени пользователя, базе данных, и т.д.

+22

rednaxi 25 сен 2012 в 12:43

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

4 мин

159K

Предисловие

Скорей всего, матерым системным администраторам статья будет не очень интересна. В первую очередь она ориентирована на новичков, а также на людей, которые столкнулись с подобной проблемой — необходимостью удалить огромное количество файлов из одной папки в ОС Linux (Debian в моем случае), а также с закончившимся местом на диске, когда df -h выдает что почти 30% свободно.

Читать дальше →

+103

Go4Yachiyo 16 сен 2012 в 07:54

Как узнать, стоит ли оптимизировать MySQL запросы?

4 мин

26K

Мне часто задают один и тот же вопрос: как можно находить запросы, которые необходимо оптимизировать. Ведь, скажем, взглянув на отчет pt-query-digest, мы легко найдем медленные запросы или запросы, которые вызывают большую нагрузку на систему — но как мы поймем, существует или нет возможность сделать выполнение этого запроса быстрее? Полный ответ на этот вопрос определенно потребует комплексного анализа, так как существует много путей оптимизации запросов. Однако, существует одна очень полезная метрика, которую вы можете применить — соотношение между количество возвращенных запросом рядов и пройденными рядами.

Читать дальше →

+22

nitso 13 сен 2012 в 07:53

Разукрашиваем вывод mysql-client в консоли

4 мин

31K

Из песочницы

Цвет и звук — это те небольшие радости, которые могут разукрасить и облегчить будние администратора при постоянной работе с консолью. Вывод цветовой информации регулируется так называемым escape-последовательностями, определяющими среди прочего цвет текста и цвет фона.

Общий вид: \033[Xm, где X — это значение параметра (цифра). Например, echo -ne "\033[34mHELLO" выведет синим цветом «HELLO». Таблицу цветов и других доступных параметров (подчеркивание, мигание и т.п.) можно получить в документации man console_codes в разделе «ECMA-48 Set Graphics Rendition». Обычно поддержка цвета интегрирована в само приложение, но mysql-client не входит в число таких программ.

В интернете не раз был встречен вопрос о разукрашивании консоли mysql, но нигде не нашлось рецепта. Только общие слова «может быть состряпать обертку» или «посмотрите в исходном коде». Такой вопрос на StackOverflow жил без ответа более 2 лет! «Жил» было специально употреблено в прошедшем времени, потому что ответ нашелся.

Поможет нам утилита grc. Она доступна в большинстве дистрибутивов и о ней многие знают. Но как обернуть в нее вывод mysql-client?

Читать дальше →

+101

zim32 23 авг 2012 в 08:51

Блокировки в InnoDB (шпаргалка)

2 мин

18K

Recovery Mode

Решил разобраться в вопросе блокировок в InnoDB. Получилась такая вот краткая шпаргалка. Может кому пригодится. Буду благодарен сообществу за найденные неточности

И так, в пределах одной транзакции, после…

Читать дальше →

+46

o_O_Tync 22 авг 2012 в 15:39

Группировка серийных постов, близких по времени

4 мин

1.7K

Добрый день, Хабр!

В проекте столкнулся со следующей задачей: есть новостная лента фотографий, постить в которую пользователи могут только по одной фотографии, а отображать их нужно вместе в виде галереи. Иными словами, все строки выборки нужно логически объединить в несколько «временных окон» по каждому автору и использовать это при отображении.

Напрашивается группировать следующие один за одним посты, однако это не подходит: если два пользователя параллельно и неспешно аплоадят сотню фотографий — в ленту они добавляются поочерёдно, и при просмотре посты будут неприятно чередоваться.

За решением на MySQL

добро пожаловать под кат

+17

KawaiDesu 20 авг 2012 в 15:32

Oracle закручивает гайки

3 мин

4.2K

MySQL * Oracle *

Перевод

Это перевод заметки Исчезновение набора тестов или очередная часть MySQL стала закрытой? (Disappearing test cases or did another part of MySQL just become closed source?)

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

Читать дальше →

+76

FanatPHP 15 авг 2012 в 08:05

Отчёт о попытке получить заявленную эффективность от prepared statements

4 мин

5.1K

MySQL * PHP * Веб-разработка *

Update: из заголовка статьи убрано слово «неудачной». Подробности ниже!

Рассказывая в своей статье о типичных заблуждениях, связанных с защитой от SQL инъекций, среди прочих я отметил тот факт, что серверные подготовленные выражения не работают в PHP по заявленному эффективному сценарию — 1 раз prepare(), потом 1000 раз executе().

Ну, то есть, в теории-то они работают — в пределах одного запуска скрипта. Но много ли вы знаете скриптов (написанных профессиональными программистами), которые выполняют кучу одинаковых запросов? Вот я тоже не знаю. Повторяющихся запросов (каких-нибудь множественных апдейтов) — доли процента, а в массе своей запросы уникальные (в пределах одного скрипта).
Соответственно, для нашего уникального запроса сначала выполняется prepare(), потом — execute(), потом скрипт благополучно умирает, чтобы, запустившись для обработки следующего HTTP запроса, заново выполнять prepare()… Как-то не слишком похоже на оптимизацию. Скорее — наоборот.
Как верно заметили в комментариях, я должен был упомянуть исключения в виде консольных скриптов и демонов, которые долго держат соединение с БД. Однако основная масса PHP скриптов всё же работает на фронтенде, умирая после выполнения пары десятков запросов.

Но неужели нет способа как-то закэшировать подготовленный запрос между запусками?

И тут меня осенила идея!

+26

AlexeyVD 14 авг 2012 в 13:43

Несколько интересных приемов и особенностей работы с MySQL

3 мин

88K

Из песочницы

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

Читать дальше →

+100

FanatPHP 6 авг 2012 в 05:22

Защита от SQL-инъекций в PHP и MySQL

26 мин

260K

MySQL * PHP * Информационная безопасность *

Recovery Mode

К своему удивлению, я не нашёл на Хабре исчерпывающей статьи на тему защиты от инъекций. Поэтому решил написать свою.

Несколько пространный дисклеймер, не имеющий прямого отношения к вопросу

Давайте признаем факт: количество статей (и комментариев) на тему защиты от SQL-инъекций, появившихся на Хабре в последнее время, говорит нам о том, что поляна далеко не так хорошо истоптана, как полагают некоторые. Причём повторение одних и тех же ошибок наводит на мысль, что некоторые заблуждения слишком устойчивы, и требуется не просто перечисление стандартных техник, а подробное объяснение — как они работают и в каких случаях должны применяться (а в каких — нет).

Статья получилась довольно длинной — в ней собраны результаты исследований за несколько лет — но самую важную информацию я постараюсь компактно изложить в самом начале, а более подробные рассуждения и иллюстрации, а так же различные курьёзы и любопытные факты привести в конце. Также я постараюсь окончательно развеять множественные заблуждения и суеверия, связанные с темой защиты от инъекций.

Я не буду пытаться изображать полиглота и писать рекомендации для всех БД и языков разом. Достаточное количество опыта у меня есть только в веб-разработке, на связке PHP/MySQL. Поэтому все практические примеры и рекомендации будут даваться для этих технологий. Тем не менее, изложенные ниже теоретические принципы применимы, разумеется, для любых других языков и СУБД.

Сразу отвечу на стандартное замечание про ORM, Active record и прочие query builders: во-первых, все эти прекрасные инструменты рождаются не по мановению волшебной палочки из пены морской, а пишутся программистами, используя всё тот же грешный SQL. Во-вторых, будем реалистами: перечисленные технологии — хорошо, но на практике сырой SQL постоянно встречается нам в работе — будь то legacy code или развесистый JOIN, который транслировать в ORM — себе дороже. Так что не будем прятать голову в песок и делать вид, что проблемы нет.

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

Ещё только начав интересоваться темой защиты от инъекций, я всегда хотел сформулировать набор правил, который был бы одновременно исчерпывающим и компактным. Со временем мне это удалось:

Правила, соблюдение которых гарантирует нас от инъекций

данные подставляем в запрос только через плейсхолдеры
идентификаторы и ключевые слова подставляем только из белого списка, прописанного в нашем коде.

Всего два пункта.
Разумеется, практическая реализация этих правил нуждается в более подробном освещении.
Но у этого списка есть большое достоинство — он точный и исчерпывающий. В отличие от укоренившихся в массовом сознании правил «прогонять пользовательский ввод через mysql_real_escape_string» или «всегда использовать подготовленные выражения», мой набор правил не является катастрофическим заблуждением (как первое) или неполным (как второе).

Но вперёд, читатель — перейдём уже к подробному разбору.

Читать дальше →

+68

snevsky 1 авг 2012 в 14:43

Сдаем позиции?

3 мин

1.8K

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

Читать дальше →

+62

adamant 1 авг 2012 в 13:28

Еще 12 «рецептов приготовления» MySQL в Битрикс24

9 мин

80K

Блог компании Битрикс24MySQL *

В нашей прошлой статье — «11 «рецептов приготовления» MySQL в Битрикс24» — мы, в основном, рассматривали архитектурные решения: стоит ли использовать облачные сервисы (типа Amazon RDS), какой форк MySQL выбрать и т.п.

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

Еще раз напомню, что эта статья (как и предыдущая) не является универсальным «рецептом» идеальной настройки MySQL на все случаи жизни. :) Такого не бывает. :) Но искренне верю, что она будет полезной для вас для решения отдельных конкретных задач.

А в конце статьи — сюрприз для самых терпеливых читателей. :)

Читать дальше →

+46

3axap4eHko 1 авг 2012 в 06:48

Миграция базы данных в Zend Framework: Akrabat_Db_Schema_Manager

3 мин

8K

MySQL * Zend Framework * PHP *

Из песочницы

В процессе работы над одним огромным проектом на Zend Framework, возникла необходимость миграции баз данных и перемещение между версиями, т.е. кроме update, был необходим так называемый downdate. Немного погуглив натолкнулся на интересную статью Роба Алана (в дальнейшем Автор) «Akrabat_Db_Schema_Manager: Zend Framework database migrations». Данная статья не является переводом оригинала, а скорее синтезом его и возникшей проблемы. Об этом и пойдет разговор.

Читать дальше →

+10

1 2 ...

14

15 16 ...