MySQL *

Очень короткая статья, про то как можно использовать HAProxy в качестве балансировщика для multi-master серверов MySQL, таких как Percona или Galera.

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

Для тех кто не знаком с HAProxy, цитата о предназначении продукта:

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

От слов к делу, установка и настройка очень просты:

Опустим долгое вступление о необходимости резервного копирования данных. Все мы знаем, что бэкапы нужно делать. Те, кто активно использует Zabbix, тоже задумываются о возможности восстановления базы в случае её повреждения либо переноса на новый сервер и т.д. Понятно, что оптимальным вариантом для этого является репликация, но далеко не каждая организация может себе это позволить. Я покажу, каким образом проблема резервного копирования Zabbix решена у нас. Если кому-то интересно, прошу под кат.

Эта статья задумана мной как сборник некоторых интересных моментов по использованию и оптимизации SQL запросов в БД MySQL, на мой взгляд, плохо освещенных в интернете. Так, из статьи вы узнаете о конструкции with rollup, и о том, как переписать подзапросы in и not in на join'ы, а так же обновление и удаление данных в нескольких таблицах — одним запросом, и многое другое. Начнем по порядку.

Привет Хабравчанам!

Рады сообщить, что в ближайшие две недели офис Jelastic навестят настоящие гуру IT-индустрии: Майкл Видениус (или Монти, создатель MySQL), Расмус Лердорф («отец PHP») и Марк Збиковски (бывший архитектор компании Microsoft).


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

Недавно мне поставили такую задачу: Есть много коммивояжеров с ноутбуками которые разъезжают по стране и что-то кому-то впаривают продают.
Т.к. им нужны актуальные данные о наличии товара и ценах, время от времени они подключаются к центральному серверу через интернет и сливают себе обновленные данные.

Условия к задаче:
— Частота и периодичность выхода на связь коммивояжеров неизвестна, ровно как и длительность.
— Должно все работать максимально надежно, потому как коммивояжеры они такие «коммивояжеры».
— Решение должно быть на базе Mysql master-slave replication.

Выводы из условия:

— Для надежности, на стороне клиента(slave) минимум настроек, никаких скриптов по крону, все должно быть внутри mysql.
— Т.к. неизвестно когда и с какой периодичностью будут подключаться к master базе коммивояжеры, binlog на мастере нужно хранить так долго пока все slave не скачают его себе.

Решение:
— Информировать мастер, какие slave и сколько уже «скачали». А точнее в какой позиции самый «ленивый» slave.
— Все остальные binlog можно смело удалять.

Продолжение.
Предыдущие части: 1-3, 4-6, 7-9

10. Нормализация баз данных

Указания для правильного проектирования реляционных баз данных изложены в реляционной модели данных. Они собраны в 5 групп, которые называются нормальными формами. Первая нормальная форма представляет самый низкий уровень нормализации баз данных. Пятый уровень представляет высший уровень нормализации.

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

Выкладываю продолжение перевода цикла статей для новичков.
В настоящих и последующих — больше информации по существу.
Начало — здесь.

4. ТАБЛИЦЫ И ПЕРВИЧНЫЕ КЛЮЧИ

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



В таблице имеются 6 уроков. Все 6 – разные, но для каждого урока значения одинаковых полей хранятся в таблице, а именно: tutorial_id (идентификатор урока), title (заголовок)и category (категория). Tutorial_id – первичный ключ таблицы уроков. Первичный ключ – это значение, которое уникально для каждой записи в таблице.
В таблице клиентов ниже customer_id – первичный ключ. В данном случае первичный ключ – также уникальное значение (число) для каждой записи.

Проект phpMyAdmin появился на свет 9 сентября 1998 года, когда Тобиас Ратшиллер (Ratschiller) выпустил версию 0.9.0. За прошедшие полтора десятилетия phpMyAdmin превратился в один из основных инструментов для администрирования MySQL и других MySQL-подобных баз данных, с гордостью пишут разработчики.

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

К созданию phpMyAdmin причастны 669 разработчиков, а основная группа разработчиков выросла с 1 до 9 человек.

Хотим «phpMyAdmin» (читай web GUI) для ноды

Отсутствие универсальных веб-интерфейсов для управления распространенными СУБД, несколько усложняет освоение Node.js, а разворачивать рядом другой веб-сервер и другой язык с инфраструктурой, ой как не хочется. Открывать порты и управлять базами, подключаясь с другого сервера или со своего рабочего компьютера — это и неудобно и есть соображения безопасности. Поэтому мы решили включить такой инструмент в платформу для веб-приложений Impress, которую анонсировали, о которой я немного писал и которая доступна в открытом коде для всеобщей пользы. Задумка такая: реализовать простой и удобный унифицированный интерфейс для СУБД, которые чаще всего применяются в связке с Node.js, позаботиться о быстром развертывании (просто скопировать папку) и независимости от среды. В бета-версии уже поддерживаются MySQL, MongoDB и в скором времени очередь дойдет до PostgreSQL и Oracle.

Можно ли уместить исходники MySQL клиента на 1 страничке формата A4? Оказывается, если 8 кеглем (в принципе читаемо) и после обфускации, то можно! А если нормальный код без обфускации и 10 кеглем, то таки нельзя: надо целых 6 страничек.

В ходе работы над всяким у меня тут случайно получился крохотный, но работающий MySQL клиент размером чуть больше 1000 строк. Стало интересно, насколько компактнее можно сделать. Потратил половину воскресенья, изолировал и минимизировал код. В результате появился nanomysql, CLI клиент для MySQL, полные исходники которого занимают чуть менее 380 строк и примерно 10500 байт, и при этом компилируются и работают под Linux, Windows, MacOS. Написано на C++ с абсолютным минимумом STL.

Скриншоты, циферки и прочие подробности уикэнд-сумасшествия по изготовлению наноклиента под катом.

Хорошей пятницы, Хабр!

Как многим известно, отдельные баги в MySQL не закрываются годами. Но все еще открытому багу #20786 «mysqldump always includes AUTO_INCREMENT» повезло больше других — на свое семилетие он хотя бы получил самый настоящий праздничный торт!




Страница бага

Один из основателей проекта MySQL, на данный момент руководитель проекта MariaDB Ульф Майкл Видениус (известный также под ником Монти), в интервью ITwire говорит о том, что Oracle провалила попытку сделать MySQL успешным продуктом, потому что компания не понимает открытую модель разработки программ.

«Это не в их ДНК», — добавил Монти. — «Они пытаются вести открытый проект в той же самой манере, в которой они разрабатывают свои закрытые продукты, и это большая ошибка».

Недавно Red Hat — компания, стоящая за разработкой наиболее популярного дистрибутива Linux в бизнес-секторе — объявила о том, что в готовящейся к выпуску седьмой версии дистрибутива MySQL будет заменён его ответвлением — MariaDB. За разработкой MariaDB в свою очередь стоит Монти и основанная им компания Monty Program Ab. Ранее под крылышко компании Монти также перешла компания SkySQL, вместе с другим со-основателем MySQL Дэвидом Аксмарком, который работал там как технический директор. Третий со-основатель MySQL — Алан Лариссон — также работает с Монти, помогая ему по мере необходимости своим советом и делом.

Монти сказал, что главной причиной, по которой всё больше и больше людей и компаний стали искать альтернативу MySQL, послужил в большей степени тот факт, что Oracle ясно показала своё нежелание играть по принятым правилам с сообществом разработчиков. Объясняя своё мнение, он добавил, что «выделение открытого ядра MySQL, удаление тестов из исходных кодов (большей частью для того, чтобы усложнить жизнь проектам, основанным на его кодовой базе) и создание таких условий, при которых никто не может разрабатывать MySQL с теми же привилегиями, какие есть у Oracle», это всё послужило причиной сложившейся ситуации.

Разработчики MariaDB случайно заметили, что в промежутке от MySQL 5.5.30 к MySQL 5.5.31 в проекте изменился текст лицензии во всех файлах в каталоге man/.

Вместо прежнего краткого текста «Эта документация является свободным программным обеспечением, вы можете распространять и/или изменять её только под условиями лицензии GNU General Public License, как опубликовано Фондом свободного ПО; версия 2 лицензии» теперь длинное описание, начинающееся со слов: «Это программное обеспечение и сопутствующая документация распространяются под лицензионным соглашением, которое содержит ограничения на использование и разглашение и защищена законами об интеллектуальной собственности».

Любой программист создающий нагруженные проекты с тысячами пользователей, когда-либо задавался вопросом, как он может улучшить SQL запросы и экономить многие сотни долларов. Процесс анализа обычно начинается с профилирования и отладки кода приложения. Далее происходит процесс оптимизации SQL запросов, для этого можно воспользоваться встроенными иструментами MySQL сервера. Например логирование MySQL в файл. Но рано или поздно начинаешь понимать, что это не удобно.

Недавно я потратил кучу времени, пытаясь понять, почему один запрос выдает такой странный результат. На MariaDB он выдавал явно некорректный результат, а на старом добром MySQL не выполнялся вовсе. Т.е. запрос запускался, но дождаться его завершения не удавалось. Для того чтобы разобраться, в чем же дело, пришлось провести небольшое исследование. Но давайте обо всем по порядку.

После выхода новой версии MySQL в начале этого года, многие задумались о том стоит ли на неё переходить с более старых версий. Чтобы ответить на этот вопрос для себя, вначале необходимо понять, а что именно даст этот переход. В этой статье я постараюсь осветить новые, важные для меня, фичи, которые были включены в дистрибутив новой версии, анализ их производительности и работоспособность новой версии, а так же необходимость что-то менять в коде в связи в переписанным оптимизатором. Так как объем изменений действительно очень велик, для каждого пункта дам ссылку на оригинальную статью по тестирования производительности и исключу из описания воду.

При разработке современного сайта часто возникает необходимость реализовать функционал вывода близлежащих географических точек. Самым оптимальным способом решения этой задачи является перекладывание работы по реализации определения точек на плечи MySQL. Если конкретней, то нам будут нужны возможности пространственных расширений MySQL (до версии 5.0.16 эти расширения были доступны только для MyISAM, более поздние версии MySQL поддерживают работу пространственных расширений с InnoDB, NDB, BDB и ARCHIVE).

Расстояние между точками будет вычисляться по формуле гаверсинусов. Формула позволяет получать расстояние между точками с очень низкой погрешностью (величина погрешности прямо пропорциональна расстоянию между точками, и не превышает 10-20 километров при вычислении очень больших расстояний, например между штаб-квартирой Google в Калифорнии (37.422045, -122.084347) и оперным театром в Сиднее, Австралия (-33.856553, 151.214696)).

При разработке современных веб-приложений сложно недооценить пользу от использования систем контроля версий. Применительно к файлам разрабатываемого продукта, мы способны отследить любые этапы производства в любой момент, начиная с первой ревизии. Инструменты, помогающие нам в этом, на сегодняшний день популяризированы, считаются хорошим тоном при разработке, а во многих случаях успешное производство без их применения невозможно в принципе. А какие возможности мы имеем, когда возникает необходимость проследить изменения не в файлах, а в базах данных проекта? Под катом я поделюсь информацией о существующих средствах, с которыми мне пришлось ознакомиться.

Разбираясь как работает та или иная CMS приходится использовать различные инструменты, облегчающие работу.
Наиболее интересная тема — это работа с баз(ой|ами) данных. Естественно для изучения запросов и результатов запросов нужно использовать что-то универсальное. Что-то, что будет работать стабильно как с известным движком, так и с самописной системой.
Предположим у вас оказалась система управления контентом и вам необходимо посмотреть как реализовано добавление новых пользователей или смена паролей.

Большинство инструментов позволяющих мониторить работу с БД являются платными [раз, два]. Я хотел что-то более легкое и удобное, поэтому выбрал mysql-proxy. Хотя возможности утилиты гораздо шире чем мне требуется, я опишу лишь основное. Работает как под Windows, так и под Unix системами.

Цель данного поста — помочь начинающему разработчику быстро освоится и спроектировать простенькую базу с помощью инструмента для визуального проектирования баз данных MySQL Workbench от компании Oracle и получить её ER-модель и SQL-дамп.