MySQL *

Доброго времени суток! В этом посте я хочу показать, как управлять электроникой через Интернет используя Raspberry Pi. Выглядеть это будет примерно вот так.



Краткое описание:

• Серверная программа, которая работает на Raspberry Pi, для того чтобы читать переменные
• Базы данных MySQL для хранения переменных
• Веб-страница Apache2, для того чтобы контролировать переменные

В связи с тем, что накопилось несколько вопросов и решений по работе со временем, решил сделать небольшой обзор.

Предыстория. Выбор БД

Возникла необходимость подружить программу, написанную на VB, с сервером баз данных. Конечно, многочисленные сотоварищи — разработчики ПО могут поставить под сомнение мой выбор базы данных (и будут правы), назвав MSSQL самым простым и очевидным выбором. Но необходимо принять во внимание несколько фактов:

• кроме основной программы (VB), заказчик пожелал иметь возможность использовать и web-интерфейс (php)
• на сервере заказчика установлен MySQL

Привет,

Пока был в отпуске, написал патч для MySQL, позволяющий каждому коннекту владеть несколькими user lock объектами.
Патч доступен здесь:

https://code.launchpad.net/~kostja/percona-server/userlock

Это последний percona-server (5.5) + новые пользовательские локи.

Подробнее про патч написал в своём блоге.
Надеюсь, кому-то окажется полезен. Буду рад комментариям по этой фиче.

Это совсем краткий пост о причинах возникновения Deadlock

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

«Deadlock found when trying to get lock; try restarting transaction»

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

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

В предыдущей статье, мы познакомились с настройкой связки nginx + apache в режиме хостинга и репозиториями dotdeb.
В этой статье мы познакомимся с настройкой backend: PHP, MySQL.

В части PHP мы познакомимся со следующими темами:
— общая настройка PHP
— правильная настройка PHP + Postfix для отправки писем через внутренний SMTP сервер посредством функции mail(),
— настройка кеширования кода и/или данных на основе APC.

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

Кто заинтересовался, добро пожаловать под кат

 

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

Чтобы уменьшить нагрузку на диск и ФС, придумали partitioning, по простому — секционирование. Файл с данными таблицы разрезается по какому-то условию на несколько не больших файлов — партиций. Для случая с логами разумно партиционировать таблицы по полю, содержащему даты события. Часто бывает разумно резать таблицу на partition по году по месяцу или по дням месяца/недели.

Что-то подсказывает что резать придется по полю timestamp.

Многие популярные CMS, как с открытым исходным кодом, так и коммерческие, имеют в своем составе модули бэкапа. Но проблема в том, что чаще всего эти модули делаются по остаточному принципу, и весьма примитивны, не учитывают многих тонкостей создания дампа. Также чаще всего эти модули банально никто не тестируют на большие объемы (прогнали его на тестовой полупустой БД и рады).

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

В данной статье я расскажу, как быстро и довольно просто встроить Sypex Dumper в административную панель своей CMS (форума, блога и т.п.). А также рассмотрим некоторые недокументированные возможности такой интеграции.

Итак, я начал внедрять в своей организации Percona XtraDB Cluster — переводить базы данных с обычного MySQL сервера в кластерную архитектуру.

Коротко о задаче и вводные данные

В кластере нам нужно держать:

• БД нескольких веб-сайтов с пользователями
• БД со статистическими данными этих пользователей
• БД для тикет-систем, систем управления проектами и прочая мелочь

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

Большинство проектов мы держим удаленно в ДЦ, поэтому и кластер будет находится там.
Задача разнести кластер географически по разным дата-центрам не стоит.

Несколько недель назад, я работал над проблемой клиента, который столкнулся с падением производительности БД и даже ее отказами, которые происходили приблизительно каждые 4 недели. Ничего особенного в окружении, в железе или запросах. В сущности, большей частью базы данных была одна таблица, в которой присутствовали, кроме прочего, INT AUTO_INCREMENT PRIMARY KEY и UNIQUE KEY.

Запросы, работающие с этой таблицей, почти все были типа INSERT ... ON DUPLICATE KEY UPDATE (далее — INSERT ODKU), где столбцы, перечисленные в INSERT, соответствовали столбцам с UNIQUE KEY. И выполнялись они с частотой, приблизительно 1500-2000 запросов в секунду, непрерывно 24 часа в сутки. Если вы хороши в математике, то наверное, уже догадались в чем дело.

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

Допустим у Вас есть 3 запроса (q1, q2, q3), каждый запрос выполняется за определенное время (t1, t2, t3), например так:

SELECT 1 AS val, SLEEP(1) AS sleep
SELECT 2 AS val, SLEEP(2) AS sleep
SELECT 3 AS val, SLEEP(3) AS sleep

В случае синхронного выполнения запросов, Вы сможете получить результаты их выполнения через t1 + t2 + t3 (ex: 6 секунд), а в случае асинхронного выполнения запросов уже за max(t1, t2, t3) (ex: 3 секунды)

Примеры работы с асинхронными запросами, а также другие примеры работы с mysqlnd можно найти на github

Некоторое время назад я задумался о повышении доступности серверов своего проекта. Всё решалось относительно легко за исключением 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.