Database server went down this morning

Feb 19 11:15:02 localhost systemd[1]: Starting LSB: start and stop MariaDB...

Feb 19 11:15:02 localhost mysql[39574]: Starting MariaDB.200219 11:15:02 mysqld_safe Logging to '/var/lib/mysql/localhost.err'.

Feb 19 11:15:02 localhost mysql[39574]: 200219 11:15:02 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

Feb 19 11:15:08 localhost mysql[39574]: ...../etc/rc.d/init.d/mysql: line 264: kill: (39584) - No such process

Feb 19 11:15:08 localhost mysql[39574]: ERROR!

Feb 19 11:15:08 localhost systemd[1]: mysql.service: control process exited, code=exited status=1

Feb 19 11:15:08 localhost systemd[1]: Failed to start LSB: start and stop MariaDB.

Feb 19 11:15:08 localhost systemd[1]: Unit mysql.service entered failed state.

Feb 19 11:15:08 localhost systemd[1]: mysql.service failed.

2020-02-18 09:55:58 7fa34d5f98c0 InnoDB: uncompressed page, stored checksum in field1 801693338, calculated checksums for field1: crc32 199530142, innodb 801693338, none 3735928559, stored checksum in field2 2297860288, calculated checksums for field2: crc32 199530142, innodb 2490704896, none 3735928559, page LSN 23 3481931258, low 4 bytes of LSN at page end 3481922866, page number (if stored to page already) 5, space id (if created with >= MySQL-4.1.1 and stored already) 0

InnoDB: Page may be a transaction system page

InnoDB: Database page corruption on disk or a failed

InnoDB: file read of page 5.

InnoDB: You may have to recover from a backup.

InnoDB: It is also possible that your operating

InnoDB: system has corrupted its own file cache

InnoDB: and rebooting your computer removes the

InnoDB: error.

InnoDB: If the corrupt page is an index page

InnoDB: you can also try to fix the corruption

InnoDB: by dumping, dropping, and reimporting

InnoDB: the corrupt table. You can use CHECK

InnoDB: TABLE to scan your table for corruption.

InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html

InnoDB: about forcing recovery.

InnoDB: Ending processing because of a corrupt database page.

2020-02-18 09:55:58 7fa34d5f98c0  InnoDB: Assertion failure in thread 140339354507456 in file buf0buf.cc line 4511

InnoDB: We intentionally generate a memory trap.

InnoDB: Submit a detailed bug report to https://jira.mariadb.org/

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.6/en/forcing-innodb-recovery.html

InnoDB: about forcing recovery.

200218  9:55: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 https://mariadb.com/kb/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: 10.0.38-MariaDB-wsrep

key_buffer_size=134217728

read_buffer_size=131072

max_used_connections=0

max_threads=153

thread_count=0

It is possible that mysqld could use up to

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467095 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/sbin/mysqld(my_print_stacktrace+0x2e)[0xbf35fe]

/usr/sbin/mysqld(handle_fatal_signal+0x3b6)[0x75f406]

sigaction.c:0(__restore_rt)[0x7ff79b9365f0]

:0(__GI_raise)[0x7ff79a05e337]

:0(__GI_abort)[0x7ff79a05fa28]

/usr/sbin/mysqld[0xae06f2]

/usr/sbin/mysqld[0xaf6af1]

/usr/sbin/mysqld[0xadce4b]

/usr/sbin/mysqld[0xa98858]

/usr/sbin/mysqld[0xa82c4b]

/usr/sbin/mysqld[0x9b45fc]

/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x5e)[0x7613ae]

/usr/sbin/mysqld[0x5f16f6]

/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x494)[0x5f29c4]

/usr/sbin/mysqld[0x5442fc]

/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x90b)[0x548d7b]

/lib64/libc.so.6(__libc_start_main+0xf5)[0x7ff79a04a505]

/usr/sbin/mysqld[0x53bc27]

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.'

200218 10:14:14 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

200218 10:14:14 mysqld_safe WSREP: Running position recovery with --log_error='/var/lib/mysql/wsrep_recovery.ivK3mr' --pid-file='/var/lib/mysql/localhost-recover.pid'

200218 10:14:14 [Note] /usr/sbin/mysqld (mysqld 10.0.38-MariaDB-wsrep) starting as process 48956 ...

200218 10:14:15 mysqld_safe WSREP: Failed to recover position: '200218 10:14:14 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

200218 10:14:14 [Note] InnoDB: Using mutexes to ref count buffer pool pages

200218 10:14:14 [Note] InnoDB: The InnoDB memory heap is disabled

200218 10:14:14 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins

200218 10:14:14 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier

200218 10:14:14 [Note] InnoDB: Compressed tables use zlib 1.2.7

200218 10:14:14 [Note] InnoDB: Using Linux native AIO

200218 10:14:14 [Note] InnoDB: Using CPU crc32 instructions

200218 10:14:14 [Note] InnoDB: Initializing buffer pool, size = 128.0M

200218 10:14:14 [Note] InnoDB: Completed initialization of buffer pool

InnoDB: Database page corruption on disk or a failed

InnoDB: file read of page 5.

InnoDB: You may have to recover from a backup.

2020-02-18 10:14:14 7f018e8508c0 InnoDB: Page dump in ascii and hex (16384 bytes):