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

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

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

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

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

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

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

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

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

Задача:

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

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