Никак не поднимается mysql, где лежит файл клиентских настроек?
Добрый день. Ситуация следующая - лег mysql.
service mysqld start - ошибка
все логи перечитаны, все еще ничего непонятно.
Самый главный вопрос где лежит пользовательский файл настроек mysql на сервере?
Вопрос навеян следующим:
Есть бекап, ноября месяца, в меню настроек mysql серверов которого есть 2 строки, о наличии пароля и наличии клиент mysql конфиг.
Так вот, на сейчас эти строки уверяют меня, что конфига на сервере нет.
Предвидя очевидные ответы:
в рабочей версии команда find / -name my.cnf -print выдает три файла, в не рабочей тоже три состав у них одинаковый все файлы ссылаются на сокет который так же есть.
Заранее попрошу осадить нравоучения на счет бекапов.
И заранее спасибо за ответы.
конфиги показывайте,
/etc/my.cnf
содержимое папки (если есть) /etc/my.cnf.d/
как вариант попробовать его запустить просто из командной строки указав его конфиг, и посмотреть что он напишет в stderr
[root@portal conf.d]# head /etc/my.cnf
# Ansible managed
# 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/conf.d/z_bx_custom.cnf
#
[client]
port = 3306
socket = /var/lib/mysqld/mysqld.sock
default-character-set = utf8
Шикарно.
Что в
# 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/conf.d/z_bx_custom.cnf
??
мне честно говоря не очень понятно как он вообще должен запускаться в таком раскладе. конфигурация сделана ансиблом, параметры сервера распиханы в нестандартные места. ок.
я бы полез в свойства юнита Systemd и посмотрел как оно там сделано, может оно должно стартовать не самостоятельно, может его битрикс этот стартует каким то хитровывернутым способом.
короче, идеи есть, но чтобы их проверять - надо сидеть у системы и ковыряться.
По битриксу у меня опыта нет, так что, извините..
Чем больше знаю, тем лучше понимаю, как мало знаю.
Вообще-то пользовательских настроек у mysqld_safe нет, для запуска сервера они не используются.
И настройки именно сервера обычно хранятся в /etc/my.cnf. При ручном запуске mysqld_safe можно указать свой my.cnf.
Настройки пользователя лежат в директории пользователя ~/.my.cnf, и как правило настраивают подключение mysql-клиента к mysqld-серверу. На работу сервера они НЕ ВЛИЯЮТ, они влияют на подключение к серверу.
AUser0, [root@portal ~]# systemctl restart mysql ; tail -n25 /var/log/messages
Job for mysqld.service failed because the control process exited with error code . See "systemctl status mysqld.service" and "journalctl -xe" for details.
Feb 12 18:45:01 portal systemd: Starting User Slice of bitrix.
Feb 12 18:45:01 portal systemd: Started Session 433 of user bitrix.
Feb 12 18:45:01 portal systemd: Starting Session 433 of user bitrix.
Feb 12 18:45:01 portal systemd: Removed slice User Slice of bitrix.
Feb 12 18:45:01 portal systemd: Stopping User Slice of bitrix.
Feb 12 18:46:01 portal systemd: Started Session 434 of user root.
Feb 12 18:46:01 portal systemd: Starting Session 434 of user root.
Feb 12 18:46:01 portal systemd: Created slice User Slice of bitrix.
Feb 12 18:46:01 portal systemd: Starting User Slice of bitrix.
Feb 12 18:46:01 portal systemd: Started Session 435 of user bitrix.
Feb 12 18:46:01 portal systemd: Starting Session 435 of user bitrix.
Feb 12 18:46:01 portal systemd: Removed slice User Slice of bitrix.
Feb 12 18:46:01 portal systemd: Stopping User Slice of bitrix.
Feb 12 18:46:14 portal systemd: Started Session 436 of user root.
Feb 12 18:46:14 portal systemd-logind: New session 436 of user root.
Feb 12 18:46:14 portal systemd: Starting Session 436 of user root.
Feb 12 18:46:25 portal systemd: Starting MySQL Server...
Feb 12 18:46:25 portal mysqld_pre_systemd: my_print_defaults: [Warning] World-wr itable config file '/etc/mysql/conf.d/z_bx_custom.cnf' is ignored.
Feb 12 18:46:25 portal mysqld_pre_systemd: my_print_defaults: [Warning] World-wr itable config file '/etc/mysql/conf.d/z_bx_custom.cnf' is ignored.
Feb 12 18:46:25 portal mysqld: mysqld: [Warning] World-writable config file '/et c/mysql/conf.d/z_bx_custom.cnf' is ignored.
Feb 12 18:46:26 portal mysqld: Unable to determine if daemon is running: Success
Feb 12 18:46:26 portal systemd: mysqld.service: control process exited, code=exi ted status=1
Feb 12 18:46:26 portal systemd: Failed to start MySQL Server.
Feb 12 18:46:26 portal systemd: Unit mysqld.service entered failed state.
Feb 12 18:46:26 portal systemd: mysqld.service failed.
Мда, из подробностей только mysqld.service: control process exited, code=exi ted status=1.
Для определения причины проблемы - маловато данных.
Запускайте killall mysqld_safe ; mysqld_safe, может хоть так его ошибки увидим...
--rw-r--r-- 1 root root 0 май 21 2018 z_bx_custom.cnf
сейчас имею такое.
при запуске с systemctl
[root@portal conf.d]# systemctl restart mysql ; tail -n25 /var/log/messages
Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.
Feb 12 19:17:01 portal systemd: Starting Session 5 of user bitrix.
Feb 12 19:17:01 portal systemd: Removed slice User Slice of bitrix.
Feb 12 19:17:01 portal systemd: Stopping User Slice of bitrix.
Feb 12 19:18:01 portal systemd: Created slice User Slice of bitrix.
Feb 12 19:18:01 portal systemd: Starting User Slice of bitrix.
Feb 12 19:18:01 portal systemd: Started Session 6 of user bitrix.
Feb 12 19:18:01 portal systemd: Starting Session 6 of user bitrix.
Feb 12 19:18:01 portal systemd: Started Session 7 of user root.
Feb 12 19:18:01 portal systemd: Starting Session 7 of user root.
Feb 12 19:18:02 portal systemd: Removed slice User Slice of bitrix.
Feb 12 19:18:02 portal systemd: Stopping User Slice of bitrix.
Feb 12 19:19:02 portal systemd: Started Session 9 of user root.
Feb 12 19:19:02 portal systemd: Starting Session 9 of user root.
Feb 12 19:19:02 portal systemd: Created slice User Slice of bitrix.
Feb 12 19:19:02 portal systemd: Starting User Slice of bitrix.
Feb 12 19:19:02 portal systemd: Started Session 8 of user bitrix.
Feb 12 19:19:02 portal systemd: Starting Session 8 of user bitrix.
Feb 12 19:19:02 portal systemd: Removed slice User Slice of bitrix.
Feb 12 19:19:02 portal systemd: Stopping User Slice of bitrix.
Feb 12 19:19:52 portal systemd: Starting MySQL Server...
Feb 12 19:19:53 portal mysqld: Unable to determine if daemon is running: Success
Feb 12 19:19:53 portal systemd: mysqld.service: control process exited, code=exited status=1
Feb 12 19:19:53 portal systemd: Failed to start MySQL Server.
Feb 12 19:19:53 portal systemd: Unit mysqld.service entered failed state.
Feb 12 19:19:53 portal systemd: mysqld.service failed.
[root@portal ~]# killall mysqld_safe mysqld ; mysqld_safe --console
mysqld_safe: процесс не найден
mysqld: процесс не найден
-bash: mysqld_safe: команда не найдена
напоминаю, что ОС - Centos 7
нашел логи мускл.
2021-02-12T06:58:46.408627Z 0 [Note] InnoDB: Uses event mutexes
2021-02-12T06:58:46.408631Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2021-02-12T06:58:46.408635Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.7
2021-02-12T06:58:46.408641Z 0 [Note] InnoDB: Using Linux native AIO
2021-02-12T06:58:46.412793Z 0 [Note] InnoDB: Number of pools: 1
2021-02-12T06:58:46.421153Z 0 [Note] InnoDB: Using CPU crc32 instructions
2021-02-12T06:58:46.424856Z 0 [Note] InnoDB: Initializing buffer pool, total size = 6G, instances = 8, chunk size = 128M
2021-02-12T06:58:46.668310Z 0 [Note] InnoDB: Completed initialization of buffer pool
2021-02-12T06:58:46.741337Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2021-02-12T06:58:46.934793Z 0 [Note] InnoDB: Recovering partial pages from the parallel doublewrite buffer at /var/lib/mysql/xb_doublewrite
2021-02-12T06:58:47.590513Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2021-02-12T06:58:47.769776Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 186078784162
2021-02-12T06:58:49.214514Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 186078964268
2021-02-12T06:58:49.216352Z 0 [Note] InnoDB: Database was not shutdown normally!
2021-02-12T06:58:49.216366Z 0 [Note] InnoDB: Starting crash recovery.
2021-02-12T06:58:49.443509Z 0 [Note] InnoDB: Database page corruption or a failed file read of page [page id: space=0, page number=532]. Trying to recover it from the doublewrite buffer.
2021-02-12T06:58:49.443579Z 0 [ERROR] InnoDB: Dump of the page:
2021-02-12T06:58:49.443591Z 0 [Note] InnoDB: Page dump in ascii and hex (16384 bytes):
тут дамп
InnoDB: End of page dump
2021-02-12T06:58:49.494442Z 0 [Note] InnoDB: Uncompressed page, stored checksum in field1 2049606457, calculated checksums for field1: crc32 1145418102/2917252669, innodb 1666644705, none 3735928559, stored checksum in field2 2049606457, calculated checksums for field2: crc32 1145418102/2917252669, innodb 2223021145, none 3735928559, page LSN 43 1395177334, low 4 bytes of LSN at page end 1395177334, page number (if stored to page already) 532, space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an update undo log page
2021-02-12T06:58:49.494456Z 0 [ERROR] InnoDB: Dump of corresponding page in doublewrite buffer:
2021-02-12T06:58:49.494462Z 0 [Note] InnoDB: Page dump in ascii and hex (16384 bytes):
и тут дамп
InnoDB: End of page dump
2021-02-12T06:58:49.546252Z 0 [Note] InnoDB: Uncompressed page, stored checksum in field1 2049606457, calculated checksums for field1: crc32 1847096793/2883168024, innodb 2230298171, none 3735928559, stored checksum in field2 2049606457, calculated checksums for field2: crc32 1847096793/2883168024, innodb 2223021145, none 3735928559, page LSN 43 1395177334, low 4 bytes of LSN at page end 1395177334, page number (if stored to page already) 532, space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an update undo log page
2021-02-12T06:58:49.546277Z 0 [ERROR] [FATAL] InnoDB: The page in the doublewrite buffer is corrupt. Cannot continue operation. You can try to recover the database with innodb_force_recovery=6
2021-02-12 09:58:49 0x7f338c65a880 InnoDB: Assertion failure in thread 139859375532160 in file ut0ut.cc line 943
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.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
06:58:49 UTC - 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.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/
key_buffer_size=100663296
read_buffer_size=131072
max_used_connections=0
max_threads=86
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1677119 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 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 = 0 thread_stack 0x80000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xef5c1b]
/usr/sbin/mysqld(handle_fatal_signal+0x471)[0x79b061]
/lib64/libpthread.so.0(+0xf6d0)[0x7f338c2426d0]
/lib64/libc.so.6(gsignal+0x37)[0x7f338a343277]
/lib64/libc.so.6(abort+0x148)[0x7f338a344968]
/usr/sbin/mysqld[0x7687ec]
/usr/sbin/mysqld(_ZN2ib5fatalD1Ev+0xfd)[0x118284d]
/usr/sbin/mysqld(_Z17buf_dblwr_processv+0x10ee)[0x11d144e]
/usr/sbin/mysqld(_Z35recv_recovery_from_checkpoint_startm+0x1f90)[0x1052820]
/usr/sbin/mysqld(_Z34innobase_start_or_create_for_mysqlv+0x3f11)[0x112dff1]
/usr/sbin/mysqld[0xfe27d1]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x51)[0x7fd031]
/usr/sbin/mysqld[0xce7545]
/usr/sbin/mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x2f0)[0xced600]
/usr/sbin/mysqld[0x7913bd]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0xabd)[0x794e3d]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f338a32f445]
/usr/sbin/mysqld[0x78a234]
You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.
как я понял, полетела БД.
Может, есть какая-то возможность попробовать ее восстановить?
innodb восстанавливается с помощью mysql, который, собственно, не стартует.
Да, судя по всему - физически побились файлы базы данных.
Делайте backup директории /var/lib/mysql (или где у вас хранится вся база), а потом добавляйте параметр "innodb_force_recovery=6" в файл my.cnf, и пытайтесь еще раз стартануть сервис, стандартным путем. Возожно он сам справится с восстановлеием файлов... Если нет - вы же делали ежедневные/еженедельные бэкапы?
AUser0, нет. вообще бекапы виртуальных машин были настроены на каждую неделю, но после падения, выяснилось что все встало в январе. esxi не на мне, а вот битрикс на мне, поэтому собственно, и создан этот топик. восстановить машину с бекапа минут 20 времени.
форс рековери ничего не дал, может, просто я что то не так делаю. После изменений в my.cnf
и команды /service mysqld restart
получал
Active: failed (Result: start-limit) since Пт 2021-02-12 10:53:32 MSK; 10s ago
Так проверьте, не работает-ли mysql после первого запуска. Вполне возможно он там таблицы восстанавливает, файлы копирует-прочесывает, вот-вот все будет сделано, а вы его пытаетесь перезапустить в этот момент...
AUser0,
случилось невероятное.
тс горем пополам, на форс_рекавери=6 поднялся мускл.
Главный вопрос сейчас - что мне теперь делать?)
Сейчас сделал дамп бд битрикса.
так что сделал проверку всех баз - особого результата не получил, после удаления строчки форс_рекавери все так же не стартует мускл.
Копия битой базы хранится?
Самое простое: после полного MySQL-дампа удалить базу, переключить в нормальный режим, и залить полный MySQL-дамп. Так вы получите работоспособную базу в обычном режиме.
НО, большое НО! Останется вопрос в корректности данных в базе. Ведь где-то в таблицах могут хранится значения, которые не соответствуют значеням в других таблицах... И тут уже нужна полная проверка от производителя (Битрикс-а).
Ещё в логах можно высматривать, что говорит MySQL, может какие-то отдельные таблицы сбойные?
Тогда можно удалить+залить только сбойные таблицы, вдруг и запустится в обычном режиме.
AUser0, да, дамп+спамшот виртуальной машины, всегда смогу откатиться. столкнулся с новой проблемой.
переименовал mysql в бекап, создаю новый каталог mysql, даю права.
при попытке mysql_install_db --user=mysql --verbose
получаю
2021-02-14 13:54:52 [WARNING] mysql_install_db is deprecated. Please consider switching to mysqld --initialize
2021-02-14 13:54:52 [ERROR] The data directory needs to be specified.
Простой
