MySQL

Решил вновь заняться изучением мускула, есть на это причины. Из исходников не собрался, что уже обидело. Ну да ладно, скачал с Арчевых реп. Далее решил создать системную базу данных всем известной командной

mysql_install_db

в ответ ошибок не получил, получил лишь просьбу установки пароля для рута, что понятно и приглашение для старта демона:

You can start the MySQL daemon with:
cd /usr ; /usr/bin/mysqld_safe &
You can test the MySQL daemon with mysql-test-run.pl
cd /usr/mysql-test ; perl mysql-test-run.pl

но при

# /usr/bin/mysqld_safe &

выводит ошибки:

100522 01:12:09 mysqld_safe Logging to '/var/lib/mysql/xx.err'.
100522 01:12:10 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

а в файле xx.err написано следующее:

100522 01:11:56 mysqld_safe mysqld from pid file /var/lib/mysql/xx.pid ended
100522 01:12:10 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
100522  1:12:10 [Note] Plugin 'FEDERATED' is disabled.
100522  1:12:10 [Note] Plugin 'ndbcluster' is disabled.
100522  1:12:10  InnoDB: Started; log sequence number 0 44233
100522  1:12:10 [Note] Event Scheduler: Loaded 0 events
100522  1:12:10 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.46'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Source distribution
100522  1:13:38 [Note] /usr/sbin/mysqld: Normal shutdown
100522  1:13:38 [Note] Event Scheduler: Purging the queue. 0 events
100522  1:13:38  InnoDB: Starting shutdown...
100522  1:13:41  InnoDB: Shutdown completed; log sequence number 0 44233
100522  1:13:41 [Note] /usr/sbin/mysqld: Shutdown complete
100522 01:13:41 mysqld_safe mysqld from pid file /var/lib/mysql/xx.pid ended

если не запускать в безопасном, то:

 /usr/bin/mysql
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

Помогите пожалуйста.
Видел что-то наподобие на opennet.ru - толком конкретного не нашел, да что нашел не помогло.

Сперва провер права на папку '/var/run/mysqld/mysqld.sock' и остальные какие относятса к мускулу. Доступ к ним должен иметь пользователь, как мне кажетса mysqld:mysqld, но могу ошыбатса. провер лежыт ли в /etc my.cfn и провер в конфиге пути. также можеш посмотреть в /var/lib/mysql есть ли там папки information_shema mysql test, и есть ли в information_shema и mysql файлики с розшырением *.MY. Если файли есть то база проиницылизировалась если нет, ошыбка иницыализацыи базы.

kisil написал:

Доступ к ним должен иметь пользователь, как мне кажетса mysqld:mysqld

может быть mysql:mysql
?
у мну - так.

kisil написал:

ошыбка иницыализацыи базы.

о коей в логе написано... а где лог-то?

может быть mysql:mysql
?
у мну - так.

Да. Верно должен бить mysql:mysql

о коей в логе написано... а где лог-то?

kOvr1K написал

а в файле xx.err написано следующее:

Значит он знает где лежит файл лога.

А для правильного запуска нужна написать что то такое, если это rpm дистрибутив
/etc/init.d/mysqld start или service mysql start
Если дистр слакваре или ему подобные то:
/etc/rc.d/rc.mysqld start

Debian Lenny, сборка XAMPP

Друзья, такоц препон. Поднял сайт, всё отлично работало, но после попытки добавить lampp в автозагрузку (к слову, успешной), после нескольких проверочных ребутов перестал стартовать MySQL:

XAMPP: Starting MySQL...
XAMPP: Couldn't start MySQL!

В /opt/lampp/var/mysql есть лог debian.err фрагмент которого я привожу:

100819 10:30:51 mysqld_safe Starting mysqld daemon with databases from /opt/lampp/var/mysql
100819 10:30:51 [Warning] '--skip-locking' is deprecated and will be removed in a future release. Please use

'--skip-external-locking' instead.
100819 10:30:51 [Note] Plugin 'FEDERATED' is disabled.
100819 10:30:52 InnoDB: Started; log sequence number 0 44263
100819 10:30:52 [Note] PrimeBase XT (PBXT) Engine 1.0.11-6 Pre-GA loaded...
100819 10:30:52 [Note] Paul McCullagh, PrimeBase Technologies GmbH, http://www.primebase.org
100819 10:30:52 [Note] The server was not shutdown correctly, recovery required
100819 10:30:52 [Note] Recovering after a crash using tc.log
100819 10:30:52 - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=0
max_threads=151
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133316 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = (nil) thread_stack 0x30000
/opt/lampp/sbin/mysqld(my_print_stacktrace+0x26)[0x847e346]
/opt/lampp/sbin/mysqld(handle_segfault+0x3ff)[0x81c93df]
[0xb770c400]
/opt/lampp/sbin/mysqld(_ZN11TC_LOG_MMAP4openEPKc+0x289)[0x826d669]
/opt/lampp/sbin/mysqld[0x81ce775]
/opt/lampp/sbin/mysqld(main+0x1d5)[0x81c9b55]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7371455]
/opt/lampp/sbin/mysqld[0x8112801]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
100819 10:30:52 mysqld_safe mysqld from pid file /opt/lampp/var/mysql/debian.pid ended

Дальше всё то же самое по кругу... Что может являться причиной ошибки? Как восстановить работу сборки не повредив базу сайта? Спасибо!

Не знаю какой мускул в ХАМРР может луче поставить мускул из репы Дебиана и использовать его? wink

krasnoff написал:

The server was not shutdown correctly, recovery required

работа сервера была завершена не корректно, и он требует восстановить БД. такое я видел после сбоев с напряжениемп и если HDD посыпался.
лечится какой-то утилитой из поставки mysql. у меня всё прошло нормально. ну тут вообще-то сами понимаете, как повезёт... Бекап сделать не забудьте (вообще-то он у вас УЖЕ должен быть).

krasnoff,

Посмотри чтоб расчётное значение памяти key_buffer_size +
(read_buffer_size + sort_buffer_size)*max_connections не превышало
имеющийся в наличии размер памяти.
Например расчётное 1284140 K а в сервере 512М тогда будет падать при
попытке получить ещё памяти

kisil, боюсь не осилить.
drBattyПросто не успел бэкап сделать... Очередной обучающий удар граблями. Тулзу попробую найти.

Hvzh написал:

krasnoff,
Посмотри чтоб расчётное значение памяти key_buffer_size +
(read_buffer_size + sort_buffer_size)*max_connections не превышало
имеющийся в наличии размер памяти.
Например расчётное 1284140 K а в сервере 512М тогда будет падать при
попытке получить ещё памяти

Сервер - громко сказано. Памяти 256 Мб, и то с откусыванием на интегрир. видео. Пишет: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133316 K вроде бы укладываюсь?

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

krasnoff,
Все-таки, ошибка именно в этом. Попробуйте поменять значения переменных

Вопрос благополучно разрешился в соотв. с советом kisil: накатили с товарищем мускл из репозитория, слили дамп базы, переустановили xampp и восстановили сайт. Но, к слову, база восстановилась и после банального копирования каталога с ней на старое место, специально проверил на будущее, мне только пользователя в pma оставалось добавить.
Всё работает, спасибо вам всем!

krasnoff написал:

Но, к слову, база восстановилась и после банального копирования каталога с ней на старое место

угу. в моём случае вообще весь раздел /var умер - вытянул с него данные, и всунул на новый раздел. вся база восстановилась (не считая какой-то мелочи, какой-то временной таблицы).