Периодически( а иногда и достаточно часто) возникает необходимость в тестовых, или иных других целях, поднять пару mysql серверов, а можно и с реплицированием, для откатки или отладки того или иного процесса.
Автоматизировать самому данное телодвижение зачастую нет смысла, поскольку это не так часто необходимо, как хочется.

Продолжение. Начало тут.

Множественные песочницы.
Вы можете создавать множественные песочницы командой
$ make_multiple_sandbox /path/to/tarball
Будут созданы 3 песочницы, одной версии, без репликации.
При необходимости, также есть возможность создания множественной (3 шт) пeсочницы с использованием разных версий mysql

1. Суть оптимизации
2. Page load vs forced refresh
3. Потребуется автоматизация
4. Реализация серверной части
5. Оптимизация серверной части
6. Особенности google app engine
7. Исходный код
8. Резюме

Рассматривается пример реализации для Google App Engine / Python.

Несколько дней назад вышел из строя один из жестких дисков на бюджетном массиве из 16х1ТБ дисков. Уровень массива: RAID 6. Ситуация осложнилась тем, что (как оказалось) ранее также встал кулер на видеокарте этого же сервера, что не было заранее подмечено, и после замены HDD, в результате изменения режима охлаждения корпуса — это стало проявляться в виде зависаний во время синхронизации, что само по себе очень неприятно. Вылилось это в то, что массив перестал автособираться, и были помечены как сбойные еще несколько дисков, и пришлось уже разбираться с ним по-серьёзному, курить вики, мануалы и форумы (форумы — самое полезное, поскольку описывают опыт конкретных людей в конкретных ситуациях).

Есть задачи, которые в рамках реляционных СУБД не имеют универсальных решений и для того чтобы получить хоть какой-то приемлемый результат, приходится придумывать целый набор костылей, который ты потом гордо называешь “Архитектура”. Не так давно мне как раз встретилась именно такая.

Предположим, имеется некоторые сущности А и Б, связанные между собой по принципу One-to-Many. Количество экземпляров данных сущностей достаточно велико. При отображении сущностей для пользователя необходимо применить ряд независимых критериев, как для сущности А так и для сущности Б. Причем результатом применения критериев являются множества достаточно большой мощности — порядка нескольких миллионов записей. Критерии фильтрации и принцип сортировки задается пользователем. Как (я бы ещё спросил: Зачем им миллионы записей на одном экране? — но говорят надо) показать все это пользователю за время 0 секунд?
Решать такие задачи всегда интересно, но их решение сильно зависит от СУБД, под управлением которой крутится твоя база данных. Если у тебя в рукаве козырной туз в виде Oracle, то есть шанс, что эти костыли он подставит сам. Но спустимся на землю — у нас есть только MySQL, так что придется почитать теорию.

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

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

Еще в начале 80-х комитет ISO выделил основные компоненты системы управления сетью. Модель получила название FCAPS. По версии ISO, для успешного управления сетью надо уметь управлять отказами (F), конфигурацией оборудования и сервисов (C ), собирать и обрабатывать статистику по потреблению услуг (A), оценивать производительность (P) и централизованно управлять безопасностью (S). Прошедшие три десятка лет не добавили ничего принципиально нового, и все задачи управления сетью так или иначе прыгают вокруг основных составляющих.

Коммерческие комплексы подобного рода весьма дороги и далеко не безгрешны, а среди open-source систем присутсвовал явный и откровенный пробел, что просто подталкивало на разработку своего велосипеда. В результате обобщения нашего личного опыта по созданию и эксплуатации сетей, после долгих проб и ошибок появилась система NOC

После прочтения на Хабре недавних статей, посвящённых теме безопасности линукс систем, у меня возникло желание поделиться своей точкой зрения на этот вопрос.
Статья в целом рассчитана на начинающих администраторов, поэтому в ней изложены очевидные для хорошего специалиста вещи. Ценные дополнения и замечания приветствуются.
Копи-пейст выдержки из конфиг файлов я почти не буду приводить по трём причинам:

1. Это приведёт с излишнему разрастанию статьи
2. Маны и гугл никто не отменял
3. Пункт 2 очень полезен для развития специалиста

Итак, как повысить безопасность и надёжность сервера (да и рабочей станции) на базе линукс?

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

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

И был бы этот топик топиком-ссылкой, да по необъяснимым причинам не разрешает Хабр в топиках-ссылках указывать авторов, заслуживающих похвал. Так что вот они ссылки:
Описание: artpolikarpov.ru/projects/flags
Архив с флагами: artpolikarpov.ru/projects/flags/flags.zip

Solaris Container (zone). Создание и администрирование. Часть 2

Введение

Технология Solaris Zone (Solaris Container) – это технология, позволяющая разделить на программном уровне Solaris 10 ОС на контейнеры(зоны), почти самостоятельные ОС, которые могут иметь отдельные независимые ресурсы (процессоры, память, дисковое пространство) и своих собственных пользователей.

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

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

Что такое спам? Это 80% почтового трафика в интернете и 20% эффективности. Обычная, грамотно сделанная email рассылка, будет в разы эффективнее. Но даже с самыми благими намерениями всегда есть риск попасть в чистилище папки «Нежелательная почта». Чтобы этого избежать, нужно учитывать ряд нюансов.

Как обычно, саммари в начале статьи и дальше — подробные пояснения. Итак, 9 простых правил:

1. Не занимайтесь спамом
2. Спрашивайте у адресатов согласия на рассылку
3. Обновляйте ваши базы адресов
4. Не используйте покупные базы
5. Храните подтверждения о законности вашей базы
6. Давайте возможность отписаться прямо из рассылки
7. Не повторяйтесь
8. Красиво и грамотно составляйте письма
9. Учитывайте требования спам-фильтров

Архитектура сетей современных операторов связи отлично описана во всяческих мануалах, гайдах по подготовке к сертификациям Cisco и просто умных и хороших книжках. Но многие из них концентрируются именно на MPLS Core с интересными особенностями этой технологии (как то Traffic Engineering, MPLS BGP Multipath и прочее), обходя внимание distribution-access сегмент. Предлагаю поговорить именно об архитектуре сети доступа, принятой в крупных провайдерах. В качестве примеров будем рассматривать сети доступа одного из операторов ОАЭ (назовем его UAE Telecom) и Tier 1 оператора из США (скажем, USA Telecom), с которыми мне посчастливилось работать. По информации, такую же aggregation-access архитектуру имеет IP сеть одного из крупных украинских операторов.

Вчера к нам в офис, а затем и в мою квартиру явились сотрудники Отдела «К», изъяли суммарно 3 системных блока, 2 ноутбука, 1 нетбук (всего 6 компьютеров), предъявив все необходимые бумаги для обыска: постановление на обыск по решению суда, и поручение, дающее право на обыск, обыск проводился с понятыми.

В постановлении на обыск сказано, что причиной является уголовное дело, возбужденное в отношении неустановленного лица, по подозрению в нарушении авторских прав компании Плэйтокс.
Утверждается, что якобы при разработке игры fermer.mobi, использовался программный код игры Мир Теней.

Вечером того же дня мне принесли повестку, явиться на допрос в качестве свидетеля.

То, что контроллеры должны быть «худыми» знают все, но по мере наращивания функционала поддерживать чистоту контроллеров становится все сложнее и сложнее. Мы хотим предложить несколько рекомендаций как содержать свои контроллеры максимально чистыми без ущерба для качества кода.

Продолжая мучить хеши, добытые с antichat (да кому они нужны?) не удержался от создания достаточно быстрого средства, автоматически применяющего рассмотренные в статье методы. Теперь уже в ход пошли видеокарты, и на подбор 60% паролей достаточно было перекура. При скорости перебора over 100 mpwd/s, применении гибридной техники и частотного анализа это не кажется удивительным результатом, что в общем-то наконец должно заставить пересмотреть отношение к способам хранения паролей тех, кто все еще не озаботился этим. Ниже небольшое рассуждение о примененном подходе и, конечно, сама программа.

Проблемы контроля версий баз данных и миграций между версиями уже не раз поднимались как на Хабре (1, 2, 3 и др.), так и в Интернете (преимущественно, англоязычном).

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

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

Вопросы конкурентного доступа к реляционным базам данных встают практически перед любыми разработчиками прикладного программного обеспечения и не только перед ними. Результатом такой востребованности этой области является наличие большого количества созданных архитектурных паттернов. Это позволяет успешно справляться с большой сложностью разработки таких программ. Ниже пойдёт речь о таких рецептах, а также механизмах на которых базируется их реализация. Повествование будет иллюстрироваться примерами кода на Java, но большинство материала не привязано к языку. Цель статьи — описать проблемы конкурентного доступа к реляционным базам данных, в качестве введения в предмет, а не полноценного охвата темы.

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

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

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

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

Задача:

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

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