• 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

Issue mariadb restarts every day at 8.30 and I don't know why -> (ERROR mysqld got signal 11)

scsjcm

scsjcm

New Pleskian
Server operating system version
Debian 11.6
Plesk version and microupdate number
Plesk Obsidian Versión 18.0.50 Actualización 2, última actualización el 15/Feb/2023 07:39
Hello everyone,
It may not be the best place, I apologize in advance if I disturb someone :)

A couple of months ago I'm going crazy with a reboot that happens every day at 8.30 - 9.30 and I can't find it.
I have checked the crons, and I have not found any task that makes the mariadb restart and gives me "ERROR mysqld got signal 11"
I don't see anything in the log that indicates the origin of the error, and I think it's not due to any memory problem.

What I have seen is that at this time some process starts that I don't know where it comes from that does a "SHOW TABLE STATUS FROM" of all the databases... this process takes approx 30-40 minutes (depending on the system load)... I have on server about 2500 databases with about 150 tables each.

It seems to me that this process is executed somehow and checks all the databases to confirm that they are ok before doing the XXXXXX process that ends up restarting the server with the error "ERROR mysqld got signal 11"

I have not been able to see who starts or how this process starts, and I think that something in PLESK or MARIADB is starting and ends with the error.
 
ChristophRo said:
could by a backup process that dumps mysql databases.
i've seen such things to cause crashes of the mysql process, if there are some irregularities/corruptions in one of the databases.
Click to expand...
thanks for your reply
i investigate and i think is something about task-script.php inside DailyMaintainance i try to dissable this script
 
scsjcm said:
i investigate and i think is something about task-script.php inside DailyMaintainance i try to dissable this script
Click to expand...
Better check /var/log/messages for messages on corrupt database tables. Very likely a crash is due to such.
 
You can also try to dump/backup the mysql databases manually and see if you can reproduce the crash - and if yes, on which database it happens.
The following script should be able to do that. (works out of the box on any Debian/Ubuntu system, though you may want to change the path for the dumps)

Code: 
#!/bin/bash

# config section
########################################
BACKUPDIR="/root/_mysqldumps"             #directory where the backups get saved
#
FILEEXT="sql.gz"                          #file extensions of the database dumps
EXCLUDEDB="performance_schema|phpmyadmin" #excluded databases from the backup
MYSQLDUMP="/usr/bin/mysqldump"            #path to mysqldump binary
CONFFILE="/etc/mysql/debian.cnf"          #debian mysql defaults file that contains login info
########################################

# get list of databases to backup
if [ "$1" ]
then
    # lookup requested mysql database
    ALLMYSQLDBS=$(mysql --defaults-file=$CONFFILE -N -B -e "SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = '$1'")
else
    # get list of all mysql databases on the server
    ALLMYSQLDBS=$(mysql --defaults-file=$CONFFILE -N -B -e "SHOW DATABASES" | grep -vE $EXCLUDEDB)
fi

# dump each database and compress it ##
if [ "$ALLMYSQLDBS" ]
then
 for i in $ALLMYSQLDBS
  do
    TIMESTAMP=$(date +%Y%m%d%H%M)
    FILENAME="$TIMESTAMP.$FILEEXT"
    mkdir -p $BACKUPDIR/$i
    # -c        Use complete insert statements
    # -K        disable-keys, "ALTER TABLE tb_name DISABLE/ENABLE KEYS" will be put in the output
    # -Q        Quote table and column names with backticks (`)
    # -F        Flush logs file in server before starting dump
    # -e        extended-insert, Allows utilization of the new, much faster INSERT syntax.
    # -i        Dump Comments
    # -E        Dump Events
    # -R        Dump stored routines (functions and procedures).
    $MYSQLDUMP --defaults-file=$CONFFILE -c -K -Q -F -e -i -E -R --single-transaction --add-drop-table --no-autocommit $i | gzip -c  > $BACKUPDIR/$i/$FILENAME
    echo -e "\033[32mDatabase \033[33m$i\033[32m dumped into \033[33m$BACKUPDIR/$i/$FILENAME\033[0m"
 done
else
 echo -e "\033[31mDatabase [\033[33m$1\033[31m] does not exist!\033[0m"
 exit 1
fi
 
ChristophRo said:
You can also try to dump/backup the mysql databases manually and see if you can reproduce the crash - and if yes, on which database it happens.
The following script should be able to do that. (works out of the box on any Debian/Ubuntu system, though you may want to change the path for the dumps)

Code: 
#!/bin/bash

# config section
########################################
BACKUPDIR="/root/_mysqldumps"             #directory where the backups get saved
#
FILEEXT="sql.gz"                          #file extensions of the database dumps
EXCLUDEDB="performance_schema|phpmyadmin" #excluded databases from the backup
MYSQLDUMP="/usr/bin/mysqldump"            #path to mysqldump binary
CONFFILE="/etc/mysql/debian.cnf"          #debian mysql defaults file that contains login info
########################################

# get list of databases to backup
if [ "$1" ]
then
    # lookup requested mysql database
    ALLMYSQLDBS=$(mysql --defaults-file=$CONFFILE -N -B -e "SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = '$1'")
else
    # get list of all mysql databases on the server
    ALLMYSQLDBS=$(mysql --defaults-file=$CONFFILE -N -B -e "SHOW DATABASES" | grep -vE $EXCLUDEDB)
fi

# dump each database and compress it ##
if [ "$ALLMYSQLDBS" ]
then
 for i in $ALLMYSQLDBS
  do
    TIMESTAMP=$(date +%Y%m%d%H%M)
    FILENAME="$TIMESTAMP.$FILEEXT"
    mkdir -p $BACKUPDIR/$i
    # -c        Use complete insert statements
    # -K        disable-keys, "ALTER TABLE tb_name DISABLE/ENABLE KEYS" will be put in the output
    # -Q        Quote table and column names with backticks (`)
    # -F        Flush logs file in server before starting dump
    # -e        extended-insert, Allows utilization of the new, much faster INSERT syntax.
    # -i        Dump Comments
    # -E        Dump Events
    # -R        Dump stored routines (functions and procedures).
    $MYSQLDUMP --defaults-file=$CONFFILE -c -K -Q -F -e -i -E -R --single-transaction --add-drop-table --no-autocommit $i | gzip -c  > $BACKUPDIR/$i/$FILENAME
    echo -e "\033[32mDatabase \033[33m$i\033[32m dumped into \033[33m$BACKUPDIR/$i/$FILENAME\033[0m"
 done
else
 echo -e "\033[31mDatabase [\033[33m$1\033[31m] does not exist!\033[0m"
 exit 1
fi
Click to expand...
great script :)
 
Peter Debik said:
Better check /var/log/messages for messages on corrupt database tables. Very likely a crash is due to such.
Click to expand...

I found 2 databases that contained corrupted information, and I think this was the reason.

There is a process that is launched in the morning around 8.00 that loops through all the databases with the command : "SHOW TABLE STATUS FROM databasename"
This process reached these databases, and caused the error and restarted the mysql service.

Today I checked it and everything worked OK. :)

By the way, can this process be disabled?
or change the time to run this loop to check all DB?
...because it consumes server resources at a time 8.00-9.00 when I have many clients connected.
 
Peter Debik said:
With
# grep -ri "/etc/cron.daily" /etc/cron.d/dailyjobs
you can see the daily maintenance time. I have never tried to change it myself, but I also do not see why this should not be possible to move it to a different time. A bit more can be seen here:
Click to expand...
perfect, i change hour dailyjobs execution :)

and you know if it is possible to disable the execution of the process... "SHOW TABLE STATUS FROM databasename" ... I think it's something inside plesk maintenance
 
I do not think these tasks should be touched at all. If developers put it there, better leave it there. It will have a purpose. These guys never do anything without good reason. I am not sure if it is possible to remove it, but removing it will for sure impact something, whatever that will be.
 
Peter Debik said:
I do not think these tasks should be touched at all. If developers put it there, better leave it there. It will have a purpose. These guys never do anything without good reason. I am not sure if it is possible to remove it, but removing it will for sure impact something, whatever that will be.
Click to expand...
thanks :)
 
Peter Debik said:
With
# grep -ri "/etc/cron.daily" /etc/cron.d/dailyjobs
you can see the daily maintenance time. I have never tried to change it myself, but I also do not see why this should not be possible to move it to a different time. A bit more can be seen here:
Click to expand...
I have changed the execution time, but the process has been executed at the same time as always.
I think this process is launched in some different way.
 
Peter Debik said:
Yes, probably it is. It may not be a Plesk process.
Click to expand...
I don't know if it's a coincidence....
but since the installation of the new version 18.0.51 of plesk (YESTERDAY UPDATE) ---> TODAY the "SHOW TABLE STATUS FROM databasename" process that looped in all the databases has not been carried out for me.

I think something happened in the last plesk update, and it didn't install completely correctly.... this should produce a "SELF-REPAIR DAILY SYSTEM PLESK"

Finally ... installed the new plesk update 18.0.51... it works fine.
 
scsjcm said:
I don't know if it's a coincidence....
but since the installation of the new version 18.0.51 of plesk (YESTERDAY UPDATE) ---> TODAY the "SHOW TABLE STATUS FROM databasename" process that looped in all the databases has not been carried out for me.

I think something happened in the last plesk update, and it didn't install completely correctly.... this should produce a "SELF-REPAIR DAILY SYSTEM PLESK"

Finally ... installed the new plesk update 18.0.51... it works fine.
Click to expand...
forget this post, today continue with check all tables :(
 
You must log in or register to reply here.

Similar threads

TimReeves
Resolved MariaDB Update to 10.11.7 via Plesk 18.0.60 on Debian 10
Replies
1
Views
146
TimReeves
TimReeves
F
Issue Can't restart Maria since upgrade to 18.0.41
Replies
6
Views
4K
Nasdaq
Nasdaq
M
Issue DB query failed: SQLSTATE[HY000] [2002] No such file or directory
Replies
3
Views
1K
Peter Debik
P
Endre
Issue Server Error 500 Plesk\Exception\Database DB query failed: SQLSTATE[HY000] [2002] No such file or directory
Replies
15
Views
7K
MihaiNecreala
M
nisamudeen97
Issue Mysql service stops with [ERROR] InnoDB: CORRUPT LOG RECORD FOUND
Replies
0
Views
1K
nisamudeen97
nisamudeen97
Back
Top