Mysql Database restore / reinstall / rebuild CentOs Cpanel

Entelekta

Member
Oct 28, 2018
12
0
1
Cologne Germany
cPanel Access Level
Website Owner
Hello

i need your help

After turning off the server and turning it on again, my MySQL database no longer works.

How can I revive mysql with ERROR 2002 (HY000)?:

Scroll down for pics
Root: systemctl status mysqld.service
mysqld.service - MySQL Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/mysqld.service.d

└─limits.conf
Active: failed (Result: start-limit) since Mi 2023-08-09 06:03:03 EDT; 4min 24s ago
Docs: man:mysqld(8)
MySQL :: MySQL 8.1 Reference Manual :: 2.5.9 Managing MySQL Server with systemd
Process: 22421 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=1/FAILURE)
Process: 22389 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)


Aug 09 06:03:03 prof-vds-1.xx-x.com systemd[1]: mysqld.service: control process exited, code=exited status=1
Aug 09 06:03:03 prof-vds-1.xx-x.com systemd[1]: Failed to start MySQL Server.
Aug 09 06:03:03 prof-vds-1.xx-x.com systemd[1]: Unit mysqld.service entered failed state.
Aug 09 06:03:03 prof-vds-1.xx-x.com systemd[1]: mysqld.service failed.
Aug 09 06:03:03 prof-vds-1.xx-x.com systemd[1]: mysqld.service holdoff time over, scheduling restart.
Aug 09 06:03:03 prof-vds-1.xx-x.com systemd[1]: Stopped MySQL Server.
Aug 09 06:03:03 prof-vds-1.xx-x.com systemd[1]: start request repeated too quickly for mysqld.service
Aug 09 06:03:03 prof-vds-1.xx-x.com systemd[1]: Failed to start MySQL Server.
Aug 09 06:03:03 prof-vds-1.xx-x.com systemd[1]: Unit mysqld.service entered failed state.
Aug 09 06:03:03 prof-vds-1.xx-x.com systemd[1]: mysqld.service failed.
Also has
mysql.sock
only 0 bytes so the file exists but without content. See Pics


Do you have a trick / tip?

Please look pictures

Thank you in advance! Bildschirmfoto 2023-08-09 um 12.12.15.png
mysql-server.jpg
 
Last edited by a moderator:

ffeingol

Well-Known Member
PartnerNOC
Nov 9, 2001
963
437
363
cPanel Access Level
DataCenter Provider
Your going to have to provide more details from the MySQL log file. It's typically in /var/log/mysqld.log. The file /var/lib/mysql/mysql.sock (the socket that MySQL creates) is normally 0 bytes.
 
  • Like
Reactions: Entelekta and cPRex

Entelekta

Member
Oct 28, 2018
12
0
1
Cologne Germany
cPanel Access Level
Website Owner
Thanks for reply! ;)


[root@prof-vds-1 ~]# mysql
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)
It was over 160 MB

I deleted mysqld.log contents and
systemctl restart mysqld


Download Full 1 file – 522,6 KB
Title: new_mysqld.log
Or the last lines:
2023-08-09T20:10:28.998364Z 0 [Note] InnoDB: Uncompressed page, stored checksum in field1 1674790193, calculated checksums for field1: crc32 54368264/3619260815, innodb 2873703367, none 3735928559, stored checksum in field2 1674790193, calculated checksums for field2: crc32 54368264/3619260815, innodb 2716907909, none 3735928559, page LSN 3 1418934613, low 4 bytes of LSN at page end 1418934613, page number (if stored to page already) 330, space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an update undo log page
2023-08-09T20:10:28.998372Z 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
2023-08-09 16:10:28 0x7f25fbf46780 InnoDB: Assertion failure in thread 139801117616000 in file ut0ut.cc line 921
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to MySQL Bugs.
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: MySQL :: MySQL 5.7 Reference Manual :: 14.22.2 Forcing InnoDB Recovery
InnoDB: about forcing recovery.
20:10:28 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.

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
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 = 68199 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 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xf80ecb]
/usr/sbin/mysqld(handle_fatal_signal+0x486)[0x80ec06]
/lib64/libpthread.so.0(+0xf630)[0x7f25fbb2b630]
/lib64/libc.so.6(gsignal+0x37)[0x7f25fa513387]
/lib64/libc.so.6(abort+0x148)[0x7f25fa514a78]
/usr/sbin/mysqld[0x7debd8]
/usr/sbin/mysqld(_ZN2ib5fatalD1Ev+0xfd)[0x13e4d3d]
/usr/sbin/mysqld(_Z17buf_dblwr_processv+0x112e)[0x14305be]
/usr/sbin/mysqld(_Z35recv_recovery_from_checkpoint_startm+0x28f0)[0x12ba0e0]
/usr/sbin/mysqld(_Z34innobase_start_or_create_for_mysqlv+0x41bc)[0x1390c3c]
/usr/sbin/mysqld[0x1255f00]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x51)[0x861ae1]
/usr/sbin/mysqld[0xd62015]
/usr/sbin/mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x2f0)[0xd68340]
/usr/sbin/mysqld[0x807164]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0xa85)[0x80a985]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f25fa4ff555]
/usr/sbin/mysqld[0x7fe5e4]
The manual page at MySQL :: MySQL 8.1 Reference Manual :: B.3.3.3 What to Do If MySQL Keeps Crashing contains
information that should help you find out what is causing the crash.
 
Last edited:

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
17,470
2,843
363
cPanel Access Level
Root Administrator
Unfortunately that isn't good news. I'd recommend working through this if you feel comfortable with the process, or reaching out to an experienced database administrator to keep data loss to a minimum.