CyberHosting

Database server is down

I have a problem the Database server is down. Free disk space is half the disk. I can not restart it from SSH. Please help me!

Comments

  • service mysql status
    ERROR! MariaDB is not running, but lock file (/var/lock/subsys/mysql) exists
  • systemctl status mysql.service

    ● mysql.service - LSB: start and stop MariaDB
    Loaded: loaded (/etc/rc.d/init.d/mysql; bad; vendor preset: disabled)
    Active: failed (Result: exit-code) since Tue 2020-02-18 10:50:55 UTC; 8s ago
    Docs: man:systemd-sysv-generator(8)
    Process: 15616 ExecStart=/etc/rc.d/init.d/mysql start (code=exited, status=1/FAILURE)

    Feb 18 10:50:53 localhost systemd[1]: Starting LSB: start and stop MariaDB...
    Feb 18 10:50:54 localhost mysql[15616]: Starting MariaDB.200218 10:50:54 mysqld_safe Logging to '/var/lib/mysql/localhost.err'.
    Feb 18 10:50:54 localhost mysql[15616]: 200218 10:50:54 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
    Feb 18 10:50:55 localhost mysql[15616]: /etc/rc.d/init.d/mysql: line 262: kill: (15621) - No such process
    Feb 18 10:50:55 localhost mysql[15616]: ERROR!
    Feb 18 10:50:55 localhost systemd[1]: mysql.service: control process exited, code=exited status=1
    Feb 18 10:50:55 localhost systemd[1]: Failed to start LSB: start and stop MariaDB.
    Feb 18 10:50:55 localhost systemd[1]: Unit mysql.service entered failed state.
    Feb 18 10:50:55 localhost systemd[1]: mysql.service failed.
  • Try this to get more a more detailed log output: https://www.linode.com/community/questions/18444/unable-to-start-mysql-no-such-process
  • edited February 18
    # service mysql start
    Starting MariaDB.200218 13:55:05 mysqld_safe Logging to '/var/lib/mysql/localhost.err'.
    200218 13:55:05 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
    /etc/init.d/mysql: line 262: kill: (24625) - No such process
    ERROR!


    in phpmyadmin
    mysqli::real_connect(): (HY000/2002): Connection refused

    Server Error Log in OLS
    [PlainConf] [httpServerConfig:] Not support [adminroot $SERVER_ROOT/admin/] in file /usr/local/lsws/conf/httpd_config.conf:16
  • edited February 18
    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):
  • Check your disk space
    Cyberpanel Managed & Unmanaged Shared & VPS Hosting by Cyberpanel Experts.

    https://www.cyberhosting.org
  • df
    Filesystem 1K-blocks Used Available Use% Mounted on
    devtmpfs 3983228 0 3983228 0% /dev
    tmpfs 3995008 152 3994856 1% /dev/shm
    tmpfs 3995008 86380 3908628 3% /run
    tmpfs 3995008 0 3995008 0% /sys/fs/cgroup
    /dev/mapper/centos-root 80726016 36750152 43975864 46% /
    /dev/loop0 1479088 57504 1328400 5% /tmp
    /dev/sda1 1038336 362968 675368 35% /boot
    tmpfs 799004 0 799004 0% /run/user/0


    See for yourself, it seems ok
  • Also
    systemctl start pdns.service
    Is not starting anymore either
Sign In or Register to comment.
CyberPanel Discord

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!