Comments 27
ситуация знакомая. Я в подобных случаях шел к начальнику, брал его за рукав и доверительно глядя в глаза объяснял, что, да, в принципе можно все поднять и на этом железе и оно даже будет как-то работать. Но! Железо старое, запчастей на него нет и не будет уже никогда. Любая самая малая поломка все равно приведет к необходимости покупки новой техники, но уже в авральном режиме, без выделенного заранее финансирования и под непрерывные вопли пользователей. Оно надо? А если не надо, то вот, пожалуйста, смета и счет, вот тут распишитесь, да. Как это зачем? Это запасные кулеры, память, процессор и диски. А то ведь и новая техника рано или поздно устареет…
+16
Полностью с вами согласен)
Примерно так же мы все это и описывали клиенту, но, однако, эффекта не возымело.
К тому же заказывали именно разработку ПО для этого всего. Так что требовать другое железо было несколько не актуально…
Примерно так же мы все это и описывали клиенту, но, однако, эффекта не возымело.
К тому же заказывали именно разработку ПО для этого всего. Так что требовать другое железо было несколько не актуально…
+1
Вот! Слова не мальчика — но мужа. :)
Творчество «из говна и палок» оставим «мальчикам». :)
Творчество «из говна и палок» оставим «мальчикам». :)
-4
UFO just landed and posted this here
было бы круто если бы вы еще хранили избыточные бекапы на комьпютерах пользователей в зашифрованном виде и все это по p2p распространялось
+3
UFO just landed and posted this here
Сервер А. Основной рабочий сервер системы, хранит Базу за текущие сутки и выполняет всю основную логику.
Сервер В. Второй сервер, хранит базу за все время, не считая текущих суток. В полночь данные из А переливались в В. Тут лежат скрипты составления отчетов по периодам.
Сервер С. Бекап сервер. После перелива в полночь бекапил В, стирал стары й бекап. И зеркалил А во все время работы
Честно сказать крайне сомнительная система получилась. А где бэкап на текущий момент? Без пяти минут день закончился, а тут хард летит к чертям. Что тогда? где резерв данных на текущие сутки? Standby-сервак надо поднимать.
Сервер В. Второй сервер, хранит базу за все время, не считая текущих суток. В полночь данные из А переливались в В. Тут лежат скрипты составления отчетов по периодам.
Сервер С. Бекап сервер. После перелива в полночь бекапил В, стирал стары й бекап. И зеркалил А во все время работы
Честно сказать крайне сомнительная система получилась. А где бэкап на текущий момент? Без пяти минут день закончился, а тут хард летит к чертям. Что тогда? где резерв данных на текущие сутки? Standby-сервак надо поднимать.
0
Бекап на текущий момент лежит на С.
То есть бекап до полуночи + бекап А.
То есть бекап до полуночи + бекап А.
+1
в режиме риал-тайм зеркалит? То есть прошла транзакция и тут же она отражена на серваке С?
0
Да. Запрос отправлялся одновременно на оба сервера и с обоих ожидался ответ о завершении транзакции.
На удивление не сильно мешало работе.
На удивление не сильно мешало работе.
+1
на самом деле не совсем правильно… сбои вероятны как на сервере А, так и на С.
Реально покапайте о Standby-серверах. Даже Мускул сейчас поддерживает. Геморно поставить (под Мускул точно не скажу, под Оракл поднимал), но это стоит того. Вероятность ошибок стремительно близится к нулю. В случае выхода основного сервера, Стэндбай переводим в режим мастера и продолжаем с ним работать, поднимая при необходимости параллельно новый стендбай.
Реально покапайте о Standby-серверах. Даже Мускул сейчас поддерживает. Геморно поставить (под Мускул точно не скажу, под Оракл поднимал), но это стоит того. Вероятность ошибок стремительно близится к нулю. В случае выхода основного сервера, Стэндбай переводим в режим мастера и продолжаем с ним работать, поднимая при необходимости параллельно новый стендбай.
0
А почему не с помощью репликации? Или хотелось 100% синхронности?
0
Не понравилась асинхронность. Возможно это и паранойя, но хотелось иметь полностью актуальный бекап в момент попадания шваброй по серверу )
0
Звучит разумно :) Хотя странно, что репликация не может предоставить такой возможности сама. С другой стороны, наверное проще написать функцию дублирующую запрос чем настраивать репликацию. Но зато репликация уже отлажена, а эту систему пришлось отлаживать и проверять, что она всегда генерирует идентичные базы, самостоятельно.
+1
UFO just landed and posted this here
www.taobackup.com/
хозяйке на заметку
хозяйке на заметку
+1
не совсем понятна тема бекапа на python
чем mysqldump не устроил?
чем mysqldump не устроил?
-1
Скриптами выполнялась проверка целостности поле бекапа и построение логов на день.
Ну а в общем они были оболочкой к тому же mysqldump )
Ну а в общем они были оболочкой к тому же mysqldump )
0
а расскажите, пожалуйста, что имеется в виду под целостностью бекапа?
0
Купите хотя бы несколько новых винтов…
+1
«Пожара не случилось, землетрясения тоже. Все прекрасно работает второй год» — а искусственно ЧП вы хоть раз организовывали?
Если нет, то как знать, вдруг до сих пор все работает только по стечению обстоятельств.
Если нет, то как знать, вдруг до сих пор все работает только по стечению обстоятельств.
-1
«выдержало все краштесты»
Естественно, дергали швабрами все что можно, вырубали на горячую сервера в произвольном порядке, подсовывали подбитые бекапы, в конце концов гоняли во время работы несколько фильмов по сети во всех направлениях и загружали процессоры на максимум чем нибудь бессмысленным. Ни одного нештатного сбоя и не прогнозируемой ошибки. Система держалась молодцом)
Естественно, дергали швабрами все что можно, вырубали на горячую сервера в произвольном порядке, подсовывали подбитые бекапы, в конце концов гоняли во время работы несколько фильмов по сети во всех направлениях и загружали процессоры на максимум чем нибудь бессмысленным. Ни одного нештатного сбоя и не прогнозируемой ошибки. Система держалась молодцом)
0
Sign up to leave a comment.
Отказоустойчивая система из мусора