Новая тема   Ответить

 AcidDog
Сидж - аврора. При заходе в админку выдаёт

Got error 127 from table handler

Как вручную базу можно востановить? Помагите плиз.

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

 von Stoltz
Linoge писал:
А еще лучше - который ее в принципе потерять не может
А здесь phpMyAdmin тебе, вероятно, поможет

Последний раз редактировалось: von Stoltz (29/03/05 в 17:06), всего редактировалось 1 раз

 Linoge
Цитата:

 badsanta
AcidDog писал:

В phpmyadmin есть такая опция как repair database или если у тебя CPanel то в опциях MySQL есть тоже ета функция. Вот она часто помогает у меня оди раз такая ерунда была с форумом. Ну вот я его так и поднял. И делай иногда хотябы раз внеделю бекап базы.

 Phoenix66
von Stoltz писал:

Любой скрипт может потерять базу, если сервер перегружен. Включая те кто работает без MySQL (они кстати как раз в первую очередь теряют данные обычно)

 AcidDog
Всем спасибо, оценил, базу установил.

 Pedronas
Цитата:

просто 90% сиджей новичками делается на авроре, вот и вопросов по ней много, а так скрипт хорош, ничего плохого сказать не могу

 von Stoltz
Phoenix66 писал:

Не нужно таких безаппеляционных заявлений, я понимаю, что имеется ввиду..., но ты не учитываешь что :

1. (скрипт !использует MySQL) !== (скрипт использует текстовую базу)
Действительно скрипты с текстовой базой легко теряют базу даже на относительно стабильном хосте, поэтому все современные скрипты, хранящие критические данные в тексте оборудованы автовосстановлением или чем-то подобным, но для особо важных файлов ведь можно предусмотреть и другой формат.

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

 Phoenix66
Где ты безаппеляционность увидел? Я писал МОЖЕТ ПОТЕРЯТЬ, а не ТЕРЯЕТ.

Нормально настроенный мускуль базу тоже не теряет, если ты имеешь в виду часть по поводу мускуль/не мускуль. Он ее тоже беккапит и восстанавливает автоматом. Годами ничего не терялось у меня при такой настройке на стоящем раком сервере где много виртуалов было.

 von Stoltz
Ну извините, видимо "нормально настроить мускуль" способны единицы хостеров.
У меня год назад, когда перегрузки на виртуале начались в первую очередь вылетел мускульный скрипт, причем вылетел по варианту "потеря базы", то есть посетители видели надпись "cannot connect to DB" или что-то в этом роде.

 Stek
Гм, сейчас дидикейт нормальный можно за 80 баксов взять. Нет сил столько заработать ? Идите в дворники господа, больше получать будете и здоровье сохраните.

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

 Phoenix66
von Stoltz писал:

А при чем тут потеря базы? Это временная неспособность сервера обслужить запрос. Возникает обычно из-за превышения ограничения на количество коннектов к базе. Ну можно убрать лимит - только тогда сервер ебнется совсем скорее всего. Нагрузи сервер таким же количеством скриптов, которые работают с диском, а не с мускулем - и он точно так же ебнется.

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

А потери базы в случае "Cannot Connect" не происходит. Уменьшится количество запросов - и начнет опять нормально отвечать. Все данные при этом остаются целыми.


Что же касается того, что при потере части данных скриптами, не использующими MySQL они типа продолжают работать - так это смотря какая часть потерялась. Может морда и нормально продолжает отображаться. Только трейд может весь в пизду идти при этом...

 Phoenix66
Кстати, на виртуале заткнуться MySQL может просто из-за чьего-то криво написанного скрипта. При том что мощности теоретически более чем достаточно. Достаточно наплодить спящих процессов и пиздец мускулю - будет этот самый Cannot Connect.

 von Stoltz
Stek писал:
С таким подходом под SQL Server сиджи писать нужно. Сколько квадро зеон с виндой стоит, 800 в месяц? Нет сил столько заработать ? Фсем в дворники! Или SQL Server
Phoenix66 писал:
Насколько я помню, трейдеров все же пришлось ручками восстанавливать, скрипт ТТТ был...

Phoenix66 писал:
Равномерная потеря данных на трейде не скажется никак, а то что морда продолжит отображаться - намного лучше, чем демонстрировать посетителям "cannot connect" в течение нескольких часов.

 Fi$her
von Stoltz писал:
Извини конечно, но кто мешает вместо die("Cannot connect") написать header("Location: index.shtml") ?
Понятно что при этом ни ин нормально, ни аут работать не будут.
Но и в ауте обход это проблемы можно решить...

 von Stoltz
Fi$her писал:
Правильно, и получится CJ скрипт без MySQL

 SeRsH
Да просто не было еще нормально написанных под mysql сиджеев
У меня сейчас около 400-500 запросов в секунду на мускуле. более миллиона хитов сервак держит в день на моем сж скрипте под мускуль. И ничего, 70-80% процессора в idle, на винт нагрузки вообще нет - весь реалтайм в памяти. Но я сейчас еще больше улучшаю показатели производительности, там можно добиться, чтобы load average еще в 2-3 раза снизить, а то слишком много запросов на ауте и не самый оптимальный формат айпи-лога.

 Stek
Вот нечего слова передергивать про квадро ксеоны с виндами. В 90% падения базы виноваты кривые скрипты и руки админов, которые не удосуживаются не только апдейтить мускуль , но и даже элементарно его настроить. Большинство просто ставит мускуль на сервер считают на этом свою работу законченной, даже не думая о том, что стандартная настройка мускуля расчитана на сервер со 128 мегами памяти.

Цитата:
ну вас нахрен с таким трейдом. Поменяйте таблицы на хеап, там тоже тогда нечего терять будет

 von Stoltz
Stek писал:

Ну вот только самому не надо передергивать, да ;)

Речь шла о том, что лучше - потерять часть данных, сохранив скрипт в рабочем состоянии или полностью базу и несколько часов (пока не проснулся и не поднял) демонстрировать посетителю "cannot connect" или "Got error 127".
Мне больше нравится первый вариант.

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

 badsanta
von Stoltz писал:
Хорошего админа тяжело счас найти как и раньше и стоят они не как 40к загод. Как на CPanel'е была предложение. После етого появляются и вломаные серваки и т.д.