[26.09.2010] Катастрофа (пропали данные)

DROP DATABASE posts;
 
1 2 3 4 5 6 7 8 9

au

   
★★☆
Дата последнего файла бэкапа БД форумов: 05.10.2010 05:14
 3.5.63.5.6

Balancer

администратор
★★★★★
MPK> Вроде все сохранилось. Спасибо! Непонятно правда что дальше делать? Как все вернуть в исходное? Опыта в таких делах не имею...

Просто создать заново тему и туда всё скопипастить :-/
 

Balancer

администратор
★★★★★
au> Дата последнего файла бэкапа БД форумов: 05.10.2010 05:14

Ага, я вижу. И жду следующего утра.
 
RU Алдан-3 #17.10.2010 12:33
+
-
edit
 

Алдан-3

аксакал
★★☆
Как я понимаю, отдалённые последствия.

В репутации +1 от ED за совет по FireFox (который я давал) ведёт по ссылке на сообщение Бяки (которого я, разумеется, не писал и в котором про FireFox ничего нет).

Как я понимаю связь по ID, старый ID слетел, а новое сообщение с тем же ID оказалось связано "само" как только появилось.

Непорядок (ц)
Особенно его раздражало то, что его постоянно спрашивали, чем он так раздражен.  3.5.53.5.5
RU Balancer #17.10.2010 17:50  @Алдан-3#17.10.2010 12:33
+
-
edit
 

Balancer

администратор
★★★★★
Алдан-3> Непорядок (ц)

Хм. Надо будет поломать голову...
 
+
-
edit
 

Mishka

модератор
★★★
Kuznets> не тащить 10 тыс, тащить 100. на логику это вряд ли влияет.

Влияет. Т.к. performance зависит от этого. Ну всякие join начинают требовать ресурсов намного больше. Кроме того, из-за того, что много дат (expiration, start, end. through, temp) линейка действия commodity зависит от всех.

Kuznets> ну, вот такие вещи имхо надо делать на остановленной и отбекапленной системе...
Дык, делали на тестовой, но с полным набором. Вот разработка идёт на маленькой. А останавливать основную нельзя. Поскольку клиенты были со всего мира.

Kuznets> разве нельзя указать "эта таблица очень важная" или "на эту таблицу в принципе начхать"?

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

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

Дык, действий может быть много. И сознательный риск был в том, чтобы работать на живой базе. А дроп таблицы у нас произошёл не потому, что риск, а потому, что тоже нечаянно не то набрал. У Рому примерно так же. Хотел одно, а получил другое.

Kuznets> а как они вообще могут там появиться если логика изначально прописана?

Начиная с того, что не всё выражается foreign keys, куча функциональных зависимостей описывается через прикладнуху, в которой могут быть ошибки. Ну и ошибки самой СУБД никто не отменял.

Kuznets> разве ресурсы не резервируются?

Не хватает их. У нас по тому времени на системах было по физическому максимуму. Living on the cutting edge, так сказать.

Kuznets> не, насчет технических проблем я не спорю, но чтобы вот так просто пользователь мог удалить большой кусок данных из основной таблицы.....

Дык, стараются избежать. Не всегда выходит.

Мы отказались от SCO и Proliant серверов тогда, т.к. они физически не умели размещать более 100 ГБ дисков. Хотя они работали быстрее HP-х. А Sequent-ы уже переставали поддерживаться IBM. IBM R серия тоже имела проблемы с такими БД. Оракле имел, поэтому работали с Informix-м.
 3.6.103.6.10
Это сообщение редактировалось 17.10.2010 в 19:05
RU Balancer #18.10.2010 01:27  @Алдан-3#17.10.2010 12:33
+
-
edit
 

Balancer

администратор
★★★★★
Алдан-3> Непорядок (ц)

Всё, прибил ссылки в голосах за пропавший период.
 
+
-
edit
 

Balancer

администратор
★★★★★
Mishka> Влияет. Т.к. performance зависит от этого. Ну всякие join начинают требовать ресурсов намного больше.

На Авиабазе в былые времена, когда ресурсов было много меньше, периодическое явление было. То всё летает, то в один прекрасный день, по достижении критической массы, всё ложится. Производительность нередко падает по мере роста объёма данных не линейно, а скачком с какого-то порогового значения.
 
US Сергей-4030 #19.10.2010 18:06  @Сергей-4030#28.09.2010 17:38
+
-
edit
 

Сергей-4030

исключающий третье
★★
Balancer>Пока кроме меня и Ведмедя никто на такую жертву не согласился, так что я и интерфейс для привязки ЖЖ пока не делал, Ведмедю и себе авторизационные данные вручную прописал.

Слушай, пожалуй ты прав, как-то некомфортно, да. Дело даже не в том, что пароли exposed, просто ненужные зависимости появляются. Я поменял пароль на LJ, удали из моей записи, pls. Извини за беспокойство, плохая была идея. :(
 6.0.472.636.0.472.63
RU Balancer #19.10.2010 18:29  @Сергей-4030#19.10.2010 18:06
+
-
edit
 
Последние действия над темой
1 2 3 4 5 6 7 8 9

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru