Биллинговая система Nodeny

Сегодня, во время грозы, убило ИБП. Сервер лег. Меня рядом не было. Подняли без меня. Мускул так и лежит. Может кто подскажет что делать? В каком направлении двигаться? Логи, какими я пользуюсь прикрепляю. Очень надо. Гугл как бы не помогает. Спасибо заранее...

дайте доступ по ssh

и ждать долго т.к. будет проверять все базы и все таблицы или
и ждать быстро

в innodb ?
уверен ?

Нет конечно, но где речь шла об innodb? Практика показала что innodb крашатся гораздо реже чем myisam и чаще всего проблема с биллингом решается именно таким способом. )

так в первом посту лог прикреплен .....


вернее будет так - решалась - в v50.xx  в n+  другие решения

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

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

очень интересно - рекомендации на оф сайте назвать решением через задний проход ...
конечно проще накатить из бекапа - только вот у большенства бекапы суточные....  и что делать если за день прошло 2-3к платежей ...  ручками ?
да и в n+  да и не только (скажем узерсайд)  база (или часть таблиц)  в innodb


 

Ну ты и сказочник, я валяюсь )))
Ладно, разговор ни о чем. Ты безумно крут... я сдаюсь )))

могу показать в первых числах ....

а вообще умные Вам не возражюут

Заметь, ты это сам сказал )))) Сегодня что, первое число? или просто так, для поддержания беседы рассказываешь об этом )))
Рука-Лицо!

я же сказал умные вам не возражают .



я привык за слова отвечать

+----------+----------------------------+
| count(*) | DAY(FROM_UNIXTIME(`time`)) |
+----------+----------------------------+
|     3250 |                          1 |
|     1450 |                          2 |
|     1822 |                          3 |
|      963 |                          4 |
|      497 |                          5 |
|      649 |                          6 |
|      604 |                          7 |
|      402 |                          8 |
|      370 |                          9 |
|      284 |                         10 |
|      231 |                         11 |
|      172 |                         12 |
|      177 |                         13 |
|      231 |                         14 |
|      233 |                         15 |
|      169 |                         16 |
|      147 |                         17 |
|      227 |                         18 |
|      188 |                         19 |



даже 19  числа сколько надо времени что бы выбрать и провести платежи 188 тел  ?

+ на восстановление базы я потратил менее 10 мин....
из них больше на кофе и сигарету.
притом что использовал стандартный способ ремонта innodb .

а если 1 или  30 числа это было бы ?
  

Если табличка не фейковая (а так ответить и я могу, еще круче получится) то таких организаций (более 10к юзеров), работающих на Н+ пересчитать на пальцах одной руки можно и останется место. Так что не убедительно получилось. Да, чуть не забыл, не всегда innodb лечится "стандартными" способами )) иногда легче 200 платежей поручить бухгалтеру провести вручную (ведь в такой организации есть бухгалтер? )))) или все админ делает ))))
А курить вредно, бросай!

я и не говрил что таблицка из n+ ,  но база в innodb ....
чуть более 25к
да есть и бухи , но вот тольок там проблемка в том билинге бух они не могут провести платеж от имени терминала...
а значит в консоли мускула править ручками ...
а если не верно провести то с 1с будет рвать данные....
да и я стороник сохранения любой инфы....

это не относится к данному случаю...
в данном случае было все банально ....


любая база и не только не всегда лечится... но это как правил исключение (или железо или кривые руки)..
после креша userside  в одной сети не смог восстановить.... /инодб
тоже самое в другой сети n50  тоже (кое кто ее пытался рихтовать....). /муисам
 

еще Тамерла́н  говорил = мы рождаемся что бы умереть , а жизнь каждоденвная отсрочка