Проблемы с MySQL

[AnDrEyKa]

Использую Zabbix 2.4.1 VMware Appliance. Смутно припоминаю, что относительно недавно (может быть месяц назад) обновлял Zabbix и сейчас он пишет версию 2.4.5.
Внезапно, без объявления войны (а точнее после перезагрузки вызванной длительным отключением питания, но ИБП сервера тушат корректным завершением работы), получаю в вэб-интерфейсе сообщение:

Database error
Error connecting to database: No such file or directory

Сначала пытался восстановиться из бэкапа, но на самом старом бэкапе этой виртуалки картина идентичная.
Потом включаю гугл, читаю много всего с похожими симптомами, в первую очередь на этом же форуме тут и тут, но описанные методы ни к чему не приводят. Из доп. симптомов понял, что MySQL не стартует, на команды типа

mysql start

или

mysql restart

пишет одно и то же:

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

а на

mysqladmin -p status

отвечает

mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/run/mysql/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/var/run/mysql/mysql.sock' exists!

Кто-то может что-то посоветовать - как восстановить работу MySQL? Или придётся разворачивать новый Appliance (заодно более свежей версии) и как-то переносить туда старую базу со всеми настройками?

ЗЫ: запустил обновление и обновился до 2.4.6 - ничего не изменилось.

[Zentarim]

Влючайте логирование mysql и смотрите - что происходит.
тут
http://habrahabr.ru/sandbox/22772/
вроде бы все описано понятным языком.

Но если вы тушили сервер по питанию и там что-то в этот момент писалось, скорее всего вы положили базу.

Мне один раз помогло включение innodb_force_recovery
https://dev.mysql.com/doc/refman/5.0...-recovery.html

[yukra]

Влючайте логирование mysql и смотрите - что происходит.
тут
http://habrahabr.ru/sandbox/22772/
вроде бы все описано понятным языком.

Но если вы тушили сервер по питанию и там что-то в этот момент писалось, скорее всего вы положили базу.

Мне один раз помогло включение innodb_force_recovery
https://dev.mysql.com/doc/refman/5.0...-recovery.html

Нужно смотреть в error-log, который например в CentOS лежит в
/var/lib/mysql/`hostname`.err .. там все написано. Не знаю где он лежит в сусе (а именно она по моему скрывается под "VMware Appliance", но подозреваю что где то там же. В крайнем случае strace -f service mysql start 2>&1 | grep open

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

[AnDrEyKa]

Влючайте логирование mysql и смотрите - что происходит.
тут
http://habrahabr.ru/sandbox/22772/
вроде бы все описано понятным языком.

Но если вы тушили сервер по питанию и там что-то в этот момент писалось, скорее всего вы положили базу.

Мне один раз помогло включение innodb_force_recovery
https://dev.mysql.com/doc/refman/5.0...-recovery.html

По питанию по идее не тушился - при длительном отключении питания ИБП даёт команду всем виртуалкам завершать работу, ждёт определённое достаточное время, а потом даёт команду на завершение работы самому хосту, а он в свою очередь не выключится пока все виртуалки не потухнут, а тех кто не понял с первого раза - потушит уже своими методами. Т.е. внезапным образом ни хост, ни виртуалки без питания не останутся.Проверку диска конечно на всякий случай запускал - ошибок не нашёл.
Да и как я понял проблема не столько в базе, сколько в самом демоне MySQL - он тупо не запускается по каким-то пока непонятным причинам. Включу завтра логи по мануалу в вашей сцылке, а по ним надеюсь станет понятней чо ему там не понравилось...

Нужно смотреть в error-log, который например в CentOS лежит в
/var/lib/mysql/`hostname`.err .. там все написано. Не знаю где он лежит в сусе (а именно она по моему скрывается под "VMware Appliance", но подозреваю что где то там же. В крайнем случае strace -f service mysql start 2>&1 | grep open

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

Так точно - Suse Linux гостевой системой. Хотел сначала сам разобраться, потом вот на форум полез, а уже если и подсказки форума не помогут, буду заманивать знакомого линуксоида

[AnDrEyKa]

По статье

Влючайте логирование mysql и смотрите - что происходит.
тут
http://habrahabr.ru/sandbox/22772/
вроде бы все описано понятным языком.

сходил в /var/log/mysql и ничего там не обнаружил. Вообще. Добавил в конфиг my.cnf строки:

log_error = /var/log/mysql/mysql.err
log_warnings = 1

Дал команду стартовать MySQL - ничего не появилось. Ребутнулся - ничего не появилось.
Потом пошёл по рекомендации

Нужно смотреть в error-log, который например в CentOS лежит в
/var/lib/mysql/`hostname`.err .. там все написано.

и действительно нашёл там: /var/lib/mysql/zabbix.err. В логе последняя запись от 02 августа (см. ниже) - тогда то он у меня видимо и сломался окончательно, а Заббикс каким-то чудом умудрялся мне что-то показывать, но как понимаю в базу уже статистика не писалась. И после перезагрузки вызванной длительным отключением питания он уже не взлетел. Причём произошло это конечно же буквально в первый день моего отпуска
В логах я скопировал два похожих события в 13:01 и 14:02 (см. ниже). Они похожи, но событие 13:01 завершается успешным восстановлением, а событие 14:02 уже завершилось фатальной ошибкой. Событие 13:01 повторяется и более глубже по времени с той же периодичностью примерно в час: 11:01, 10:01, 9:07, 8:05, 7:57, 7:00, 6:26, 5:56, 5:00... и так до 9:14 31.07.2015. До этого такая же фигня происходила раньше, но не с такой длительной периодичностью, скорее единично раз в несколько дней, иногда короткими сериями.
Как я понял эту ситуацию, MySQL по каким-то причинам регулярно падал, но сам себя восстанавливал (у меня заббикс периодически слал оповещения что не может связаться со своей базой, но видя что дальше всё продолжает работать я списывал это на какие-то баги).
И так он сам себя успешно восстанавливал вплоть до 150802 13:01:20, пока в 150802 14:02:48 не произошла фатальная ошибка:

150802 14:02:48 [ERROR] mysqld: Can't create/write to file '/var/tmp/mysql.9w498H/ibBKvJBf' (Errcode: 2)

Судя по дальнейшим записям в логе сам MySQL распознал эту ситуацию как свой собственный баг, предложил запостить баг-репорт, и отправил к мануалу по принудительному восстановлению InnoDB. Этот мануал я уже курил раньше и ставил в my.cnf значение innodb_force_recovery от 1 до 6, с попытками стартовать mysql start и перезагрузками, но это ни к чему не приводило. Хотя, возможно, я всётаки делал что-то не так...
Есть у форумчан какие-то замечания/советы/гипотезы?

150802 13:01:17 mysqld_safe Number of processes running now: 0
150802 13:01:17 mysqld_safe mysqld restarted
150802 13:01:18 InnoDB: The InnoDB memory heap is disabled
150802 13:01:18 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150802 13:01:18 InnoDB: Compressed tables use zlib 1.2.8
150802 13:01:18 InnoDB: Using Linux native AIO
150802 13:01:18 InnoDB: Initializing buffer pool, size = 128.0M
150802 13:01:18 InnoDB: Completed initialization of buffer pool
150802 13:01:18 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 37121111598
150802 13:01:18  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 37121144307
150802 13:01:18  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 2484199, file name ./mysql-bin.000579
150802 13:01:19  InnoDB: Waiting for the background threads to start
150802 13:01:20 Percona XtraDB (http://www.percona.com) 5.5.33-MariaDB-31.1 started; log sequence number 37121144307
150802 13:01:20 [Note] Recovering after a crash using mysql-bin
150802 13:01:20 [Note] Starting crash recovery...
150802 13:01:20 [Note] Crash recovery finished.
150802 13:01:20 [Note] Server socket created on IP: '0.0.0.0'.
150802 13:01:20 [Note] Event Scheduler: Loaded 0 events
150802 13:01:20 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.33-MariaDB-log'  socket: '/var/run/mysql/mysql.sock'  port: 3306  openSUSE package
150802 14:02:47 mysqld_safe Number of processes running now: 0
150802 14:02:47 mysqld_safe mysqld restarted
150802 14:02:47 InnoDB: The InnoDB memory heap is disabled
150802 14:02:47 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150802 14:02:47 InnoDB: Compressed tables use zlib 1.2.8
150802 14:02:47 InnoDB: Using Linux native AIO
150802 14:02:47 InnoDB: Initializing buffer pool, size = 128.0M
150802 14:02:47 InnoDB: Completed initialization of buffer pool
150802 14:02:47 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 37131507514
150802 14:02:47  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 37131510251
150802 14:02:48 [ERROR] mysqld: Can't create/write to file '/var/tmp/mysql.9w498H/ibBKvJBf' (Errcode: 2)
150802 14:02:48  InnoDB: Error: unable to create temporary file; errno: 2
150802 14:02:48  InnoDB: Assertion failure in thread 140310867240768 in file dict0dict.c line 737
InnoDB: Failing assertion: dict_foreign_err_file
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
150802 14:02:48 [ERROR] mysqld got signal 6 ;
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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.

Server version: 5.5.33-MariaDB-log
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466709 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x0
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 = 0x0 thread_stack 0x48000
??:0(??)[0xa7cad9]
??:0(??)[0x6dd345]
??:0(??)[0x7f9caa9f39f0]
??:0(??)[0x7f9ca9a0e4c9]
??:0(??)[0x7f9ca9a0f958]
??:0(??)[0x8ca609]
??:0(??)[0x8c10ce]
??:0(??)[0x85df7c]
??:0(??)[0x81a737]
??:0(??)[0x6df2e1]
??:0(??)[0x5cbda3]
??:0(??)[0x5d0f85]
??:0(??)[0x544c9e]
??:0(??)[0x548637]
??:0(??)[0x7f9ca99fabe5]
??:0(??)[0x53f929]
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.
150802 14:02:48 mysqld_safe mysqld from pid file /var/run/mysql/mysqld.pid ended

[Jimson]

Во первых тут не MySQL а мария и еще с percone XtraDB, возможно проблемы специфичны, так как ошибка создания/записи во временный файл выглядит как минимум странно. Вы уже попробовали запускать восстановление с force_recovery>0? Только не делайте этого предварительно не сохранив (cp -a) весь каталог mysql.

Signal 6/11 и портянка про то что это "баг" и надо чего то куда то слать это нормальное поведение mysql. Оно в любой непонятной ситуации с innodb так себя ведет.

Во вторых я сталкивался с фатальными проблемами InnoDB в MySQL, в общем случае автоматически восстановить ничего не получится. Но можно восстановить все вручную:
1) "cp -a" - делаем копию mysql каталога целиком
2) запускаем mysql с опцией innodb_force_recovery=6
3) пробуем сделать дамп всех таблиц кроме максимально нагруженных, в моем случае оказалось достаточным исключить из дампа history и history_uint для того что бы дамп успешно создался.
4) если пункт (2) вы делали на отдельной машине, то с этого момента можно уже запустить боевую базу: крейтим заново базу, создаем zabbix database, заводим пользователей, раздаем права, восстанавливаем таблицы zabbix из бакапа, создаем вручную таблицы которые исключили из дампа, стартуем zabbix, проверяем что все заработало
5) восстанавливаем старые данные из битых таблиц, выгребая из них данные с помощью select *, например

echo "select * from history" | mysql -q -B -N -u username -p zabbix >history_part1.txt
если таблица битая то в конечном итоге команда завершится с ошибкой
wc -l history_part1.txt
5854738495
echo "select * from history offset 5854738500" | mysql -q -B -N -u username -p zabbix >history_part2.txt

ну и так далее, пока всю таблицу не выгребете
затем из полученных файлов скриптом делаете инсерты блоками строк по 10000 и заливаете старые данные

Через задницу, но это mysql, за простоту и относительное быстродействие надо расплачиваться.

[yukra]

так как ошибка создания/записи во временный файл выглядит как минимум странно.

Если только место на разделе не кончилось или диск не посыпался.

[Mihail]

Проверь наличие папки /var/run/mysql/ и наличие к ней прав.
Там есть mysql.sock ?? ( если да попробуй его удалить и запустить СКУЛь )

[AnDrEyKa]

Проверь наличие папки /var/run/mysql/ и наличие к ней прав.
Там есть mysql.sock ?? ( если да попробуй его удалить и запустить СКУЛь )

Такой папки нет и соответственно файла тоже нет. Были в инете советы на тему того, что надо её и файл создать, присвоить соответствующего владельца и повесить нужные атрибуты - не помогло. На всякий случай уточню как запускать:
mysql start
- правильно же?

Если только место на разделе не кончилось или диск не посыпался.

Диск заполнен на 11%. Утилита
fsck -f
аномалий в файловой системе не нашла.

Во первых тут не MySQL а мария и еще с percone XtraDB, возможно проблемы специфичны, так как ошибка создания/записи во временный файл выглядит как минимум странно. Вы уже попробовали запускать восстановление с force_recovery>0? Только не делайте этого предварительно не сохранив (cp -a) весь каталог mysql.

Может я как-то не так его запускаю (mysql start)? Меня смущает то, что мои попытки запустить его не отражаются в логах. В zabbix.err с 02.08.15 новых записей вообще нет, в том же каталоге нашёл ещё лог ошибок с названием linux-qvvt.err, более свежий, но всё равно мои попытки принудительных запусков MySQL там тоже не видны, последняя запись 18.08.15, тоже с ошибками InnoDB в финале:

Version: '5.5.44-MariaDB-log'  socket: '/var/run/mysql/mysql.sock'  port: 3306  openSUSE package
150818 13:27:40 mysqld_safe Number of processes running now: 0
150818 13:27:40 mysqld_safe mysqld restarted
150818 13:27:41 [Note] /usr/sbin/mysqld (mysqld 5.5.44-MariaDB-log) starting as process 10033 ...
150818 13:27:41 InnoDB: The InnoDB memory heap is disabled
150818 13:27:41 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150818 13:27:41 InnoDB: Compressed tables use zlib 1.2.8
150818 13:27:41 InnoDB: Using Linux native AIO
150818 13:27:41 InnoDB: Initializing buffer pool, size = 128.0M
150818 13:27:41 InnoDB: Completed initialization of buffer pool
150818 13:27:41 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 41319608726
150818 13:27:41  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 41319617184
150818 13:27:42  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 6783841, file name ./mysql-bin.000641
150818 13:27:43  InnoDB: Waiting for the background threads to start
150818 13:27:44 Percona XtraDB (http://www.percona.com) 5.5.43-MariaDB-37.2 started; log sequence number 41319617184
150818 13:27:44 [Note] Recovering after a crash using mysql-bin
150818 13:27:44 [Note] Starting crash recovery...
150818 13:27:44 [Note] Crash recovery finished.
150818 13:27:44 [Note] Server socket created on IP: '0.0.0.0'.
150818 13:27:44 [Note] Event Scheduler: Loaded 0 events
150818 13:27:44 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.44-MariaDB-log'  socket: '/var/run/mysql/mysql.sock'  port: 3306  openSUSE package
150818 15:30:46 mysqld_safe Number of processes running now: 0
150818 15:30:46 mysqld_safe mysqld restarted
150818 15:30:46 [Note] /usr/sbin/mysqld (mysqld 5.5.44-MariaDB-log) starting as process 5449 ...
150818 15:30:46 InnoDB: The InnoDB memory heap is disabled
150818 15:30:46 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150818 15:30:46 InnoDB: Compressed tables use zlib 1.2.8
150818 15:30:46 InnoDB: Using Linux native AIO
150818 15:30:46 InnoDB: Initializing buffer pool, size = 128.0M
150818 15:30:46 InnoDB: Completed initialization of buffer pool
150818 15:30:46 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 41342366307
150818 15:30:46  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 41342382035
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 44 row operations to undo
InnoDB: Trx id counter is D31BC00
150818 15:30:47  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 5210054, file name ./mysql-bin.000642
150818 15:30:47  InnoDB: Waiting for the background threads to start
InnoDB: Starting in background the rollback of uncommitted transactions
150818 15:30:47  InnoDB: Rolling back trx with id D31BAC7, 44 rows to undo

InnoDB: Rolling back of trx id D31BAC7 completed
150818 15:30:47  InnoDB: Rollback of non-prepared transactions completed
150818 15:30:48 Percona XtraDB (http://www.percona.com) 5.5.43-MariaDB-37.2 started; log sequence number 41342382035
150818 15:30:48 [Note] Recovering after a crash using mysql-bin
150818 15:30:48 [Note] Starting crash recovery...
150818 15:30:48 [Note] Crash recovery finished.
150818 15:30:48 [Note] Server socket created on IP: '0.0.0.0'.
150818 15:30:48 [Note] Event Scheduler: Loaded 0 events
150818 15:30:48 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.44-MariaDB-log'  socket: '/var/run/mysql/mysql.sock'  port: 3306  openSUSE package
150818 16:50:24 mysqld_safe Number of processes running now: 0
150818 16:50:24 mysqld_safe mysqld restarted
150818 16:50:24 [Note] /usr/sbin/mysqld (mysqld 5.5.44-MariaDB-log) starting as process 23033 ...
150818 16:50:24 InnoDB: The InnoDB memory heap is disabled
150818 16:50:24 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150818 16:50:24 InnoDB: Compressed tables use zlib 1.2.8
150818 16:50:24 InnoDB: Using Linux native AIO
150818 16:50:24 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137756672 bytes) failed; errno 12
150818 16:50:24 InnoDB: Completed initialization of buffer pool
150818 16:50:24 InnoDB: Fatal error: cannot allocate memory for the buffer pool
150818 16:50:24 [ERROR] Plugin 'InnoDB' init function returned error.
150818 16:50:24 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
150818 16:50:24 [ERROR] Unknown/unsupported storage engine: InnoDB
150818 16:50:24 [ERROR] Aborting

150818 16:50:24 [Note] /usr/sbin/mysqld: Shutdown complete

Фраза
150818 16:50:24 InnoDB: Fatal error: cannot allocate memory for the buffer pool
Натолкнула на мысль - может ему просто по каким-то причинам стало памяти мало?

[Jimson]

Уменьшите пул, в этом логе автоматическое recovery завершилось успешно. А вообще складывается впечатление что вы не понимаете что вы делаете и где вы находитесь. Мы тут можем, конечно, что то насоветовать, но это не тех поддержка линукса и оракла. Вы должны, в первую очередь, сами понимать что делаете, иначе можно поломать не только mysql.

[AnDrEyKa]

Уменьшите пул, в этом логе автоматическое recovery завершилось успешно. А вообще складывается впечатление что вы не понимаете что вы делаете и где вы находитесь. Мы тут можем, конечно, что то насоветовать, но это не тех поддержка линукса и оракла. Вы должны, в первую очередь, сами понимать что делаете, иначе можно поломать не только mysql.

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

[yukra]

mysql start - неверно в принципе. mysql - это консольный клиент для сервера mysqld. демон должен называться mysqld и запускается обычно init-скриптом расположенным в /etc/init.d/ через обертку service

То есть обычно это "service mysql start" или "service mysqld start" в зависимости от дистрибутива. Так же можно запустить демон руками "/usr/bin/mysqld_safe > /dev/null 2>&1 &"

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

[AnDrEyKa]

через обертку service

Вот про этот нюанс я и не знал... Честно говоря из опыта ковыряния в какой-то другой *nix-подобной системе я думал что команда "xxxxx start" всегда запускает приложение в качестве сервиса через соответствующий скрипт в init.d...
Вобщем, стоило мне стартануть MySQL через "service", как Забикс у меня ожил и всё увидел Теперь вернусь к девственному бэкапу и попытаюсь понять что именно из моего "метода тыка" помогло. Обязательно отпишусь - вдруг такому как я когда-нибудь пригодится!
Огромное спасибо за помощь!

[AnDrEyKa]

Кажется я понял в чём моя проблема. По каким-то непонятным причинам в /etc/init.d отсутствует скрипт запуска mysql. Причём ссылки на него в папках /etc/init.d/rc3.d и /etc/init.d/rc5.d есть - K50mysql и S50mysql, но они ссылаются на "../mysql", т.е. они мёртвые. Таким образом вручную я могу запустить сервис как указал yukra, но при перезагрузке он сам не стартанёт. Как я понимаю, надёжней взять скрипт именно из забиксового Appliance, чтобы не было косяков связанных с не теми ОСями, не теми путями и т.п. Собственно вопрос - где этот скрипт можно взять? Или чтобы долго не искать - скачать свежий Appliance целиком и оттуда этот скрипт скопировать?

Хотя возникает вопрос - какой же скрипт тогда запускает команда "service mysql start"?... - Эта команда реально запускает сервис...

[yukra]

chkconfig mysql on

?