!СРОЧНО Упала база

[AoW 17]

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

Старгайзер продолжает в конфигураторе использовать актуальные данные и все работает хорошо.

Автоматически подставилась старая база, но она не актуальна на данный момент.

Как завершить работу Старгайзера что б он записал в базу все актуальные данные?

База MySQL

[hex@set 1 423]

автоматически и неизвестно каким образом затерлись все бек-апы базы именно старгайзера.

Админа уволили?

[AoW 17]

автоматически и неизвестно каким образом затерлись все бек-апы базы именно старгайзера.

Админа уволили?

Пока нет, может исправится успеет

[nightfly 1 221]

Как завершить работу Старгайзера что б он записал в базу все актуальные данные?

Если старгейзер физически может производить запись в БД - он производит ее при изменениях параметров пользователя, напремер денег, тарифа, итд. Для трафика интервалы записи указываются в конфиге.

Можете рискнуть выставить какому-нить юзеру кредит скажем 1-ну деньгу и посмотреть какой будет реакция со стороны базы. Если старгейзер не потерял линка с мускулем - запись юзера должна актуализироваться. Можно за 5 минут на коленке сварганить скрипт выставляющий всем юзерам астральный кредит. Если фокус не прокатывает - то скорее всего ....упс...

 

ЗЫ админы делятся на тех кто делает бекапы и тех кто уже их делает.

ЗЫ2 предчувствую прибегание madf-а который выскажет все что он думает о store_mysql

[AoW 17]

были старые тарифы когда то и новые

Новые тарифы есть в конфигураторе - в базе их нет

Пробуем что то менять в новом тарифе - он не появляется в базе, хотя конфигуратор не матюкается

но при создании нового тарифа - все ок, олн успешно создается в базе

[nightfly 1 221]

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

[madf 279]

Самый правильный вариант спасения тут - сдампить все данные через XML RPC а потом залить их обратно. Детальной статистики и логов, понятное дело, не будет.

Изменение/сохранение не работает, т.к. для того чтобы записать изменения в БД нужно чтобы там уже что-то было. Чтобы записать изменения тарифа нужно чтобы был тариф. Чтобы записать изменения юзера нужно чтобы был юзер. И т.д.

 

nightfly - а вот и не угадал! Как раз в данном конкретном случае mod_store_mysql, не смотря на его кривость, скорее всего абсолютно не при чем

[AoW 17]

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

[madf 279]

Решение следующее, посоздавать в базе тарифы -только названия - вручную, и так же пользователей - только логин...

Ну можно и так. Еще админы, хотя это не так критично.

[AoW 17]

админы не менялись за это время

[AoW 17]

посоздавали в безе 80 логинов, 10 тарифов, поменяли пароли всем админам, из консольного конфигуратора установили - сняли галочки детальной статистики - все хорошо теперь. Всем спасибо!

Бекаптесь несколько раз, а не один как мы

[madf 279]

посоздавали в безе 80 логинов, 10 тарифов, поменяли пароли всем админам, из консольного конфигуратора установили - сняли галочки детальной статистики - все хорошо теперь. Всем спасибо!

Бекаптесь несколько раз, а не один как мы

... и используйте нормальные СУБД, которые не падают сами по себе

 

А причину падения установили?

[nightfly 1 221]

... и используйте нормальные СУБД, которые не падают сами по себе

Ну я же говорил?

 

 

А причину падения установили?

Да как всегда, очевидно - или место кончилось, или индексы недотюнили и память кончилась, свопнуло не удачно, либо тупо по питанию рухнуло.

Больше причин падения мускуля практически не видел - он слишком простой и дубовый чтобы там вообще что-то сломалось.

[madf 279]

... он слишком простой и дубовый чтобы там вообще что-то сломалось.

Адски сложный PostgreSQL не упал даже когда я унутрях у него неонку выкручивал. То бишь выковыривал битый раздел винта который пришелся как раз на базу. А он себе в это время работал и не чихал.

Я, к стати, слабо себе представляю бекап базы на 1.5 Тб

Хотя, конечно, критически важной информации там значительно меньше. Жаль, не помню сколько таблица с 30к юзерами занимала.

[Роман Погосян 0]

В постгресе не делал вакум пол года лилась статистика детальная и все такое. старгазер всегда весело запускался но случилось так что надо было удалить одного пользователя . и его удаление заняло около 2-х часов в ручную (старгазер не справлялся зависал) пришлось потратить пол ночи чтоб почистить базу от лишней неактуальной инфы и сделать вакум .... база была всго 14 гиг

[madf 279]

В постгресе не делал вакум пол года лилась статистика детальная и все такое. старгазер всегда весело запускался но случилось так что надо было удалить одного пользователя . и его удаление заняло около 2-х часов в ручную (старгазер не справлялся зависал) пришлось потратить пол ночи чтоб почистить базу от лишней неактуальной инфы и сделать вакум .... база была всго 14 гиг

VACUUM и ANALYZE давно делаются автоматически.

Удалялся 2 часа потому что статистики много.

А зачем удалять?

[Роман Погосян 0]

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

[madf 279]

По видимому, причина в том что PostgreSQL - это не та СУБД, которую "поставил и забыл"

Для таких случаев есть Firebird.

А за PostgreSQL следить надо, отслеживать деградацию планировщика запросов, добавлять индексов "по вкусу" и т.д.

Вот, например, запрос выводящий статистику по VACUUM/ANALYZE, запросам по таблицам и "мусору":

SELECT schemaname AS sch, relname AS tab, pg_size_pretty(pg_relation_size(relid)) AS size, n_tup_ins AS ins, n_tup_upd AS upd, n_tup_del AS del, n_live_tup AS live, n_dead_tup AS dead, ROUND(1.0 * n_dead_tup / CASE WHEN n_live_tup + coalesce(n_dead_tup) > 0 THEN n_live_tup + coalesce(n_dead_tup) ELSE NULL END, 3) AS "d/l", DATE_TRUNC('second', last_vacuum) AS lv, DATE_TRUNC('second', last_autovacuum) AS lav, DATE_TRUNC('second', last_analyze) AS la, DATE_TRUNC('second', last_autoanalyze) AS laa FROM pg_stat_user_tables WHERE schemaname IN ('public') ORDER BY "d/l" DESC NULLS LAST LIMIT 50;

С его помощью становится видно по каким таблицам когда производилась "сборка мусора" (VACUUM) и обновление статистики (ANALYZE). Кроме того, имеет смысл регулярно прогонять пару-тройку типичных запросов через EXPLAIN и смотреть на использование индексов. Еще набо полезных запросов для DBA:

http://wiki.postgresqlrussia.org/index.php/%D0%9F%D0%BE%D0%BB%D0%B5%D0%B7%D0%BD%D1%8B%D0%B5_%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D1%8B_%D0%B4%D0%BB%D1%8F_PostgreSQL_DBA

http://postgresqlrussia.org/articles/view/48

 

PS: удаление данных из базы - всегда плохая идея. Это все-таки историческая информация. Достаточно просто сделать disable и удалить детальную статистику.

[rsst 404]

По видимому, причина в том что PostgreSQL - это не та СУБД, которую "поставил и забыл"

 

больше года в глаза не видел консоль со своим постгресом и базой биллинга на нем. однажды настроенный автовакуум отлично работает и субд не требует каких-либо телодвижений с моей стороны.

[madf 279]

По видимому, причина в том что PostgreSQL - это не та СУБД, которую "поставил и забыл"

 

больше года в глаза не видел консоль со своим постгресом и базой биллинга на нем. однажды настроенный автовакуум отлично работает и субд не требует каких-либо телодвижений с моей стороны.

Значит, все еще впереди

Хотя, если детальная статистика не используется то "сюрпризов" быть не должно.

[rsst 404]

Значит, все еще впереди

Хотя, если детальная статистика не используется то "сюрпризов" быть не должно.

 

уточною - биллинг свой, самописный. т.е. не stg. Когда-то в нем также складывалась детальная статистика (netflow). Сейчас смысла в ней нет.

[madf 279]

Значит, все еще впереди

Хотя, если детальная статистика не используется то "сюрпризов" быть не должно.

 

уточною - биллинг свой, самописный. т.е. не stg. Когда-то в нем также складывалась детальная статистика (netflow). Сейчас смысла в ней нет.

Я думаю, что на небольших базах все СУБД одинаково хороши.