Any operations with the asteriskcdrdb database lead to a fail

Hello, I have some issue.
When I using the command:
mysqldump asteriskcdrdb -uroot -p > /home/asterisk/backup/backup.sql
I get an error:
mysqldump: Got error: 2013: “Lost connection to MySQL server during query” when using LOCK TABLES

When I using the command mysqlcheck --repair --all-databases,
I get an error:
note : The storage engine for the table doesn’t support repair
mysqlcheck: Got error: 2013: Lost connection to MySQL server during query when executing 'REPAIR TABLE … ’


my.cnf

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
#innodb_force_recovery = 4

net_buffer_length=1M
max_allowed_packet=500M
tmp_table_size = 64M
wait_timeout=604800
thread_cache_size=100
innodb_buffer_pool_size=6G
table_open_cache=10000
innodb_purge_threads=1

[mysqldump]
max_allowed_packet=1300M
#net_read_timeout=3600
#net_write_timeout=3600

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

#
# include all files from the config directory

!includedir /etc/my.cnf.d


mariadb.log

InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: about forcing recovery.
200504 23:10:13 [ERROR] 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.

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.

Server version: 5.5.60-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=1
max_threads=153
thread_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466718 K bytes of memory
Hope that’s ok; if not, decrease some variables in the equation.

Thread pointer: 0x5575e47be210
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 = 0x7fde0c5bad80 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5575d8b1ecbd]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5575d87334a5]
sigaction.c:0(__restore_rt)[0x7fde0c2885d0]
:0(__GI_raise)[0x7fde0a9b22c7]
:0(__GI_abort)[0x7fde0a9b39b8]
/usr/libexec/mysqld(+0x834140)[0x5575d8ac3140]
/usr/libexec/mysqld(+0x721be8)[0x5575d89b0be8]
/usr/libexec/mysqld(+0x6f74cb)[0x5575d89864cb]
/usr/libexec/mysqld(+0x6f7f94)[0x5575d8986f94]
/usr/libexec/mysqld(_ZN7handler7ha_openEP5TABLEPKcij+0x33)[0x5575d87373e3]
/usr/libexec/mysqld(_Z21open_table_from_shareP3THDP11TABLE_SHAREPKcjjjP5TABLEb+0x70a)[0x5575d8698b3a]
/usr/libexec/mysqld(_Z10open_tableP3THDP10TABLE_LISTP11st_mem_rootP18Open_table_context+0x1020)[0x5575d85c4d90]
/usr/libexec/mysqld(_Z11open_tablesP3THDPP10TABLE_LISTPjjP19Prelocking_strategy+0x5b5)[0x5575d85c6575]
/usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x39b6)[0x5575d8604fc6]
/usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x5575d8608445]
/usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1750)[0x5575d860a4a0]
/usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5575d86bca22]
/usr/libexec/mysqld(handle_one_connection+0x4a)[0x5575d86bcaca]
pthread_create.c:0(start_thread)[0x7fde0c280dd5]
/lib64/libc.so.6(clone+0x6d)[0x7fde0aa7a02d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7fdc40100c58): LOCK TABLES cdr READ /*!32311 LOCAL /,cel READ /!32311 LOCAL /,queuelog READ /!32311 LOCAL */
Connection ID (thread ID): 7
Status: NOT_KILLED

Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=off

information that should help you find out what is causing the crash.
200504 23:10:13 mysqld_safe Number of processes running now: 0
200504 23:10:13 mysqld_safe mysqld restarted
200504 23:10:13 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 16570 …
200504 23:10:13 [Warning] Changed limits: max_open_files: 1024 max_connections: 151 table_cache: 431
200504 23:10:13 InnoDB: The InnoDB memory heap is disabled
200504 23:10:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins
200504 23:10:13 InnoDB: Compressed tables use zlib 1.2.7
200504 23:10:13 InnoDB: Using Linux native AIO
200504 23:10:13 InnoDB: Initializing buffer pool, size = 6.0G
200504 23:10:14 InnoDB: Completed initialization of buffer pool
200504 23:10:14 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
InnoDB: Restoring possible half-written data pages from the doublewrite buffer…
200504 23:10:14 InnoDB: Error: page 32769 log sequence number 7128597652
InnoDB: is in the future! Current system log sequence number 6861191096.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: for more information.
200504 23:10:14 InnoDB: Error: page 131073 log sequence number 7253880629
InnoDB: is in the future! Current system log sequence number 6861191096.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files.
InnoDB: for more information.
200504 23:10:14 InnoDB: Error: page 65537 log sequence number 7251938077
InnoDB: is in the future! Current system log sequence number 6861191096.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: for more information.
200504 23:10:14 InnoDB: Waiting for the background threads to start
200504 23:10:15 Percona XtraDB 5.5.59-MariaDB-38.11 started; log sequence number 6861191096
200504 23:10:15 [Note] Plugin ‘FEEDBACK’ is disabled.
200504 23:10:15 [Note] Server socket created on IP: ‘0.0.0.0’.
200504 23:10:15 [Note] Event Scheduler: Loaded 0 events
200504 23:10:15 [Note] /usr/libexec/mysqld: ready for connections.
Version: ‘5.5.60-MariaDB’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 MariaDB Server

How can this problem be solved? Thanks.

The database has to be quiescent when you use SQLBACKUP, and it sounds like your database is still getting written to. There should be a way to not lock the tables when you dump them, but then you risk the data not being synced when you try to reload it.

Also, you probably should run a repairall on the database just to clean up those errors in your logs,

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.