Началось все с того, что в один прекрасный момент ядро прибило демона mysqld и mysql_safe автоматом его перезапустил и все бы хорошо, да только таблицы в БД использовались MyISAM. В итоге пришлось воспользоваться myisamcheck но это совсем другая история. В процессе проверки и починки индексов пострадала одна таблица и было принято решение восстанавливать из бекапов, хорошо, что раз в сутки делаются.

Исходные данные:

• имеем сервер БД с MySQL на борту;
• поврежденную таблицу логов(статистики) чего угодно, что постоянно заполняется и может например не использоваться какое-то время;
• суточный бекап;
• бинарные логи с последнего суточного(полного) бекапа.

Задача:

• сервер должен быть доступен для работы;
• новые данные должны попадать в таблицу;
• восстановить целостность данных.

Ожидаемый результат:
данные в поврежденной таблицы восстановлены без останова базы дынных;
таблица содержит все данные включая текущие.

Как говорит народная мудрость, “админы делятся на две категории: те, которые делают бэкапы, и те, которые уже делают”. В моем случае ответственность за несделанный бэкап упала на разработчика, то есть на меня самого. Данная статья посвящена тому, как найти выход из ситуации, подобной описанной. Надеюсь она будет полезна тем, кто не имея такого опыта, может столкнуться с подобной ситуацией.

Приветствую.
Когда перед мной встал вопрос о переходе с phpmyadmin на любой другой клиент, поддерживающий ssh туннели, я перепробовал много что. Остановился на sqlyog`е. Помимо более менее понятного интерфейса, он умел синхронизировать структуры баз данных. И в общем мирился со всеми его странностями и неудобствами. Однако столкнувшись с тем, что для timestamp полей он ставит по дефолту не «DEFAULT CURRENT_TIMESTAMP», а «DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP» и при этом постоянно врёт, что это просто «DEFAULT CURRENT_TIMESTAMP» (т.е. визуально ON UPDATE нигде не отображает), моё терпение лопнуло. В поисках нового клиента, я открыл для себя гениальное, необычное, удобное и простое решение — HeidiSQL.

Все мы помним хрестоматийное объяснение «что такое индексы в БД и как они облегчают задачи поиска нужных строк». Уверен, у большинства из вас перед глазами встаёт нечто подобное:



И сразу становится очевидно, насколько меньше данных нужно перелопатить для поиска двух-трёх нужных строк. Гениально. Просто. Понятно.

И лично мне всегда казалось, что улучшать эту схему некуда… Пока я не познакомился с кластерными индексами. Оказалось, что всё не так уж радужно с «обычными» индексами.

Итак, что же такое кластерный индекс, чем он лучше некластерного, и как с ним обстоит дело у MySQL.

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

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

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

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

1. 100% защита от SQL инъекций
2. При этом защита очень удобная в применении, делающая код короче, а не длиннее
3. Универсальность, портабельность и простота освоения

Остановлюсь чуть подробнее на каждом из пунктов.

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

Для работы мы используем postgresql + postgis базу данных с данными для всей планеты от osm.org. На диске она занимает около 350 Gb и работает не быстро, да и хранится на обычном винчестере 2Tb 7200rpm, без RAID-a. Т.к. нагрузка на базу данных постепенно растет, было решено ускорить дисковую подсистему, потратив при этом минимум денег. Вариантов было не много:

• купить еще один такой же винчестер и объединить их в raid-0.
• купить небольшой SSD и организовать на нем быстрый кэш:
  
  • dm-cache. Был добавлен в ядро 3.9, ставится просто.
  • bcache. Судя по обзорам самый быстрый. Основной минус — надо форматировать диски перед началом использования. Официально добавлен в ядро 3.10, распространяется как пропатченое ядро 3.9.
  • EnhanceIO. В обзорах я встретил упоминание его, как самого медленного, но простого в использовании.

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

Авторство статьи принадлежит нашему сотруднику Степану Карамышеву skob
Инвайта у него пока нет, потому выкладываю за него.
Далее повествование от его имени.

Данный текст не претендует на гениальность, описанные в нем методики не являются ни панацеей, ни тем более серебряной пулей. Просто в результате исследования, проведенного во время описанной ниже аварии, не было найдено ни одного источника ни на русском, ни на английском (ни, кажется, на немецком) языках, который давал бы подобную информацию. Учтите: информация предоставляется «как есть», ее использование без вдумчивого изучения может быть губительно!

Дедка за red'ку
Народная сказка

Спасибо людям, которые не стесняются поделиться своими мыслями и опытом, пусть даже негативным, по многим важным вопросам организации работы с системами БД. Я наткнулся на статью «Версионная миграция структуры БД: почему так лучше не делать», думал прокомментировать ее, но, рассмотрев дату публикации, решил написать свою. Совершенно очевидно, что автор имел собственное представление о значении и смысле слов, вынесенных им в заголовок. А неточное представление привело к тому, что решалась совсем не та задача. На Хабре довольно давно появились статьи, посвященные организации версионной миграции БД. Они легко обнаруживаются поиском по ключевым словам. Вот в этой статье: ВЕРСИОННАЯ МИГРАЦИЯ СТРУКТУРЫ БАЗЫ ДАННЫХ: ОСНОВНЫЕ ПОДХОДЫ приведено отличное введение в терминологию, задачи и основные методики их решения.
Мне хотелось бы на собственном примере рассказать о тех нежданных проблемах, которые без приглашения внезапно возникли перед нашей группой на одной из моих старых работ, и о том, чего нам тогда не хватало, для быстрого и эффективного разрешения ситуации – в общем, тоже негативный опыт — вдруг кому-то пригодится сейчас или в будущем. Несмотря на то, что в нашей компании мы более широко подходим к решению подобных задач, объединяя их под термином «Управление изменениями в БД», я постараюсь оставаться в поле терминологии из статьи выше.

ОПЫТ ПРОШЛЫХ ЛЕТ – О НЕРЕШЕННЫХ ПРОБЛЕМАХ

В 1997 году перед группой разработчиков, куда я только что вошел, была поставлена задача в течение 3 месяцев создать программный комплекс, который реализует автоматизированную технологию, которая должна была лечь в основу бизнес-деятельности всей компании. Дело давнее и, с вашего разрешения, я не буду углубляться в подробности и детали технологии и бизнес-процессов. Важно то, что нужно было обработать и взаимоувязать ежедневно принимаемые данные, поставляемые в значительных объемах из двух независимых внешних источников, накапливать их в хранилище, с минимальными задержками выдавать ответы по произвольным запросам от наших потребителей – менеджеров внутри компании, выполнять прогноз множества показателей на основе ретроспективного анализа накопленных объемов информации. Эта задача была выполнена, была создана типичная внутренняя корпоративная система, которая работает с той поры и до сих дней, успешно видоизменяясь и дорабатываясь в течение всего этого срока.

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

Вы все еще публикуете проект вручную? Тогда мы идем к вам

Под катом гайдлайн по внедрению CI для .NET проектов «с нуля», включающий:

1. Автоматические ежедневные сборки
2. Уведомления о проблемах
3. Интеграцию с баг-трекером и системой контроля версий
4. Версионирование продукта
5. Версионирование базы данных
6. Автоматизированные выкладки и бекапы

Задача

В своей работе я использую образы Windows Image — всем известные WIM файлы. Подход, которым я хочу сегодня поделиться, прямо противоположен созданию универсального образа с полным наборам софта и сервисов. Ключевым отличием от «Толстого — Thick» подхода является то, что они что в нем находится минимум — только то, что необходимо для запуска puppet agent и дальнейшей установки необходимого софта. Для установки софта я использую chocolatey, все пакеты берутся с chocolatey.org, а для кастомных пакетов имеется репозиторий на сервере в датацентре). Все остальное — ставится потом, в зависимости от требований конфигурации сервера. На мой взгляд это добавляет намного больше гибкости, и все что нужно, фактически, добавлять сервис паки и большие обновления. И вот сегодня — как раз тот день: «Пора бы обновить образ». Если говорить точнее, то сегодня нужно создать образ с нуля для Windows Server 2012 Standard с определенного ISOшника.

Если вы являетесь rails-разработчиком, то вы наверняка слышали про Unicorn, http-сервер, способный одновременно обрабатывать множество запросов.

Для обеспечения параллельности Unicorn использует создание множества процессов. Т.к. созданные (форкнутые) процессы являются копиями друг друга, это значит, что rails-приложение должно быть потокобезопасным.

Это здорово, т.к. нам тяжело быть уверенными, что наш код является потокобезопасным. Если мы не можем быть уверены в этом, то ни о параллельных веб-серверах, таких как Puma, ни даже об альтернативных реализациях Ruby, реализующих параллелизм, таких как JRuby и Rubinius, не может быть и речи.

Поэтому Unicorn предоставляет нашим rails-приложениям параллельность даже если они не потокобезопасны. Однако, это требует определенной платы. Rails-приложения, запускаемые на Unicorn’е требуют гораздо больше памяти. Не обращая никакого внимания на потребление памяти вашим приложением, вы можете в итоге обнаружить, что ваш облачный сервер перегружен.

В этой статье мы рассмотрим несколько способов использования параллельности Unicorn'а, при этом контролируя количество потребляемой памяти.

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

Метод отлова спама, который я опишу в этой статье, дает эффективность, примерно 97%. Он опробован на 10-ке серверов, и работает уже как минимум лет семь.

Обновляю 4-летний список бесплатных сервисов для управления доменами

Primary + Secondary

Сервис	Кол-во NS	Кол-во доменов	Типы записей	TTL	Доп. фичи
pdd.yandex.ru	2	50	AAAA и SRV	+	Есть API
cloudflare.com	2	неограниченное	AAAA, SRV, SPF, LOC	+
2ns.info	4	неограниченное	AAAA и SRV	+	Есть экспорт. Показывает регистратора, дату регистрации домена, дату окончания регистрации, тИЦ. By leonid239
dns.he.net	5	50	все	+	NS доступны по IPv6. Свой DDNS-сервис
www.netbreeze.net/dns	3	1	AAAA и SRV	+	Есть API
entrydns.net	3	неограниченное	AAAA и SRV	+	Есть свой DDNS-сервис, REST-api

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



Пример и код в jsFiddle.

Этот текст является переводом статьи 'Stop Being Cute and Clever' небезызвестного (по крайней мере, в Python-комьюнити) Армина Ронахера.

Последние дни в свободное время я занимался созданием планировщика. Идея была простой: создать некий клон worldtime buddy c использованием AngularJS и некоторых других JavaScript-библиотек.

И знаете что? Это было отнюдь не весело. Я уже давно так сильно не злился, работая над чем-либо, а это что-то значит, потому что обычно я быстро высказываю своё недовольство (прошу прощения у моих фолловеров в Twitter).

Я регулярно использую JavaScript, но мне редко приходилось сталкиваться с кодом других людей. Обычно я привязан только к jQuery, underscore и иногда AngularJS. Однако в этот раз я пошел ва-банк и решил использовать различные сторонние библиотеки.

Для данного проекта я использовал jQuery, без которого уже нельзя обойтись (да и зачем?), и AngularJS с некоторыми UI-компонентами (angular-ui и биндинги к jQuery UI). Для работы с часовыми поясами использовался moment.js.

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

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

Здравствуй, Хабр!

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

• Раздача на Рутрекере (видео+слайды)
• Прямые ссылки на видеофайлы: первая лекция, вторая, третья, четвертая, пятая, шестая и седьмая
• Прямая ссылка на слайды (zip-архив pdf-файлов)
• Подкаст в iTunes
• Плейлист на YouTube
• Форум курса

Первая лекция: Введение в JavaScript, немного истории, числа (тут есть ошибка: функция toFixed округляет значения).



Остальное – под катом.

Итак. Абстрагируемся от мощных высокотехнологичных постов на хабре — я им апплодирую. Но жизнь рядового программиста начинается с его рабочего места, куда он неустанно возвращается снова и снова.
Если это про вас. Если вы хотите добавить в свою жизнь немного изюминки — отвлекитесь на минутку, расслабьтесь и открывайте хабракат!