• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

MySQL just died like-that, Plesk dies, too now

K

KenanS

Guest
Hi there.

(Locally, my server is called cdn, so instead of an address, I use "cdn" here)

It began like that: I wanted to access cdn:8443 - which worked, but showed a blank page.
I got calls of clients unable to use their services, which made me get onto the server using SSH; using top I noticed mysqld restarting every 1 second. When looking in the logs of my apps, they failed any connection to mysql.

When typing "mysql" first time, it shows:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)

The second time:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

Typing "/etc/init.d/mysql start" returns:
Starting service MySQL done

Doing "/etc/init.d/mysql force-reload" returns:
Restarting service MySQL
Shutting down service MySQL done
Starting service MySQL done

MySQL shows that in its log:
thd=(nil)
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...
Cannot determine thread, fp=0xb, backtrace may not be correct.
Bogus stack limit or frame pointer, fp=0xb, stack_bottom=0x445e0000, thread_stack=262144, aborting backtrace.
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
120223 19:29:15 mysqld restarted
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
120223 19:29:15 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...
120223 19:29:15 InnoDB: Started; log sequence number 0 340652993
120223 19:29:15 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.51a' socket: '/var/lib/mysql/mysql.sock' port: 3306 SUSE MySQL RPM
120223 19:29:16 - 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=258048
max_used_connections=1
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 92783 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=(nil)
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...
Cannot determine thread, fp=0xb, backtrace may not be correct.
Bogus stack limit or frame pointer, fp=0xb, stack_bottom=0x45530000, thread_stack=262144, aborting backtrace.
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
120223 19:29:16 mysqld restarted
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
120223 19:29:16 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...
120223 19:29:16 InnoDB: Started; log sequence number 0 340652993
120223 19:29:16 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.51a' socket: '/var/lib/mysql/mysql.sock' port: 3306 SUSE MySQL RPM

"ps faux" returns that execution tree of MySQL:
root 4429 0.2 0.0 13436 1704 pts/0 S 19:33 0:03 /bin/sh /usr/bin/mysqld_safe --mysqld=mysqld --user=mysql --pid-file=/var/lib/mysql/mysqld.pid --socket=/var/lib/mysql/mysql.sock --datadir=/var/li
mysql 3436 0.0 0.0 142260 19928 pts/0 Sl 19:56 0:00 \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/mysqld.pid --skip-external-locking --port=3306

Doing "mysql -u admin" reveals:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

---

That seemed to me like that worst case scenario; I wanted to backup.
The server responded to "/usr/local/psa/bin/pleskbackup server -v --output-file=/srv/backup", with:
-------------- Start print backup log hire --------------
<?xml version="1.0" encoding="UTF-8"?>
<execution-result status="error">
<object name="backup" type="backupowner">
<message severity="error" code="msgtext">Cannot detect product mode</message>
</object>
<object name="backup" type="backupowner">
<message severity="error" code="msgtext">Unable to execute SQL: Unknown collation 'ascii_bin' in table 'misc.frm' definition</message>
</object>
<object name="backup" type="backupowner">
<message severity="error" code="msgtext">Unable to execute SQL: Unknown collation 'ascii_bin' in table 'misc.frm' definition</message>
</object>
<object name="backup" type="backupowner">
<message severity="error" code="msgtext">Unable to execute SQL: Unknown collation 'ascii_general_ci' in table 'IP_Addresses.frm' definition</message>
</object>
[..]
<object name="backup" type="backupowner">
<message severity="error" code="msgtext">Unable to execute SQL: Unknown collation 'ascii_general_ci' in table 'domains.frm' definition</message>
</object>
[...]
</object>
<object name="backup" type="backupowner">
<message severity="error" code="msgtext">Unable to execute SQL: Unknown collation 'ascii_bin' in table 'clients.frm' definition</message>
</object>
[....]
<object name="backup" type="backupowner">
<message severity="error" code="msgtext">Unable to execute SQL: Unknown collation 'ascii_bin' in table 'misc.frm' definition</message>
</object>
<object name="backup" type="backupowner">
<message severity="error" code="msgtext">Unable to execute SQL: Unknown collation 'ascii_bin' in table 'misc.frm' definition</message>
</object>
<object name="backup" type="backupowner">
<message severity="error" code="msgtext">Unable to create dump: Cannot find client ''! at /usr/local/psa/PMM/agents/PleskX/PleskStructure.pm line 213.

</message>
</object>
<object name="backup" type="backupowner">
<message severity="warning" code="msgtext">Timeout occured during mysql query. Reconnecting.</message>
</object>
[...]
<object name="backup" type="backupowner">
<message severity="warning" code="msgtext">Timeout occured during mysql query. Reconnecting.</message>
</object>
<object name="backup" type="backupowner">
<message severity="warning" code="msgtext">Timeout occured during mysql query. Reconnecting.</message>
</object>
</execution-result>
-------------- End print backup log hire --------------

You can view additional information in the log file located in /usr/local/psa/PMM/sessions/2012-02-23-195959.329 directory. This directory will be removed automatically after 30 days

Runtime error: The backup failed with errors!

Thank you all for your help,
I will need it. :(
 
Back
Top