1

After moving to a new hosting company a few months I have experiences these database errors a handful of times on different servers with different software installed. (all Ubuntu 16 or 18).

Latest on

  • Ubuntu 18 VPS with 2 GB RAM,
  • mysql Ver 14.14 Distrib 5.7.25, for Linux (x86_64) using EditLine wrapper
  • Matomo Web Analytics installed

I am really in doubt where to focus my troubleshooting - could it be hardware related, or is it rather a memory (RAM) issue? Or something entirely different?

    2019-03-25T09:08:26.753621Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
    2019-03-25T09:08:26.755941Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.25-0ubuntu0.18.04.2) starting as process 1794 ...
    2019-03-25T09:08:26.791114Z 0 [Warning] InnoDB: Using innodb_file_format is deprecated and the parameter may be removed in future releases. See http://dev.mysql.com/doc/refman/5.7/en/innodb-file-format.html
    2019-03-25T09:08:26.791231Z 0 [Note] InnoDB: PUNCH HOLE support available
    2019-03-25T09:08:26.791246Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
    2019-03-25T09:08:26.791251Z 0 [Note] InnoDB: Uses event mutexes
    2019-03-25T09:08:26.791256Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
    2019-03-25T09:08:26.791260Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
    2019-03-25T09:08:26.791265Z 0 [Note] InnoDB: Using Linux native AIO
    2019-03-25T09:08:26.791554Z 0 [Note] InnoDB: Number of pools: 1
    2019-03-25T09:08:26.791675Z 0 [Note] InnoDB: Using CPU crc32 instructions
    2019-03-25T09:08:26.795347Z 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
    2019-03-25T09:08:26.825458Z 0 [Note] InnoDB: Completed initialization of buffer pool
    2019-03-25T09:08:26.832175Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
    2019-03-25T09:08:26.846085Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
    2019-03-25T09:08:26.850648Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 2468824471
    2019-03-25T09:08:26.850696Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 2468825056
    2019-03-25T09:08:26.851041Z 0 [Note] InnoDB: Database was not shutdown normally!
    2019-03-25T09:08:26.851069Z 0 [Note] InnoDB: Starting crash recovery.
    2019-03-25T09:08:26.868271Z 0 [Note] InnoDB: Starting an apply batch of log records to the database...
    InnoDB: Progress in percent: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
    2019-03-25T09:08:26.881909Z 0 [Note] InnoDB: Apply batch completed
    2019-03-25T09:08:26.998977Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
    2019-03-25T09:08:26.999021Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
    2019-03-25T09:08:26.999125Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
    2019-03-25T09:08:27.057786Z 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
    2019-03-25T09:08:27.059771Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
    2019-03-25T09:08:27.059811Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
    2019-03-25T09:08:27.060383Z 0 [Note] InnoDB: Waiting for purge to start
    2019-03-25 10:08:27 0x7fda56ffd700  InnoDB: Assertion failure in thread 140575739205376 in file btr0cur.cc line 350
    InnoDB: Failing assertion: page_is_comp(get_block->frame) == page_is_comp(page)
    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.7/en/forcing-innodb-recovery.html
    InnoDB: about forcing recovery.
    09:08:27 UTC - 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.
    Attempting to collect some information that could help diagnose the problem.
    As this is a crash and something is definitely wrong, the information
    collection process might fail.

    key_buffer_size=268435456
    read_buffer_size=1048576
    max_used_connections=0
    max_threads=151
    thread_count=0
    connection_count=0
    It is possible that mysqld could use up to 
    key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 573412 K  bytes of memory
    Hope that's ok; if not, decrease some variables in the equation.

    Thread pointer: 0x7fda48000b20
    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 = 7fda56ffcdf0 thread_stack 0x40000
    /usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xebeb7b]
    /usr/sbin/mysqld(handle_fatal_signal+0x48b)[0x790f8b]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7fdaa1b3c890]
    /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7fdaa0e38e97]
    /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7fdaa0e3a801]
    /usr/sbin/mysqld[0x767714]
    /usr/sbin/mysqld(_Z20btr_cur_latch_leavesP11buf_block_tRK9page_id_tRK11page_size_tmP9btr_cur_tP5mtr_t+0x718)[0x10accf8]
    /usr/sbin/mysqld(_Z27btr_cur_search_to_nth_levelP12dict_index_tmPK8dtuple_t15page_cur_mode_tmP9btr_cur_tmPKcmP5mtr_t+0x17ad)[0x10b3b4d]
    /usr/sbin/mysqld(_Z22row_search_index_entryP12dict_index_tPK8dtuple_tmP10btr_pcur_tP5mtr_t+0x10e)[0xffe83e]
    /usr/sbin/mysqld[0xffa06d]
    /usr/sbin/mysqld[0xffba0a]
    /usr/sbin/mysqld(_Z14row_purge_stepP9que_thr_t+0xa43)[0xffc623]
    /usr/sbin/mysqld(_Z15que_run_threadsP9que_thr_t+0xb95)[0xfabd15]
    /usr/sbin/mysqld(srv_worker_thread+0x4b8)[0x102fd18]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0x76db)[0x7fdaa1b316db]
    /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fdaa0f1b88f]

    Trying to get some variables.
    Some pointers may be invalid and cause the dump to abort.
    Query (0): is an invalid pointer
    Connection ID (thread ID): 0
    Status: NOT_KILLED

my.cnf

[client]
#password = your_password
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld]
port = 3306
bind-address = 0.0.0.0
datadir = /var/lib/mysql
socket = /var/run/mysqld/mysqld.sock
pid-file = /var/run/mysqld/mysqld.pid

# Logging configuration.
log-error = /var/log/mysql/mysql.err



# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links = 0

# User is ignored when systemd is used (fedora >= 15).
user = mysql

# http://dev.mysql.com/doc/refman/5.5/en/performance-schema.html
;performance_schema

# Memory settings.
key_buffer_size = 256M
max_allowed_packet = 64M
table_open_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_type = 0
query_cache_size = 16M
query_cache_limit = 1M
max_connections = 151
tmp_table_size = 16M
max_heap_table_size = 16M
group_concat_max_len = 1024
join_buffer_size = 262144

# Other settings.
wait_timeout = 28800
lower_case_table_names = 0
event_scheduler = OFF

# InnoDB settings.
innodb_large_prefix = 1
innodb_file_format = barracuda
innodb_file_per_table = 1
innodb_buffer_pool_size = 256M
innodb_log_file_size = 64M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

[mysqldump]
quick
max_allowed_packet = 64M

[mysqld_safe]
pid-file = /var/run/mysqld/mysqld.pid
0

Suggestions to consider for your my.cnf [mysqld] section,

key_buffer_size=24M  # from 256M to conserve your 2G of RAM
query_cache_size=0  # because you have query_cache_type=0 for OFF to conserve RAM
read_buffer_size=256K  # from 1M for this per connection RAM request
read_rnd_buffer_size=256K  # from 4M for this per connection RAM request
thread_cache_size=32  # from 8 to avoid being 'thread' starved
innodb_buffer_pool_size=512M  # from 256M for 25% of RAM available

For additional suggestions, see my profile, Network profile.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.