Форум

Добрый день!

ИМЕЕТСЯ
Виртуальная машина версия 5.1.1, которая нормально работала, пока не произошел какой-то креш на серваке.
Теперь Mysql не запускается  с ошибкой:

НА ЭКРАНЕ:
------------------------------------------------------
Mysql connect error [localhost, 127.0.0.1]: Can't connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (2) (400)
/home/bitrix/www/bitrix/modules/main/lib/db/mysqlconnection.php:50
----------------------------------------------------

Ранее встречавшиеся ошибки - это не то. (Место хватает - проверили, файла mysqld.sock нет)


КОНФ.ФАЙЛ
-----------------------------------------------------------------------------------------------
#
# Basic mysql configuration. Use bvat for advanced settings.
# Parameters set by bvat are stored in /etc/mysql/conf.d/bvat.cnf.
# If you want to change any parameter, you'll have to redefine it in /etc/mysql/co
nf.d/z_bx_custom.cnf
#

[client]
port = 3306
socket = /var/lib/mysqld/mysqld.sock
default-character-set = utf8

[mysqld_safe]
nice = 0
socket = /var/lib/mysqld/mysqld.sock

[mysqld]

# Basic mysql server configuration
user = mysql
port = 3306
basedir = /usr
datadir = /var/lib/mysql
socket = /var/lib/mysqld/mysqld.sock
skip-external-locking
default-storage-engine = innodb
pid-file = /var/run/mysqld/mysqld.pid
transaction-isolation = READ-COMMITTED
max_allowed_packet = 16M
myisam-recover = BACKUP
expire_logs_days = 10
max_binlog_size = 100M

# Cache parameters
query_cache_size = 32M
table_open_cache = 4096
thread_cache_size = 32
key_buffer = 16M
thread_stack = 128K
join_buffer_size = 2M
sort_buffer_size = 2M

# Parameters for temporary tables
tmpdir = /tmp
max_heap_table_size     = 32M
tmp_table_size = 32M

# InnoDB parameters
innodb_file_per_table
innodb_buffer_pool_size = 32M
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 64M
innodb_flush_method = O_DIRECT

# Database charset parameters
character-set-server = utf8
collation-server = utf8_unicode_ci
init-connect = "SET NAMES utf8 COLLATE utf8_unicode_ci"
skip-character-set-client-handshake
skip-name-resolve

[mysqldump]
quick
quote-names
max_allowed_packet = 16M
default-character-set = utf8

[mysql]

[isamchk]
key_buffer = 16M

# Include additional settings
!includedir /etc/mysql/conf.d/
-------------------------------------------------------------------------------------

НАСТРОЙКИ ВСЕ СТАНДАРТНЫЕ КАКИМИ ОНИ БЫЛИ В ВИРТУАЛЬНОЙ МАШИНЕ 5.1.1 (2014-15 г.)

В ЛОГЕ:
---------------------------------------------
/usr/libexec/mysqld[0x81bc6d9]
/usr/libexec/mysqld(_Z11plugin_initPiPPci+0x9b7)[0x81c0547]
/usr/libexec/mysqld[0x81376bf]
/usr/libexec/mysqld(_Z11mysqld_mainiPPc+0x452)[0x813ab52]
/usr/libexec/mysqld(main+0x28)[0x812fa58]
/lib/libc.so.6(__libc_start_main+0xe6)[0x23cd36]
/usr/libexec/mysqld[0x812f991]
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.
171205 08:20:12 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
-----------------------------------------------

В Мессаджес
---------------------------------------------------------
[root@portal mysql]# tail /var/log/messages
Dec  5 08:51:02 portal ntpd[1690]: 0.0.0.0 c61c 0c clock_step +5.858335 s
Dec  5 08:51:02 portal ntpd[1690]: 0.0.0.0 c615 05 clock_sync
Dec  5 08:51:03 portal ntpd[1690]: 0.0.0.0 c618 08 no_sys_peer
Dec  5 09:00:55 portal ntpd[1690]: 0.0.0.0 c613 03 spike_detect +5.846018 s
Dec  5 09:03:58 portal dhclient[1408]: DHCPREQUEST on eth0 to 192.168.71.254 port 67 (xid=0x3821c24d)
Dec  5 09:03:58 portal dhclient[1408]: DHCPACK from 192.168.71.254 (xid=0x3821c24d)
Dec  5 09:04:01 portal dhclient[1408]: bound to 192.168.71.128 -- renewal in 695 seconds.
Dec  5 09:06:34 portal ntpd[1690]: 0.0.0.0 c61c 0c clock_step +5.866029 s
Dec  5 09:06:34 portal ntpd[1690]: 0.0.0.0 c614 04 freq_mode
Dec  5 09:06:35 portal ntpd[1690]: 0.0.0.0 c618 08 no_sys_peer
----------------------------------------------------------------------

Короче, все плохо, люди советуют поднять БД из дампа.
Я не очень понимаю, побились файлы нашей БД или самого ПО Mysql

ВНИМАНИЕ ВОПРОС, ВЕРНЕЕ 2:

1) Есть ли какой-то вариант восстановления без отката к дампу? Возможности нанять линуксоида нет, действуем сами по инструкциям, так что многого не знаем.
2) Если восстанавливаться из дампа, я планирую заодно тогда уж ПЕРЕЙТИ на VMBITRIX 7.2
Проблема в том, что дампы лежат в структуре сайта локально (а не в облаке), а как их оттуда забрать - я не знаю, перерыла справочники, знаю только как туда СКАЧАТЬ например wget-om

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