Problem na serwerze - Job for mariadb.service failed because

BlackAngel91 · 8 Października 2018

Dzień dobry mam problem na serwerze wszystko śmigało ( ponad rok ) i dziś nagle nie mogę zrestartować bazy danych na centos

Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xe" for details.

Mam jeszcze jedno pytanie gdyby nie udało się tego naprawić wystarczy zrobić kopię tabelek

tar -cvzf mysql-backup-30032017.tar.gz var/lib/mysql

przeinstalować i zadziała?

Proszę o pomoc i z góry dzięki

BlackAngel91 · 8 Października 2018

1 godzinę temu, Nightmare' napisał:

Pokaż błąd z journala a także bezpośrednio error log z mariadb

!!!! Backupu bazy nigdy nie robi się w prezentowany przez Ciebie sposób !!!!


[root@ns334722 ~]# systemctl restart mariadb.service
Job for mariadb.service failed because the control process exited with error cod                                                                           e. See "systemctl status mariadb.service" and "journalctl -xe" for details.
[root@ns334722 ~]# ^C
[root@ns334722 ~]# journalctl -xe
paź 08 16:47:37 ns334722 mysqld_safe[28831]: 181008 16:47:37 mysqld_safe Startin
paź 08 16:47:39 ns334722 systemd[1]: mariadb.service: control process exited, co
paź 08 16:47:39 ns334722 systemd[1]: Failed to start MariaDB database server.
-- Subject: Jednostka mariadb.service się nie powiodła
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Jednostka mariadb.service się nie powiodła.
--
-- Wynik: failed.
paź 08 16:47:39 ns334722 systemd[1]: Unit mariadb.service entered failed state.
paź 08 16:47:39 ns334722 systemd[1]: mariadb.service failed.
paź 08 16:47:42 ns334722 systemd[1]: mariadb.service holdoff time over, scheduli
paź 08 16:47:42 ns334722 systemd[1]: Starting MariaDB database server...
-- Subject: Rozpoczęto uruchamianie jednostki mariadb.service
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Jednostka mariadb.service rozpoczęła uruchamianie.
paź 08 16:47:42 ns334722 mariadb-prepare-db-dir[29197]: Database MariaDB is prob
paź 08 16:47:42 ns334722 mariadb-prepare-db-dir[29197]: If this is not the case,
paź 08 16:47:43 ns334722 mysqld_safe[29228]: 181008 16:47:43 mysqld_safe Logging
paź 08 16:47:43 ns334722 mysqld_safe[29228]: 181008 16:47:43 mysqld_safe Startin
lines 2361-2383/2383 (END)
paź 08 16:47:37 ns334722 mysqld_safe[28831]: 181008 16:47:37 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
paź 08 16:47:39 ns334722 systemd[1]: mariadb.service: control process exited, code=exited status=1
paź 08 16:47:39 ns334722 systemd[1]: Failed to start MariaDB database server.
-- Subject: Jednostka mariadb.service się nie powiodła
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Jednostka mariadb.service się nie powiodła.
--
-- Wynik: failed.
paź 08 16:47:39 ns334722 systemd[1]: Unit mariadb.service entered failed state.
paź 08 16:47:39 ns334722 systemd[1]: mariadb.service failed.
paź 08 16:47:42 ns334722 systemd[1]: mariadb.service holdoff time over, scheduling restart.
paź 08 16:47:42 ns334722 systemd[1]: Starting MariaDB database server...
-- Subject: Rozpoczęto uruchamianie jednostki mariadb.service
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Jednostka mariadb.service rozpoczęła uruchamianie.
paź 08 16:47:42 ns334722 mariadb-prepare-db-dir[29197]: Database MariaDB is probably initialized in /var/lib/mysql already, nothing is done.
paź 08 16:47:42 ns334722 mariadb-prepare-db-dir[29197]: If this is not the case, make sure the /var/lib/mysql is empty before running mariadb-prepare-db-di
paź 08 16:47:43 ns334722 mysqld_safe[29228]: 181008 16:47:43 mysqld_safe Logging to '/var/log/mariadb/mariadb.log'.
paź 08 16:47:43 ns334722 mysqld_safe[29228]: 181008 16:47:43 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
~
~
~
~
~
~
~
~
~
~
lines

a masz może jakiś inny sposób na kopie tych tabelek?

Dzięki za pomoc

8 Października 2018

Dołącz jeszcze error log z samego mariadb bo w journalu nic ciekawego nie ma. Owszem mam inny sposób, jest to wykonywanie backupu przed grzebaniem w bazie. Ewidentnie coś było dotykane, nic samo z siebie nie pada od tak.

BlackAngel91 · 8 Października 2018

Dnia 10/8/2018 o 16:57, Nightmare' napisał:

Dołącz jeszcze error log z samego mariadb bo w journalu nic ciekawego nie ma. Owszem mam inny sposób, jest to wykonywanie backupu przed grzebaniem w bazie. Ewidentnie coś było dotykane, nic samo z siebie nie pada od tak.

[root@ns334722 ~]# systemctl status mariadb.service
● mariadb.service - MariaDB database server
   Loaded: loaded (/etc/systemd/system/mariadb.service; enabled; vendor preset:                                                                                                                                                              disabled)
   Active: activating (start-post) since pon 2018-10-08 16:59:09 CEST; 576ms ago
  Process: 27724 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir %n (code=exite                                                                                                                                                             d, status=0/SUCCESS)
 Main PID: 27755 (mysqld_safe);         : 27756 (mariadb-wait-re)
   CGroup: /system.slice/mariadb.service
           ├─27755 /bin/sh /usr/bin/mysqld_safe --basedir=/usr
           ├─27986 /bin/sh /usr/bin/mysqld_safe --basedir=/usr
           └─control
             ├─27756 /bin/sh /usr/libexec/mariadb-wait-ready 27755
             └─27792 sleep 1

paź 08 16:59:09 ns334722 systemd[1]: Starting MariaDB database server...
paź 08 16:59:09 ns334722 mariadb-prepare-db-dir[27724]: Database MariaDB is ...
paź 08 16:59:10 ns334722 mysqld_safe[27755]: 181008 16:59:10 mysqld_safe Lo....
Hint: Some lines were ellipsized, use -l to show in full.

/var/log/mariadb

Spoiler


Server version: 5.5.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x56153a88c96d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x56153a4a2285]
/lib64/libpthread.so.0(+0xf6d0)[0x7f34294326d0]
/lib64/libc.so.6(gsignal+0x37)[0x7f3427b5c277]
/lib64/libc.so.6(abort+0x148)[0x7f3427b5d968]
/usr/libexec/mysqld(+0x6447bf)[0x56153a6447bf]
/usr/libexec/mysqld(+0x645414)[0x56153a645414]
/usr/libexec/mysqld(+0x747b14)[0x56153a747b14]
/usr/libexec/mysqld(+0x73c847)[0x56153a73c847]
/usr/libexec/mysqld(+0x6475ed)[0x56153a6475ed]
/usr/libexec/mysqld(+0x63b44e)[0x56153a63b44e]
/lib64/libpthread.so.0(+0x7e25)[0x7f342942ae25]
/lib64/libc.so.6(clone+0x6d)[0x7f3427c24bad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:53:42 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:53:46 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:53:46 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 6981 ...
181008 16:53:46 InnoDB: The InnoDB memory heap is disabled
181008 16:53:46 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:53:46 InnoDB: Compressed tables use zlib 1.2.7
181008 16:53:46 InnoDB: Using Linux native AIO
181008 16:53:46 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:53:46 InnoDB: Completed initialization of buffer pool
181008 16:53:46 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...
181008 16:53:47  InnoDB: Waiting for the background threads to start
181008 16:53:47  InnoDB: Assertion failure in thread 140442003703552 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:53:47 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5619ab43996d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5619ab04f285]
/lib64/libpthread.so.0(+0xf6d0)[0x7fbb70c9c6d0]
/lib64/libc.so.6(gsignal+0x37)[0x7fbb6f3c6277]
/lib64/libc.so.6(abort+0x148)[0x7fbb6f3c7968]
/usr/libexec/mysqld(+0x6447bf)[0x5619ab1f17bf]
/usr/libexec/mysqld(+0x645414)[0x5619ab1f2414]
/usr/libexec/mysqld(+0x747b14)[0x5619ab2f4b14]
/usr/libexec/mysqld(+0x73c847)[0x5619ab2e9847]
/usr/libexec/mysqld(+0x6475ed)[0x5619ab1f45ed]
/usr/libexec/mysqld(+0x63b44e)[0x5619ab1e844e]
/lib64/libpthread.so.0(+0x7e25)[0x7fbb70c94e25]
/lib64/libc.so.6(clone+0x6d)[0x7fbb6f48ebad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:53:47 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:53:51 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:53:51 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 7309 ...
181008 16:53:51 InnoDB: The InnoDB memory heap is disabled
181008 16:53:51 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:53:51 InnoDB: Compressed tables use zlib 1.2.7
181008 16:53:51 InnoDB: Using Linux native AIO
181008 16:53:51 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:53:51 InnoDB: Completed initialization of buffer pool
181008 16:53:51 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...
181008 16:53:52  InnoDB: Waiting for the background threads to start
181008 16:53:52  InnoDB: Assertion failure in thread 140075051104000 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:53:52 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55eec8e2d96d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55eec8a43285]
/lib64/libpthread.so.0(+0xf6d0)[0x7f6600bbe6d0]
/lib64/libc.so.6(gsignal+0x37)[0x7f65ff2e8277]
/lib64/libc.so.6(abort+0x148)[0x7f65ff2e9968]
/usr/libexec/mysqld(+0x6447bf)[0x55eec8be57bf]
/usr/libexec/mysqld(+0x645414)[0x55eec8be6414]
/usr/libexec/mysqld(+0x747b14)[0x55eec8ce8b14]
/usr/libexec/mysqld(+0x73c847)[0x55eec8cdd847]
/usr/libexec/mysqld(+0x6475ed)[0x55eec8be85ed]
/usr/libexec/mysqld(+0x63b44e)[0x55eec8bdc44e]
/lib64/libpthread.so.0(+0x7e25)[0x7f6600bb6e25]
/lib64/libc.so.6(clone+0x6d)[0x7f65ff3b0bad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:53:52 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:53:56 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:53:56 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 7646 ...
181008 16:53:56 InnoDB: The InnoDB memory heap is disabled
181008 16:53:56 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:53:56 InnoDB: Compressed tables use zlib 1.2.7
181008 16:53:56 InnoDB: Using Linux native AIO
181008 16:53:56 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:53:56 InnoDB: Completed initialization of buffer pool
181008 16:53:56 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...
181008 16:53:57  InnoDB: Waiting for the background threads to start
181008 16:53:58  InnoDB: Assertion failure in thread 140598880483072 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:53:58 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x56015eab596d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x56015e6cb285]
/lib64/libpthread.so.0(+0xf6d0)[0x7fdff764e6d0]
/lib64/libc.so.6(gsignal+0x37)[0x7fdff5d78277]
/lib64/libc.so.6(abort+0x148)[0x7fdff5d79968]
/usr/libexec/mysqld(+0x6447bf)[0x56015e86d7bf]
/usr/libexec/mysqld(+0x645414)[0x56015e86e414]
/usr/libexec/mysqld(+0x747b14)[0x56015e970b14]
/usr/libexec/mysqld(+0x73c847)[0x56015e965847]
/usr/libexec/mysqld(+0x6475ed)[0x56015e8705ed]
/usr/libexec/mysqld(+0x63b44e)[0x56015e86444e]
/lib64/libpthread.so.0(+0x7e25)[0x7fdff7646e25]
/lib64/libc.so.6(clone+0x6d)[0x7fdff5e40bad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:53:58 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:54:02 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:54:02 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 8094 ...
181008 16:54:02 InnoDB: The InnoDB memory heap is disabled
181008 16:54:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:54:02 InnoDB: Compressed tables use zlib 1.2.7
181008 16:54:02 InnoDB: Using Linux native AIO
181008 16:54:02 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:54:02 InnoDB: Completed initialization of buffer pool
181008 16:54:02 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...
181008 16:54:04  InnoDB: Waiting for the background threads to start
181008 16:54:04  InnoDB: Assertion failure in thread 140671688435456 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:54:04 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5632537b196d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5632533c7285]
/lib64/libpthread.so.0(+0xf6d0)[0x7ff0eb1486d0]
/lib64/libc.so.6(gsignal+0x37)[0x7ff0e9872277]
/lib64/libc.so.6(abort+0x148)[0x7ff0e9873968]
/usr/libexec/mysqld(+0x6447bf)[0x5632535697bf]
/usr/libexec/mysqld(+0x645414)[0x56325356a414]
/usr/libexec/mysqld(+0x747b14)[0x56325366cb14]
/usr/libexec/mysqld(+0x73c847)[0x563253661847]
/usr/libexec/mysqld(+0x6475ed)[0x56325356c5ed]
/usr/libexec/mysqld(+0x63b44e)[0x56325356044e]
/lib64/libpthread.so.0(+0x7e25)[0x7ff0eb140e25]
/lib64/libc.so.6(clone+0x6d)[0x7ff0e993abad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:54:04 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:54:09 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:54:09 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 8445 ...
181008 16:54:09 InnoDB: The InnoDB memory heap is disabled
181008 16:54:09 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:54:09 InnoDB: Compressed tables use zlib 1.2.7
181008 16:54:09 InnoDB: Using Linux native AIO
181008 16:54:09 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:54:09 InnoDB: Completed initialization of buffer pool
181008 16:54:09 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...
181008 16:54:10  InnoDB: Waiting for the background threads to start
181008 16:54:10  InnoDB: Assertion failure in thread 140072134616832 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:54:10 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55e41424a96d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55e413e60285]
/lib64/libpthread.so.0(+0xf6d0)[0x7f6552ed56d0]
/lib64/libc.so.6(gsignal+0x37)[0x7f65515ff277]
/lib64/libc.so.6(abort+0x148)[0x7f6551600968]
/usr/libexec/mysqld(+0x6447bf)[0x55e4140027bf]
/usr/libexec/mysqld(+0x645414)[0x55e414003414]
/usr/libexec/mysqld(+0x747b14)[0x55e414105b14]
/usr/libexec/mysqld(+0x73c847)[0x55e4140fa847]
/usr/libexec/mysqld(+0x6475ed)[0x55e4140055ed]
/usr/libexec/mysqld(+0x63b44e)[0x55e413ff944e]
/lib64/libpthread.so.0(+0x7e25)[0x7f6552ecde25]
/lib64/libc.so.6(clone+0x6d)[0x7f65516c7bad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:54:10 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:54:14 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:54:14 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 8776 ...
181008 16:54:14 InnoDB: The InnoDB memory heap is disabled
181008 16:54:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:54:14 InnoDB: Compressed tables use zlib 1.2.7
181008 16:54:14 InnoDB: Using Linux native AIO
181008 16:54:14 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:54:14 InnoDB: Completed initialization of buffer pool
181008 16:54: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...
181008 16:54:15  InnoDB: Waiting for the background threads to start
181008 16:54:15  InnoDB: Assertion failure in thread 140573591160576 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:54:15 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55d9e156b96d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55d9e1181285]
/lib64/libpthread.so.0(+0xf6d0)[0x7fda1409a6d0]
/lib64/libc.so.6(gsignal+0x37)[0x7fda127c4277]
/lib64/libc.so.6(abort+0x148)[0x7fda127c5968]
/usr/libexec/mysqld(+0x6447bf)[0x55d9e13237bf]
/usr/libexec/mysqld(+0x645414)[0x55d9e1324414]
/usr/libexec/mysqld(+0x747b14)[0x55d9e1426b14]
/usr/libexec/mysqld(+0x73c847)[0x55d9e141b847]
/usr/libexec/mysqld(+0x6475ed)[0x55d9e13265ed]
/usr/libexec/mysqld(+0x63b44e)[0x55d9e131a44e]
/lib64/libpthread.so.0(+0x7e25)[0x7fda14092e25]
/lib64/libc.so.6(clone+0x6d)[0x7fda1288cbad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:54:15 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:54:19 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:54:20 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 9108 ...
181008 16:54:20 InnoDB: The InnoDB memory heap is disabled
181008 16:54:20 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:54:20 InnoDB: Compressed tables use zlib 1.2.7
181008 16:54:20 InnoDB: Using Linux native AIO
181008 16:54:20 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:54:20 InnoDB: Completed initialization of buffer pool
181008 16:54:20 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...
181008 16:54:21  InnoDB: Waiting for the background threads to start
181008 16:54:21  InnoDB: Assertion failure in thread 139784605271808 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:54:21 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55a3032c896d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55a302ede285]
/lib64/libpthread.so.0(+0xf6d0)[0x7f2260d056d0]
/lib64/libc.so.6(gsignal+0x37)[0x7f225f42f277]
/lib64/libc.so.6(abort+0x148)[0x7f225f430968]
/usr/libexec/mysqld(+0x6447bf)[0x55a3030807bf]
/usr/libexec/mysqld(+0x645414)[0x55a303081414]
/usr/libexec/mysqld(+0x747b14)[0x55a303183b14]
/usr/libexec/mysqld(+0x73c847)[0x55a303178847]
/usr/libexec/mysqld(+0x6475ed)[0x55a3030835ed]
/usr/libexec/mysqld(+0x63b44e)[0x55a30307744e]
/lib64/libpthread.so.0(+0x7e25)[0x7f2260cfde25]
/lib64/libc.so.6(clone+0x6d)[0x7f225f4f7bad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:54:21 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:54:25 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:54:25 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 9436 ...
181008 16:54:25 InnoDB: The InnoDB memory heap is disabled
181008 16:54:25 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:54:25 InnoDB: Compressed tables use zlib 1.2.7
181008 16:54:25 InnoDB: Using Linux native AIO
181008 16:54:25 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:54:25 InnoDB: Completed initialization of buffer pool
181008 16:54:25 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...
181008 16:54:26  InnoDB: Waiting for the background threads to start
181008 16:54:26  InnoDB: Assertion failure in thread 140249866852096 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:54:26 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55b2d43b296d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55b2d3fc8285]
/lib64/libpthread.so.0(+0xf6d0)[0x7f8eb49896d0]
/lib64/libc.so.6(gsignal+0x37)[0x7f8eb30b3277]
/lib64/libc.so.6(abort+0x148)[0x7f8eb30b4968]
/usr/libexec/mysqld(+0x6447bf)[0x55b2d416a7bf]
/usr/libexec/mysqld(+0x645414)[0x55b2d416b414]
/usr/libexec/mysqld(+0x747b14)[0x55b2d426db14]
/usr/libexec/mysqld(+0x73c847)[0x55b2d4262847]
/usr/libexec/mysqld(+0x6475ed)[0x55b2d416d5ed]
/usr/libexec/mysqld(+0x63b44e)[0x55b2d416144e]
/lib64/libpthread.so.0(+0x7e25)[0x7f8eb4981e25]
/lib64/libc.so.6(clone+0x6d)[0x7f8eb317bbad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:54:26 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:54:30 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:54:30 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 9766 ...
181008 16:54:30 InnoDB: The InnoDB memory heap is disabled
181008 16:54:30 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:54:30 InnoDB: Compressed tables use zlib 1.2.7
181008 16:54:30 InnoDB: Using Linux native AIO
181008 16:54:30 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:54:30 InnoDB: Completed initialization of buffer pool
181008 16:54:30 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...
181008 16:54:31  InnoDB: Waiting for the background threads to start
181008 16:54:31  InnoDB: Assertion failure in thread 140587859961600 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:54:31 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5636b42a596d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5636b3ebb285]
/lib64/libpthread.so.0(+0xf6d0)[0x7fdd668d16d0]
/lib64/libc.so.6(gsignal+0x37)[0x7fdd64ffb277]
/lib64/libc.so.6(abort+0x148)[0x7fdd64ffc968]
/usr/libexec/mysqld(+0x6447bf)[0x5636b405d7bf]
/usr/libexec/mysqld(+0x645414)[0x5636b405e414]
/usr/libexec/mysqld(+0x747b14)[0x5636b4160b14]
/usr/libexec/mysqld(+0x73c847)[0x5636b4155847]
/usr/libexec/mysqld(+0x6475ed)[0x5636b40605ed]
/usr/libexec/mysqld(+0x63b44e)[0x5636b405444e]
/lib64/libpthread.so.0(+0x7e25)[0x7fdd668c9e25]
/lib64/libc.so.6(clone+0x6d)[0x7fdd650c3bad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:54:31 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:54:35 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:54:35 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 10095 ...
181008 16:54:35 InnoDB: The InnoDB memory heap is disabled
181008 16:54:35 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:54:35 InnoDB: Compressed tables use zlib 1.2.7
181008 16:54:35 InnoDB: Using Linux native AIO
181008 16:54:35 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:54:35 InnoDB: Completed initialization of buffer pool
181008 16:54:35 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...
181008 16:54:36  InnoDB: Waiting for the background threads to start
181008 16:54:36  InnoDB: Assertion failure in thread 140204107568896 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:54:36 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55a67c15a96d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55a67bd70285]
/lib64/libpthread.so.0(+0xf6d0)[0x7f840d12c6d0]
/lib64/libc.so.6(gsignal+0x37)[0x7f840b856277]
/lib64/libc.so.6(abort+0x148)[0x7f840b857968]
/usr/libexec/mysqld(+0x6447bf)[0x55a67bf127bf]
/usr/libexec/mysqld(+0x645414)[0x55a67bf13414]
/usr/libexec/mysqld(+0x747b14)[0x55a67c015b14]
/usr/libexec/mysqld(+0x73c847)[0x55a67c00a847]
/usr/libexec/mysqld(+0x6475ed)[0x55a67bf155ed]
/usr/libexec/mysqld(+0x63b44e)[0x55a67bf0944e]
/lib64/libpthread.so.0(+0x7e25)[0x7f840d124e25]
/lib64/libc.so.6(clone+0x6d)[0x7f840b91ebad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:54:37 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:54:40 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:54:41 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 10426 ...
181008 16:54:41 InnoDB: The InnoDB memory heap is disabled
181008 16:54:41 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:54:41 InnoDB: Compressed tables use zlib 1.2.7
181008 16:54:41 InnoDB: Using Linux native AIO
181008 16:54:41 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:54:41 InnoDB: Completed initialization of buffer pool
181008 16:54:41 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...
181008 16:54:42  InnoDB: Waiting for the background threads to start
181008 16:54:42  InnoDB: Assertion failure in thread 139837096965888 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:54:42 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x56086635896d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x560865f6e285]
/lib64/libpthread.so.0(+0xf6d0)[0x7f2e9987b6d0]
/lib64/libc.so.6(gsignal+0x37)[0x7f2e97fa5277]
/lib64/libc.so.6(abort+0x148)[0x7f2e97fa6968]
/usr/libexec/mysqld(+0x6447bf)[0x5608661107bf]
/usr/libexec/mysqld(+0x645414)[0x560866111414]
/usr/libexec/mysqld(+0x747b14)[0x560866213b14]
/usr/libexec/mysqld(+0x73c847)[0x560866208847]
/usr/libexec/mysqld(+0x6475ed)[0x5608661135ed]
/usr/libexec/mysqld(+0x63b44e)[0x56086610744e]
/lib64/libpthread.so.0(+0x7e25)[0x7f2e99873e25]
/lib64/libc.so.6(clone+0x6d)[0x7f2e9806dbad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:54:42 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:54:46 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:54:46 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 10759 ...
181008 16:54:46 InnoDB: The InnoDB memory heap is disabled
181008 16:54:46 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:54:46 InnoDB: Compressed tables use zlib 1.2.7
181008 16:54:46 InnoDB: Using Linux native AIO
181008 16:54:46 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:54:46 InnoDB: Completed initialization of buffer pool
181008 16:54:46 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...
181008 16:54:47  InnoDB: Waiting for the background threads to start
181008 16:54:47  InnoDB: Assertion failure in thread 140622196905728 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:54:47 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x558f7e6d296d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x558f7e2e8285]
/lib64/libpthread.so.0(+0xf6d0)[0x7fe5652a26d0]
/lib64/libc.so.6(gsignal+0x37)[0x7fe5639cc277]
/lib64/libc.so.6(abort+0x148)[0x7fe5639cd968]
/usr/libexec/mysqld(+0x6447bf)[0x558f7e48a7bf]
/usr/libexec/mysqld(+0x645414)[0x558f7e48b414]
/usr/libexec/mysqld(+0x747b14)[0x558f7e58db14]
/usr/libexec/mysqld(+0x73c847)[0x558f7e582847]
/usr/libexec/mysqld(+0x6475ed)[0x558f7e48d5ed]
/usr/libexec/mysqld(+0x63b44e)[0x558f7e48144e]
/lib64/libpthread.so.0(+0x7e25)[0x7fe56529ae25]
/lib64/libc.so.6(clone+0x6d)[0x7fe563a94bad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:54:47 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:54:51 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:54:51 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 11091 ...
181008 16:54:51 InnoDB: The InnoDB memory heap is disabled
181008 16:54:51 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:54:51 InnoDB: Compressed tables use zlib 1.2.7
181008 16:54:51 InnoDB: Using Linux native AIO
181008 16:54:51 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:54:51 InnoDB: Completed initialization of buffer pool
181008 16:54:51 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...
181008 16:54:52  InnoDB: Waiting for the background threads to start
181008 16:54:52  InnoDB: Assertion failure in thread 140001897481984 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:54:52 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x556c523b496d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x556c51fca285]
/lib64/libpthread.so.0(+0xf6d0)[0x7f54f86ab6d0]
/lib64/libc.so.6(gsignal+0x37)[0x7f54f6dd5277]
/lib64/libc.so.6(abort+0x148)[0x7f54f6dd6968]
/usr/libexec/mysqld(+0x6447bf)[0x556c5216c7bf]
/usr/libexec/mysqld(+0x645414)[0x556c5216d414]
/usr/libexec/mysqld(+0x747b14)[0x556c5226fb14]
/usr/libexec/mysqld(+0x73c847)[0x556c52264847]
/usr/libexec/mysqld(+0x6475ed)[0x556c5216f5ed]
/usr/libexec/mysqld(+0x63b44e)[0x556c5216344e]
/lib64/libpthread.so.0(+0x7e25)[0x7f54f86a3e25]
/lib64/libc.so.6(clone+0x6d)[0x7f54f6e9dbad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:54:52 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:54:56 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:54:56 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 11419 ...
181008 16:54:56 InnoDB: The InnoDB memory heap is disabled
181008 16:54:56 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:54:56 InnoDB: Compressed tables use zlib 1.2.7
181008 16:54:56 InnoDB: Using Linux native AIO
181008 16:54:56 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:54:56 InnoDB: Completed initialization of buffer pool
181008 16:54:56 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...
181008 16:54:57  InnoDB: Waiting for the background threads to start
181008 16:54:57  InnoDB: Assertion failure in thread 140108790949632 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:54:57 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x555d8ff5796d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x555d8fb6d285]
/lib64/libpthread.so.0(+0xf6d0)[0x7f6ddbc426d0]
/lib64/libc.so.6(gsignal+0x37)[0x7f6dda36c277]
/lib64/libc.so.6(abort+0x148)[0x7f6dda36d968]
/usr/libexec/mysqld(+0x6447bf)[0x555d8fd0f7bf]
/usr/libexec/mysqld(+0x645414)[0x555d8fd10414]
/usr/libexec/mysqld(+0x747b14)[0x555d8fe12b14]
/usr/libexec/mysqld(+0x73c847)[0x555d8fe07847]
/usr/libexec/mysqld(+0x6475ed)[0x555d8fd125ed]
/usr/libexec/mysqld(+0x63b44e)[0x555d8fd0644e]
/lib64/libpthread.so.0(+0x7e25)[0x7f6ddbc3ae25]
/lib64/libc.so.6(clone+0x6d)[0x7f6dda434bad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:54:57 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:55:02 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:55:02 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 11865 ...
181008 16:55:02 InnoDB: The InnoDB memory heap is disabled
181008 16:55:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:55:02 InnoDB: Compressed tables use zlib 1.2.7
181008 16:55:02 InnoDB: Using Linux native AIO
181008 16:55:02 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:55:02 InnoDB: Completed initialization of buffer pool
181008 16:55:02 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...
181008 16:55:05  InnoDB: Waiting for the background threads to start
181008 16:55:05  InnoDB: Assertion failure in thread 139985167820544 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:55:05 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x561a2354496d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x561a2315a285]
/lib64/libpthread.so.0(+0xf6d0)[0x7f51134346d0]
/lib64/libc.so.6(gsignal+0x37)[0x7f5111b5e277]
/lib64/libc.so.6(abort+0x148)[0x7f5111b5f968]
/usr/libexec/mysqld(+0x6447bf)[0x561a232fc7bf]
/usr/libexec/mysqld(+0x645414)[0x561a232fd414]
/usr/libexec/mysqld(+0x747b14)[0x561a233ffb14]
/usr/libexec/mysqld(+0x73c847)[0x561a233f4847]
/usr/libexec/mysqld(+0x6475ed)[0x561a232ff5ed]
/usr/libexec/mysqld(+0x63b44e)[0x561a232f344e]
/lib64/libpthread.so.0(+0x7e25)[0x7f511342ce25]
/lib64/libc.so.6(clone+0x6d)[0x7f5111c26bad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:55:05 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:55:09 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:55:09 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 12258 ...
181008 16:55:09 InnoDB: The InnoDB memory heap is disabled
181008 16:55:09 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:55:09 InnoDB: Compressed tables use zlib 1.2.7
181008 16:55:09 InnoDB: Using Linux native AIO
181008 16:55:09 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:55:09 InnoDB: Completed initialization of buffer pool
181008 16:55:09 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...
181008 16:55:10  InnoDB: Waiting for the background threads to start
181008 16:55:10  InnoDB: Assertion failure in thread 139871022913280 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:55:10 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5574203bd96d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55741ffd3285]
/lib64/libpthread.so.0(+0xf6d0)[0x7f367fb706d0]
/lib64/libc.so.6(gsignal+0x37)[0x7f367e29a277]
/lib64/libc.so.6(abort+0x148)[0x7f367e29b968]
/usr/libexec/mysqld(+0x6447bf)[0x5574201757bf]
/usr/libexec/mysqld(+0x645414)[0x557420176414]
/usr/libexec/mysqld(+0x747b14)[0x557420278b14]
/usr/libexec/mysqld(+0x73c847)[0x55742026d847]
/usr/libexec/mysqld(+0x6475ed)[0x5574201785ed]
/usr/libexec/mysqld(+0x63b44e)[0x55742016c44e]
/lib64/libpthread.so.0(+0x7e25)[0x7f367fb68e25]
/lib64/libc.so.6(clone+0x6d)[0x7f367e362bad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:55:10 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:55:14 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:55:14 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 12586 ...
181008 16:55:14 InnoDB: The InnoDB memory heap is disabled
181008 16:55:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:55:14 InnoDB: Compressed tables use zlib 1.2.7
181008 16:55:14 InnoDB: Using Linux native AIO
181008 16:55:14 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:55:14 InnoDB: Completed initialization of buffer pool
181008 16:55: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...
181008 16:55:15  InnoDB: Waiting for the background threads to start
181008 16:55:15  InnoDB: Assertion failure in thread 140421283149568 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:55:15 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55c01749596d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55c0170ab285]
/lib64/libpthread.so.0(+0xf6d0)[0x7fb69dbdf6d0]
/lib64/libc.so.6(gsignal+0x37)[0x7fb69c309277]
/lib64/libc.so.6(abort+0x148)[0x7fb69c30a968]
/usr/libexec/mysqld(+0x6447bf)[0x55c01724d7bf]
/usr/libexec/mysqld(+0x645414)[0x55c01724e414]
/usr/libexec/mysqld(+0x747b14)[0x55c017350b14]
/usr/libexec/mysqld(+0x73c847)[0x55c017345847]
/usr/libexec/mysqld(+0x6475ed)[0x55c0172505ed]
/usr/libexec/mysqld(+0x63b44e)[0x55c01724444e]
/lib64/libpthread.so.0(+0x7e25)[0x7fb69dbd7e25]
/lib64/libc.so.6(clone+0x6d)[0x7fb69c3d1bad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:55:15 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:55:20 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:55:20 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 12923 ...
181008 16:55:20 InnoDB: The InnoDB memory heap is disabled
181008 16:55:20 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:55:20 InnoDB: Compressed tables use zlib 1.2.7
181008 16:55:20 InnoDB: Using Linux native AIO
181008 16:55:20 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:55:20 InnoDB: Completed initialization of buffer pool
181008 16:55:20 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...
181008 16:55:21  InnoDB: Waiting for the background threads to start
181008 16:55:21  InnoDB: Assertion failure in thread 140500941149952 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:55:21 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55cbb2a0496d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x55cbb261a285]
/lib64/libpthread.so.0(+0xf6d0)[0x7fc929ba76d0]
/lib64/libc.so.6(gsignal+0x37)[0x7fc9282d1277]
/lib64/libc.so.6(abort+0x148)[0x7fc9282d2968]
/usr/libexec/mysqld(+0x6447bf)[0x55cbb27bc7bf]
/usr/libexec/mysqld(+0x645414)[0x55cbb27bd414]
/usr/libexec/mysqld(+0x747b14)[0x55cbb28bfb14]
/usr/libexec/mysqld(+0x73c847)[0x55cbb28b4847]
/usr/libexec/mysqld(+0x6475ed)[0x55cbb27bf5ed]
/usr/libexec/mysqld(+0x63b44e)[0x55cbb27b344e]
/lib64/libpthread.so.0(+0x7e25)[0x7fc929b9fe25]
/lib64/libc.so.6(clone+0x6d)[0x7fc928399bad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:55:21 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:55:25 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:55:25 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 13254 ...
181008 16:55:25 InnoDB: The InnoDB memory heap is disabled
181008 16:55:25 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:55:25 InnoDB: Compressed tables use zlib 1.2.7
181008 16:55:25 InnoDB: Using Linux native AIO
181008 16:55:25 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:55:25 InnoDB: Completed initialization of buffer pool
181008 16:55:25 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...
181008 16:55:26  InnoDB: Waiting for the background threads to start
181008 16:55:26  InnoDB: Assertion failure in thread 139823970834176 in file trx0purge.c line 848
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181008 16:55:26 [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.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

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.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=92
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 332887 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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x558da2d2596d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x558da293b285]
/lib64/libpthread.so.0(+0xf6d0)[0x7f2b8b2216d0]
/lib64/libc.so.6(gsignal+0x37)[0x7f2b8994b277]
/lib64/libc.so.6(abort+0x148)[0x7f2b8994c968]
/usr/libexec/mysqld(+0x6447bf)[0x558da2add7bf]
/usr/libexec/mysqld(+0x645414)[0x558da2ade414]
/usr/libexec/mysqld(+0x747b14)[0x558da2be0b14]
/usr/libexec/mysqld(+0x73c847)[0x558da2bd5847]
/usr/libexec/mysqld(+0x6475ed)[0x558da2ae05ed]
/usr/libexec/mysqld(+0x63b44e)[0x558da2ad444e]
/lib64/libpthread.so.0(+0x7e25)[0x7f2b8b219e25]
/lib64/libc.so.6(clone+0x6d)[0x7f2b89a13bad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181008 16:55:26 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
181008 16:55:30 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
181008 16:55:30 [Note] /usr/libexec/mysqld (mysqld 5.5.56-MariaDB) starting as process 13615 ...
181008 16:55:30 InnoDB: The InnoDB memory heap is disabled
181008 16:55:30 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181008 16:55:30 InnoDB: Compressed tables use zlib 1.2.7
181008 16:55:30 InnoDB: Using Linux native AIO
181008 16:55:30 InnoDB: Initializing buffer pool, size = 512.0M
181008 16:55:30 InnoDB: Completed initialization of buffer pool
181008 16:55:30 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...

Właśnie nie było nic grzebane ;/ strona działała od roku na wordpress niekiedy padała baza wystarczyło że ją zrestartowałem i działało. Ostatnio też wyskoczył mi ten błąd, zrestartowałem serwer i baza się odpaliła śmigało z miesiąc. Teraz restart serwera nie pomaga i baza już się nie włącza

8 Października 2018

Wordpress był aktualizowany w tym czasie? Zrób tak:

Wyłacz całkowicie mariadb i zrób backup ibów:

/var/lib/mysql/ib*

do my.cnf dodaj:

innodb_force_recovery = 1

Zrestartuj mariadb i zdumpuj wszystkie tabele do pliku .sql, następnie zdropuj wszystkie tabele które są uszkodzone, wyłącz mariadb i wykonaj:

/var/lib/mysql/ib*

Następnie usuń linijkę z my.cnf którą dodałeś wcześniej i zrestertuj mysqla, jeśli pojawi się błąd wklej mi go tutaj, jeśli nie zaimportuj wszystkie tabele z powrotem do bazy.

BlackAngel91 · 8 Października 2018

1 minutę temu, Nightmare' napisał:
Wordpress był aktualizowany w tym czasie? Zrób tak:

Wyłacz całkowicie mariadb i zrób backup libów:
/var/lib/mysql/ib*
do my.cnf dodaj:
innodb_force_recovery = 1
Zrestartuj mariadb i zdumpuj wszystkie tabele do pliku .sql, następnie zdropuj wszystkie tabele które są uszkodzone, wyłącz mariadb i wykonaj:
/var/lib/mysql/ib*
Następnie usuń linijkę z my.cnf którą dodałeś wcześniej i zrestertuj mysqla, jeśli pojawi się błąd wklej mi go tutaj, jeśli nie zaimportuj wszystkie tabele z powrotem do bazy.

backup zrobić komendą

tar -cvzf mysql-backup-30032017.tar.gz var/lib/mysql

tak ?

8 Października 2018

Tak

BlackAngel91 · 8 Października 2018

3 godziny temu, Nightmare' napisał:

Tak

Kupiłem vps za 5zl żeby spróbować przenieść te tabelki na nowo zainstalowaną marie db tym sposobem

tar -cvzf mysql-backup-30032017.tar.gz var/lib/mysql

potem

tar -cvzf mysql-backup-30032017.tar.gz var/lib/mysql'

 chown -R mysql:mysql /var/lib/mysql/

i tabelki nie działają ;/ " Tabele doesn't exist

8 Października 2018

Mój drogi, tabele miałeś wyexportować do .sql a nie tworzyć backup w takiej formie. W tej formie miałeś spakować jedynie liby przed dalszą częścią pracy. Zmarnowałeś 3h i nie zrobiłeś niczego, też delikatnie wprowadziłem Cie w błąd z tego względu że odpisałem Ci "tak" a nie doczytałem że chcesz w ten sposób zrobić backup całej bazy a nie ibów.

BlackAngel91 · 8 Października 2018

3 minuty temu, Nightmare' napisał:

Mój drogi, tabele miałeś wyexportować do .sql a nie tworzyć backup w takiej formie. W tej formie miałeś spakować jedynie liby przed dalszą częścią pracy. Zmarnowałeś 3h i nie zrobiłeś niczego, też delikatnie wprowadziłem Cie w błąd z tego względu że odpisałem Ci "tak" a nie doczytałem że chcesz w ten sposób zrobić backup całej bazy a nie ibów.

Da się jakoś naprawić lub przenieść te tabele ? wyexportować do .sql nie mogę bo bazy nie da się włączyć.

8 Października 2018

Ehh, chłopie ty w ogóle czytasz co ja Ci napisałem wyżej? Zrobiłeś cokolwiek z tego co tam wypisałem?

BlackAngel91 · 8 Października 2018

2 minuty temu, Nightmare' napisał:

Ehh, chłopie ty w ogóle czytasz co ja Ci napisałem wyżej? Zrobiłeś cokolwiek z tego co tam wypisałem?

Tak gdy dodałem

innodb_force_recovery = 1

do my.cnf bazy dalej nie udało się włączyć ten sam błąd

folderu

/var/lib/mysql/ib*

nie ma jest tylko

/var/lib/mysql/ i tutaj tabele

8 Października 2018

ib to nie folder a pliki. Miałeś je zbackupować i dopiero po backupie dodać tą linijkę do my.cnf a następnie usunąć te pliki i odpalić mariadb.

BlackAngel91 · 8 Października 2018

12 minut temu, Nightmare' napisał:

ib to nie folder a pliki. Miałeś je zbackupować i dopiero po backupie dodać tą linijkę do my.cnf a następnie usunąć te pliki i odpalić mariadb.

baza się włączyła ale tabelki nie działają ;/ Tabele doesn't exist tutaj nie wgrywałem backupa tą komendą tar -xzf backup-30032017.tar.gz na tym serwerze tylko zgrywałem

tar -cvzf mysql-backup-30032017.tar.gz var/lib/mysql

mogłem tym uszkodzić ?

8 Października 2018

Teraz możesz zdumpować .sql tabel oraz użyć narzędzie naprawczych.

BlackAngel91 · 8 Października 2018

Przed chwilą, Nightmare' napisał:

Teraz możesz zdumpować .sql tabel oraz użyć narzędzie naprawczych.

Gdy wpisuje

mysqldump -u user-p wp3 > wp3.sql

Enter password:
mysqldump: Got error: 1146: "Table 'wp3.wp_aiowps_events' doesn't exist" when using LOCK TABLES

;/ ( jak się uda stawiam czteropak )

8 Października 2018

Czteropak mówisz? Daj mi 20 minut dosmażę tylko pancakes i możesz wbić na discorda. Czteropak jest mój

BlackAngel91 · 8 Października 2018

1 minutę temu, Nightmare' napisał:

Czteropak mówisz? Daj mi 20 minut dosmażę tylko pancakes i możesz wbić na discorda. Czteropak jest mój

ok Najbardziej chodzi mi żeby odzyskać tabelki lub ta kopia żeby zadziałała na tym 2 vps, jak się uda wysyłam na piwko paypalem i będę w ch*j wdzięczny

8 Października 2018

Zapraszam na discorda mpcforum, tam szybciej pomogę

BlackAngel91 · 8 Października 2018

2 minuty temu, Nightmare' napisał:

Zapraszam na discorda mpcforum, tam szybciej pomogę

Podasz mi nick na discord bo nie moge znalesc kanalu mpcforum

Problem rozwiązany dzięki @Nightmare' za pomoc Można zamknąć

8 Października 2018

Pokaż błąd z journala a także bezpośrednio error log z mariadb

!!!! Backupu bazy nigdy nie robi się w prezentowany przez Ciebie sposób !!!!

Zaloguj się

👋 Witaj na MPCForum!

Problem na serwerze - Job for mariadb.service failed because

Pytanie

20 odpowiedzi na to pytanie

Rekomendowane odpowiedzi

Gość

Gość

Gość

Gość

Gość

Gość

Gość

Gość

Gość

Gość

Gość

Gość

Gość

Gość

Gość

Gość

Gość

Gość

Gość

Gość

Zarchiwizowany