Details

    Description

      Quite often mariadb crashes and immediately rises, while there is no serious load and long queries.
      Some information about system:

      centos-release-7-7.1908.0.el7.centos.x86_64
      

      lscpu
      Architecture:          x86_64
      CPU op-mode(s):        32-bit, 64-bit
      Byte Order:            Little Endian
      CPU(s):                3
      On-line CPU(s) list:   0-2
      Thread(s) per core:    1
      Core(s) per socket:    3
      Socket(s):             1
      NUMA node(s):          1
      Vendor ID:             GenuineIntel
      CPU family:            6
      Model:                 85
      Model name:            Intel(R) Xeon(R) Gold 6248 CPU @ 2.50GHz
      Stepping:              7
      CPU MHz:               2494.140
      BogoMIPS:              4988.28
      Hypervisor vendor:     VMware
      Virtualization type:   full
      L1d cache:             32K
      L1i cache:             32K
      L2 cache:              1024K
      L3 cache:              28160K
      NUMA node0 CPU(s):     0-2
      Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec arat pku ospke md_clear spec_ctrl intel_stibp flush_l1d arch_capabilities
      

      free -m
                    total        used        free      shared  buff/cache   available
      Mem:           7821        5329         198         369        2293        1823
      Swap:          4091        2325        1766
      

      my.cnf

      [mysqld]
      datadir=/u01/mysql
      socket=/u01/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
      #instructions in http://fedoraproject.org/wiki/Systemd
      #
       
      port =  3306
       
      log-error=/var/log/mariadb/mariadb.log
      log-warnings=2
       
      # Replication Configuration
      log_bin = mariadb-bin
       
      server_id = 1
       
      innodb_buffer_pool_size=4G
       
      character_set_server=utf8mb4
      collation_server=utf8mb4_unicode_ci
      innodb_file_format=Barracuda
      innodb_large_prefix=1
      innodb_file_per_table=1
      lower_case_table_names=1
       
      gtid_strict_mode = 1
      gtid_domain_id = 1
      log_slave_updates=1
       
      slow_query_log
      long_query_time=5.0
      slow_query_log_file=/var/log/mariadb/mariadb-slow.log
       
      #
      # This group is read both by the client and the server
      # use it for options that affect everything
      #
       
      [mysqld_safe]
      #log-error=/var/log/mariadb/mariadb.log
      pid-file=/var/run/mariadb/mariadb.pid
       
      [client-server]
      socket=/u01/mysql/mysql.sock
       
      #
      # include *.cnf from the config directory
      #
      !includedir /etc/my.cnf.d
      

      We have cluster with maxscale.
      Log is in the attacment.

      What can you advise to avoid crashes?

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              magzhanova Asel Magzhanova
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.