MySQL → немного о SELECT… FOR UPDATE и GET_LOCK
Для примера рассмотрим такой случай.
У нас есть MySQL база, в которой есть таблица queue. В эту таблицу поступают задания для выполнения.
Задания должны распределяться между процессами. Одна и та же задача не должна попасть к разным процессам.
У нас есть MySQL база, в которой есть таблица queue. В эту таблицу поступают задания для выполнения.
Задания должны распределяться между процессами. Одна и та же задача не должна попасть к разным процессам.
Nginx → MySQL в NGINX: использование блокирующих библиотек в неблокирующем сервере из песочницы
Как известно, при разработке высоконагруженных серверов часто применяется событийная модель работы с сокетами. Ключевым компонентом системы при этом является epoll (во FreeBSD и Windows есть свои решения, но остановимся на Линуксе). Функция epoll_wait, будучи единственным блокирующим вызовом, возвращает нам информацию обо всех сетевых событиях, которые нас интересуют. Подобным образом, конечно, работает и всем известный сервер NGINX.
Событийная модель программирования делает код весьма своеобразным, как будто выворачивает его наизнанку. Но эта проблема не так страшна. Есть другая проблема — использование в событийно-ориентированном коде существующих библиотек, изначально не предназначенных для него. Если подобная библиотека делает блокирующие вызовы (например, connect, recv и т.д.), вся событийная модель может потерять смысл т.к. окончания одного такого вызова будут ждать все остальные клиенты, что совершенно неприемлемо, если вы пишете серьезный продукт.
Событийная модель программирования делает код весьма своеобразным, как будто выворачивает его наизнанку. Но эта проблема не так страшна. Есть другая проблема — использование в событийно-ориентированном коде существующих библиотек, изначально не предназначенных для него. Если подобная библиотека делает блокирующие вызовы (например, connect, recv и т.д.), вся событийная модель может потерять смысл т.к. окончания одного такого вызова будут ждать все остальные клиенты, что совершенно неприемлемо, если вы пишете серьезный продукт.
Системное администрирование → BIND: храним зоны в mysql (Dynamically Loadable Zones — BIND DLZ)
Возможность Berkeley Internet Name Daemon (BIND) хранить зоны DNS в базе mysql не шибко известна и крайне плохо документирована. Документация заморожена на моменте включения отдельного патча DLZ в основную ветку BIND, а это BIND 9.4.* и 2005-2006 годы. Я постараюсь хотя бы частично восполнить этот пробел, выложив под хабракатом рабочие на данный момент инструкции с примерами. Мое описание совершенно не претендует на полноту, но простейшую зону прописать позволит.Отдельно хочу заметить, что DLZ поддерживает не только mysql, список поддерживаемых хранилищ также под хабракатом.
Веб-разработка → Open Server — профессиональный инструмент веб-разработчика под Windows
Хочу представить вам новый профессиональный инструмент для веб-разработки под Windows.
Open Server — это портативный локальный WAMP/WNMP сервер, имеющий многофункциональную управляющую программу и большой выбор подключаемых компонентов. Представленный пакет программ не является очередной любительской сборкой собранной «на коленке», это первый полноценный профессиональный инструмент, созданный специально для веб-разработчиков с учётом их рекомендаций и пожеланий.
Если вы всё еще используете Denwer, Xampp, Vertrigo и т.д. или предпочитаете устанавливать все компоненты сервера раздельно — добро пожаловать под кат.
Open Server — это портативный локальный WAMP/WNMP сервер, имеющий многофункциональную управляющую программу и большой выбор подключаемых компонентов. Представленный пакет программ не является очередной любительской сборкой собранной «на коленке», это первый полноценный профессиональный инструмент, созданный специально для веб-разработчиков с учётом их рекомендаций и пожеланий.
Если вы всё еще используете Denwer, Xampp, Vertrigo и т.д. или предпочитаете устанавливать все компоненты сервера раздельно — добро пожаловать под кат.
MySQL → Резервное копирование данных в MySQL
Резервное копирование базы данных — это такая штука, которую вечно приходится настраивать для уже работающих проектов прямо на «живых» production-серверах.
Подобная ситуация легко объяснима. В самом начале любой проект еще пуст и там просто нечего копировать. В фазе бурного развития головы немногочисленных разработчиков заняты исключительно прикручиванием фишек и рюшек, а также фиксом критических багов с дедлайном «позавчера». И только когда проект «взлетит», приходит осознание, что главная ценность системы — это накопленная база данных, и её сбой станет катастрофой.
Эта обзорная статья — для тех, чьи проекты уже достигли этой точки, но жареный петух ещё не клюнул.
Подобная ситуация легко объяснима. В самом начале любой проект еще пуст и там просто нечего копировать. В фазе бурного развития головы немногочисленных разработчиков заняты исключительно прикручиванием фишек и рюшек, а также фиксом критических багов с дедлайном «позавчера». И только когда проект «взлетит», приходит осознание, что главная ценность системы — это накопленная база данных, и её сбой станет катастрофой.
Эта обзорная статья — для тех, чьи проекты уже достигли этой точки, но жареный петух ещё не клюнул.
MySQL → Как перекодировать latin1 в кириллицу из песочницы
Мне каждый раз задают один и тот же вопрос, спрашивают об одном и том же: «Как перекодировать кракозябры из базы данных, хранящей строки в кодировке latin1 в нормальную кириллицу (windows-1251) или utf-8».
Ниже я постараюсь наиболее полно ответить на данный вопрос, а также приведу кусок кода на PHP, который однозначно решает проблему.
Ниже я постараюсь наиболее полно ответить на данный вопрос, а также приведу кусок кода на PHP, который однозначно решает проблему.
Системное администрирование → Проверка репликации MySQL master-master через Zabbix из песочницы
После настройки MySQL репликации master-master, следующий логический шаг это настройка проверки этой системы. Читая туториалы по интернету стало ясно, что подобная репликация — дело популярное, а слетает оно на раз два три. Поэтому решил вставить проверку — а работает ли репликация до сих пор, или что-нибудь произошло и все слетело.
Первые же несколько гугл запросов показали, что верить «SHOW SLAVE STATUS\G» нельзя: Штука хорошая, но врет часто и помногу. Немного подумав, я пришел к следующему решению:
Первые же несколько гугл запросов показали, что верить «SHOW SLAVE STATUS\G» нельзя: Штука хорошая, но врет часто и помногу. Немного подумав, я пришел к следующему решению:
Блог компании Badoo → Clustered index в InnoDB и оптимизация запросов
В последнее время в сети часто пишут про clustered index в InnoDB и таблицах MySQL, но, несмотря на это, на практике используют довольно редко.В данной статье мы покажем на двух реальных примерах, как мы оптимизировали достаточно сложные системы Badoo, основываясь на понимании принципов работы clustered index.
Clustered index – форма организации таблицы в файле. В InnoDB данные хранятся в дереве, в таком же, в котором лежат обычные B-TREE ключи. Таблица InnoDB сама по себе уже является большим B-TREE. В качестве значений ключа используется clustered index. Согласно документации, в качестве clustered index выбирается PRIMARY KEY. Если PRIMARY KEY отсутствует – выбирается первый UNIQUE KEY. Если и такого нет, то используется внутренний 6-тибайтный код.
Что же вытекает из такой организации данных на диске?
Node.JS → Маршрутизация запросов в Autodafé
Autodafé — node.js фреймворк, начало читайте в этой статье: habrahabr.ru/blogs/nodejs/135089/
Основная часть статьи будет посвящена перенаправлению запросов в autodafe, формированию URL и т. п. Но для начала мне бы хотелось осветить общие принципы работы приложения с подключенными клиентами, для того чтобы было понятнее какую часть рабочего процесса мы будем обсуждать.
Начнем со схемы, отображающей подключение клиентов к приложению:
На схеме можно увидеть несколько пользователей, которые пользуются различными устройствами и различными браузерами, которые в свою очередь подключаются к приложению по различным протоколам. (В данный момент к autodafe можно подключиться только по http и websockets)
В приложении каждому подключению соответствует один Client. Client создается для каждого http запроса и подключения по websockets. Клиенты с одинаковым идентификатором сессии принадлежат одному экземпляру Session. Обычно одна сессия в приложение соответствует одному браузеру.
Ну и для логического завершения на схеме приведен компонент “users”, который позволяет привязать различные сессии, прошедшие специальную авторизацию к одному объекту UserIdentity. Таким образом в приложении каждый объект UserIdentity соотносится к одному реальному пользователю.
Основная часть статьи будет посвящена перенаправлению запросов в autodafe, формированию URL и т. п. Но для начала мне бы хотелось осветить общие принципы работы приложения с подключенными клиентами, для того чтобы было понятнее какую часть рабочего процесса мы будем обсуждать.
Откуда берется пыль
Начнем со схемы, отображающей подключение клиентов к приложению:
На схеме можно увидеть несколько пользователей, которые пользуются различными устройствами и различными браузерами, которые в свою очередь подключаются к приложению по различным протоколам. (В данный момент к autodafe можно подключиться только по http и websockets)
В приложении каждому подключению соответствует один Client. Client создается для каждого http запроса и подключения по websockets. Клиенты с одинаковым идентификатором сессии принадлежат одному экземпляру Session. Обычно одна сессия в приложение соответствует одному браузеру.
Ну и для логического завершения на схеме приведен компонент “users”, который позволяет привязать различные сессии, прошедшие специальную авторизацию к одному объекту UserIdentity. Таким образом в приложении каждый объект UserIdentity соотносится к одному реальному пользователю.
Python → MySQLdb vs UTF-8
Традиционная проблема базы и кодировок.
При подключении обычным способом к MySQL через MySQLdb во время записи строк в кодировке utf-8 имеем неприятный момент: UnicodeEncodeError: 'latin-1' codec can't encode characters in position 0-5: ordinal not in range(256) Как не игрался с кодировками — либо это исключение, либо крякозябры в базе. Кроме того, даже чтение записей выдает не то, что ожидалось увидеть…
При подключении обычным способом к MySQL через MySQLdb во время записи строк в кодировке utf-8 имеем неприятный момент: UnicodeEncodeError: 'latin-1' codec can't encode characters in position 0-5: ordinal not in range(256) Как не игрался с кодировками — либо это исключение, либо крякозябры в базе. Кроме того, даже чтение записей выдает не то, что ожидалось увидеть…