Как стать автором
Обновить

Отказоустойчивая система из мусора

Время на прочтение2 мин
Количество просмотров2.1K
Собственно история была такова.
Для одной фирмы N необходимо было разработать дешевую и надежную систему хранения и обработки данных. Вкратце про данные. Необходимо принимать с клиентов информацию (упущу какую именно, что-то вроде налоговой отчетности) и хранить ее долгие годы. Достаточно часто требовался поиск по этой информации и еще более часто модификация данных, внесенных за последние пару часов. Потеря информации недопустима ни в каких случаях. В том числе при пожаре или землетрясении. Раньше все это делалось на бумаге и хранилось в боооольших папках. Для разбора папок существовал целый отдел бессмысленных и беспощадных людей.

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


Машины представляли собой в основном P3, 128mb оперативной, 16mb видео, 10гб винт. То есть не эталон сервера, мягко говоря.

Бэкапить предлагалось каждую запись – то есть зеркалить БД-сервер и бэкап-сервер. Учитывая объемы данных и неповоротливость машин при первых же тестах это показало неприятно долгие результаты при выборке из БД. Сама база, кстати, не сильно способствовала скорости работы, ибо была полностью нормализирована и компактна.
Так как редактирование записей в БД было достаточно частым, это вызывало неудобство.

После мозгового штурма было решено несколько извратиться.
Итого в итоге:
Сервер А. Основной рабочий сервер системы, хранит Базу за текущие сутки и выполняет всю основную логику.
Сервер В. Второй сервер, хранит базу за все время, не считая текущих суток. В полночь данные из А переливались в В. Тут лежат скрипты составления отчетов по периодам.
Сервер С. Бекап сервер. После перелива в полночь бекапил В, стирал стары й бекап. И зеркалил А во все время работы.

Итого: при потере любого из серверов у нас оставалась вся информация. То есть А+В или С.

Сервер С поселили отдельно на случай ЧП(заказщик тот еще параноик)

На всех серверах стоял линукс, апач и мускул. Основной код написан на PHP, бэкапы на Питоне.

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

Думаю это велосипед или излишняя паранойя, но все работало, выдержало все краштесты и все остались довольны.

%username%, а как бы ты улучшил эту систему?

UPD: посоветуйте, в какой блог перенести.
Теги:
Хабы:
Всего голосов 36: ↑27 и ↓9+18
Комментарии27

Публикации

Истории

Работа

Ближайшие события

7 – 8 ноября
Конференция byteoilgas_conf 2024
МоскваОнлайн
7 – 8 ноября
Конференция «Матемаркетинг»
МоскваОнлайн
15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
22 – 24 ноября
Хакатон «AgroCode Hack Genetics'24»
Онлайн
28 ноября
Конференция «TechRec: ITHR CAMPUS»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань