The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Оценка методов противостояния потере данных в ФС при крахе с..., opennews (??), 15-Дек-15, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


80. "Оценка методов противостояния потере данных в ФС при крахе с..."  +/
Сообщение от angra (ok), 15-Дек-15, 22:30 
Ну вот тебе сходу две очень даже продакшеновые задачи: запись логов и бекапы. Поведай нам жуткие подробности поедания мозга на их примере.
Ответить | Правка | Наверх | Cообщить модератору

93. "Оценка методов противостояния потере данных в ФС при крахе с..."  –1 +/
Сообщение от Аноним (-), 15-Дек-15, 23:15 
> Ну вот тебе сходу две очень даже продакшеновые задачи: запись логов и
> бекапы. Поведай нам жуткие подробности поедания мозга на их примере.

За потерю нужных логов на проде поддержку/ИТ казнят лютой казнью. А как бекапы соотносятся с настройкой кеширования - не понятно, если только вы не каждую минуту бекапите систему.

Ответить | Правка | Наверх | Cообщить модератору

111. "Оценка методов противостояния потере данных в ФС при крахе с..."  +1 +/
Сообщение от angra (ok), 16-Дек-15, 02:34 
А за потерю логов, которые не понадобились? А это 99% логов.

Причем здесь каждую минуту? Может быть и раз в сутки, а может вообще быть непрерывным. Суть в том, что потеря пары часов при создании бекапа вообще никого не волнует, если только ровно в это же время не случился факап и с основным сервером. А ведь бекап может идти и больше чем в одно место и на кратковременное падение одного из них вообще всем плевать.

Ответить | Правка | Наверх | Cообщить модератору

141. "Оценка методов противостояния потере данных в ФС при крахе с..."  –1 +/
Сообщение от Аноним (-), 16-Дек-15, 14:05 
> А за потерю логов, которые не понадобились? А это 99% логов.

Когда сервер падает, логи автоматически нужны. И именно в этом случае они теряются. Забавно, не находите?

> Причем здесь каждую минуту? Может быть и раз в сутки, а может
> вообще быть непрерывным. Суть в том, что потеря пары часов при
> создании бекапа вообще никого не волнует, если только ровно в это
> же время не случился факап и с основным сервером.

Если при создании бекапа результат никого не интересует, то неладно что-то в королевстве датском.

Ответить | Правка | Наверх | Cообщить модератору

101. "Оценка методов противостояния потере данных в ФС при крахе с..."  +/
Сообщение от Чаёвник (?), 15-Дек-15, 23:54 
> Ну вот тебе сходу две очень даже продакшеновые задачи: запись логов и
> бекапы. Поведай нам жуткие подробности поедания мозга на их примере.

Кэширование для бекапов? Серьёзно? У вас клёёёвый прод!
И да, если кто-то лезет за бекапом (очевидно потому что текущее файло битое) и не находит бекапа, то кто-то с кешированием "во все ненужные места" пойдёт искать работу =)

Логи... ну может быть... но может быть вам такие логи и не нужны?
И да, если сервер вдруг раз в час (или сколько вы там себе настроили на кеш) резко проседает под нагрузкой, это тоже как-то ну оооочень странно.

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

113. "Оценка методов противостояния потере данных в ФС при крахе с..."  +2 +/
Сообщение от angra (ok), 16-Дек-15, 02:42 
> Кэширование для бекапов? Серьёзно? У вас клёёёвый прод!

Ну давай, поделись как надо.

> И да, если кто-то лезет за бекапом (очевидно потому что текущее файло
> битое) и не находит бекапа, то кто-то с кешированием "во все
> ненужные места" пойдёт искать работу =)

То есть сразу должен навернуться и бекап и продакшен. мягко говоря не очень частая ситуацияю А если бекап шел сразу на несколько отдельных серверов еще и географически разнесенных? Тоже все сразу навернутся?

> Логи... ну может быть... но может быть вам такие логи и не
> нужны?

Ты не поверишь, но логи не нужны в 99% случаев. Их ведут ради разбора факапов и иногда статистики. На небольшую потерю статистики обычно плевать, а факапы должны случаться достаточно редко. В противном случае проблема совсем не в кешировании.

> И да, если сервер вдруг раз в час (или сколько вы там
> себе настроили на кеш) резко проседает под нагрузкой, это тоже как-то
> ну оооочень странно.

Про запись данных раз в час тебе нашептали голоса в голове. Не слушай их, до добра не доведут.

Ответить | Правка | Наверх | Cообщить модератору

135. "Оценка методов противостояния потере данных в ФС при крахе с..."  –3 +/
Сообщение от Чаёвник (?), 16-Дек-15, 11:51 
> Ну давай, поделись как надо.

Не хочу, когда сами огребёте пару раз - научитесь научитесь, общепринятая практика хранения данных же вам не интересна, всё тлен, всё ненужно

> То есть сразу должен навернуться и бекап и продакшен. мягко говоря не очень частая ситуацияю А если бекап шел сразу на несколько отдельных серверов еще и географически разнесенных? Тоже все сразу навернутся?

Далеко не все сидят в облаках или имеют инфраструктуру размазанную по принципу "этот сервер будет работать тут, а вон оттого ННАДА чтобы респонсы тормозили посильнее, поэтому перевезём его на северный полюс, заодно сэкономим на охлаждении".
Довольно классическая ситуация: вся улица остаётся на несколько часов без света (например из-за пожара у кого-то в другом краю этой улицы). И тут вдруг оказывается, что к вашим костылям с кешированием надо дописывать ещё костыли, которые будут мониторить UPSы и быстренько синкать эти кеши на диск, а так же каждый квартал пачками менять АКБ которые без ваших понтовых костылей вполне бы ещё пару лет поработали, что тоже не самое безболезненное и не самое дешёвое мероприятие.

> логи не нужны в 99% случаев

Ну так не пишите их, раз они вам не нужны, нафиг вы нам мозг морочите?

> Про запись данных раз в час

Нашептали в соседнем посте этой же ветки этого же сабжа, дочитывайте всю ветку перед комментированием

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру