MySQL *

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

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

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

Что имеем?

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

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

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

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

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

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

С выходом ejabberd 2.1.11, в котором разработчики добавили поддержку ODBC в новых модулях, я столкнулся с проблемой переноса данных из штатной БД mnesia в более подходящую под мои задачи 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 стоит у нас под боком.

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

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

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

Введение

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

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

А что если к такой замечательной возможности MySQL как создание триггеров, способных записывать старые и новые значения данных при вставке, изменении и удалении записей добавить информацию, которой обладает php скрипт?

Триггеры MySQL знают:
* момент в который происходит изменение
* старое и новое значение

PHP знает:
* кто в данный момент залогинен
* какая страница открыта, с какой перешли
* бравзер
* IP адрес
* POST, GET
* Cookie

Каким же способом можно умудриться записать всю необходимую информацию?

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

Иногда, в очереди скапливается большое количество запросов к БД, выполнение которых необходимо остановить, не перезапуская 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; 

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

Предисловие

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

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

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

После того, как ваши запросы оптимизированы, по идее у вас не должно возникать ситуаций, когда
1. Один запрос блокирует другие
2. Какие-то запросы блокируют друг друга
Мы стремимся к тому, чтобы таких ситуаций не возникало.

Потому хорошим «сторожем работоспособности» будет умный «Query killer»,
который будет отслеживать подозрительные ситуации и освобождать базу данных.

Этот киллер допускает ситуацию, когда БД выполняет пару тяжелых запросов.
Но когда он видит, что начинает появляться много долгих запросов — то начинает принмать меры

Цвет и звук — это те небольшие радости, которые могут разукрасить и облегчить будние администратора при постоянной работе с консолью. Вывод цветовой информации регулируется так называемым 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?

Сегодня, работая над сайтом, мне надо было отделить основной каталог от дополнительного. А в дополнительном каталоге надо было пронумеровать нужные записи в виде «Проект 1», «Проект 2». И тут какой то неведомый зверь не позволил мне сделать это по-быстрому на каком нибудь распространенном языке программирования. Мне захотелось попробовать, а можно ли сделать это используя лишь только средства MySQL?
Насколько я помню, в MySQL есть переменные, например @a. Но поиск в сети, как сделать цикл в MySQL, ничего мне не дал.
Тогда я поразмыслил, ведь мы можем написать

SELECT @i:=@i+1;

А UPDATE в свою очередь проходит каждую запись и заменяет значение по одному.

SELECT @i := 0;
UPDATE `table` SET `name`=CONCAT('Проект ', @i := @i+1) WHERE `type` = 1 ORDER BY `id`;

В итоге мы переименовали записи с типом 1 по порядку следования их ID.
PS: CONCAT объединяет строки.

Возникла у меня необходимость добавить к моему приложению справочники с регионами России и городами. Первая идея которая меня посетила это поискать готовые файлы XML с регионами и городами в интернете, и в случае успеха импортировать данные в мои таблицы. Оптимизма поубавилось когда я начал искать. Конечно никто для меня специально не готовил эти данные, но это и не удивительно. Имея уже однажды опыт импортирования данных из КЛАДР в SqlServer, в структуру отличную от КЛАДР, я решил что придется снова повторить подвиг и организовывать импорт из КЛАДР в мою структуру. Я прекрасно помнил и тот факт что в КЛАДР данные хранятся в таблицах DBF, а импортировать данные

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

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

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

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

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

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

Всем привет.

Более пяти лет я работаю системным администратором в хостинговой компании, обслуживаю более сотни серверов с freebsd и centos. За это время накопилось много самописных скриптов, облегчающих мне жизнь. Этими скриптами хочу поделиться с сообществом, да и выслушать здоровую критику никогда не помешает.

Предыстория.

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

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