I have a problem: I can't do anything in a database.
It will return the following directly to me when any action is currently performed, But this error seems to be only targeted at one of my databases:
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 8
Current database: gomeet
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/home/mysql/software/mysql.sock' (111)
ERROR:
Can't connect to the server
It seems that I send any instruction in the gomeet database and dataserver.err will return me a similar error:
InnoDB: Error: trying to access page number 0 in space 3090,
InnoDB: space name gomeet/api_worker_face_back,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10.
InnoDB: If you get this error at mysqld startup, please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MySQL server.
2021-05-18 17:04:07 7f0fe3206700 InnoDB: Assertion failure in thread 139706211788544 in file fil0fil.cc line 5603
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.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
09:04:07 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.
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.
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=40
max_threads=1500
thread_count=40
connection_count=40
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 604688 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x177301d0
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 = 7f0fe3205ea0 thread_stack 0x40000
/home/mysql/software/bin/mysqld(my_print_stacktrace+0x2c)[0x8f016c]
/home/mysql/software/bin/mysqld(handle_fatal_signal+0x364)[0x66cb64]
/lib64/libpthread.so.0(+0xf5f0)[0x7f13417d25f0]
/lib64/libc.so.6(gsignal+0x37)[0x7f13407d1337]
/lib64/libc.so.6(abort+0x148)[0x7f13407d2a28]
/home/mysql/software/bin/mysqld[0xaa1074]
/home/mysql/software/bin/mysqld[0xa6d899]
/home/mysql/software/bin/mysqld[0xa565b1]
/home/mysql/software/bin/mysqld[0xa3e751]
/home/mysql/software/bin/mysqld[0x9ee9b6]
/home/mysql/software/bin/mysqld[0x952b18]
/home/mysql/software/bin/mysqld[0x959e20]
/home/mysql/software/bin/mysqld(_ZN7handler7ha_openEP5TABLEPKcii+0x33)[0x5aa5c3]
/home/mysql/software/bin/mysqld(_Z21open_table_from_shareP3THDP11TABLE_SHAREPKcjjjP5TABLEb+0x61c)[0x7705cc]
/home/mysql/software/bin/mysqld(_Z10open_tableP3THDP10TABLE_LISTP18Open_table_context+0xc8b)[0x69fc0b]
/home/mysql/software/bin/mysqld(_Z11open_tablesP3THDPP10TABLE_LISTPjjP19Prelocking_strategy+0x839)[0x6a7d09]
/home/mysql/software/bin/mysqld(_Z30open_normal_and_derived_tablesP3THDP10TABLE_LISTj+0x4a)[0x6a878a]
/home/mysql/software/bin/mysqld(_Z18mysqld_list_fieldsP3THDP10TABLE_LISTPKc+0x25)[0x7222d5]
/home/mysql/software/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x2103)[0x6f66f3]
/home/mysql/software/bin/mysqld(_Z24do_handle_one_connectionP3THD+0x1ed)[0x6be7dd]
/home/mysql/software/bin/mysqld(handle_one_connection+0x39)[0x6be829]
/home/mysql/software/bin/mysqld(pfs_spawn_thread+0x140)[0x9374d0]
/lib64/libpthread.so.0(+0x7e65)[0x7f13417cae65]
/lib64/libc.so.6(clone+0x6d)[0x7f134089988d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f0f6000c078): is an invalid pointer
Connection ID (thread ID): 21
Status: NOT_KILLED
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.
210518 17:04:07 mysqld_safe Number of processes running now: 0
210518 17:04:07 mysqld_safe mysqld restarted
2021-05-18 17:04:07 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2021-05-18 17:04:07 3479 [Note] Plugin 'FEDERATED' is disabled.
2021-05-18 17:04:07 3479 [Note] InnoDB: Using atomics to ref count buffer pool pages
2021-05-18 17:04:07 3479 [Note] InnoDB: The InnoDB memory heap is disabled
2021-05-18 17:04:07 3479 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2021-05-18 17:04:07 3479 [Note] InnoDB: Compressed tables use zlib 1.2.3
2021-05-18 17:04:07 3479 [Note] InnoDB: Using CPU crc32 instructions
2021-05-18 17:04:07 3479 [Note] InnoDB: Initializing buffer pool, size = 12.0G
2021-05-18 17:04:08 3479 [Note] InnoDB: Completed initialization of buffer pool
2021-05-18 17:04:08 3479 [Note] InnoDB: Highest supported file format is Barracuda.
2021-05-18 17:04:08 3479 [Note] InnoDB: Log scan progressed past the checkpoint lsn 474510929998
2021-05-18 17:04:08 3479 [Note] InnoDB: Database was not shutdown normally!
2021-05-18 17:04:08 3479 [Note] InnoDB: Starting crash recovery.
2021-05-18 17:04:08 3479 [Note] InnoDB: Reading tablespace information from the .ibd files...
2021-05-18 17:04:08 3479 [Note] InnoDB: Restoring possible half-written data pages
2021-05-18 17:04:08 3479 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 474516172800
InnoDB: Doing recovery: scanned up to log sequence number 474519100469
2021-05-18 17:04:08 3479 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 8103845, file name mysql-bin.002311
2021-05-18 17:04:09 3479 [Note] InnoDB: 128 rollback segment(s) are active.
2021-05-18 17:04:10 3479 [Note] InnoDB: Waiting for purge to start
2021-05-18 17:04:10 3479 [Note] InnoDB: 5.6.16 started; log sequence number 474519100469
2021-05-18 17:04:10 3479 [Note] Recovering after a crash using mysql-bin
2021-05-18 17:04:10 3479 [Note] Starting crash recovery...
2021-05-18 17:04:10 3479 [Note] Crash recovery finished.
2021-05-18 17:04:10 3479 [Note] Server hostname (bind-address): '*'; port: 3306
2021-05-18 17:04:10 3479 [Note] IPv6 is available.
2021-05-18 17:04:10 3479 [Note] - '::' resolves to '::';
2021-05-18 17:04:10 3479 [Note] Server socket created on IP: '::'.
2021-05-18 17:04:10 3479 [Note] Event Scheduler: Loaded 0 events
2021-05-18 17:04:10 3479 [Note] /home/mysql/software/bin/mysqld: ready for connections.
Version: '5.6.16-log' socket: '/home/mysql/software/mysql.sock' port: 3306 Source distribution
my.cnf:
[mysqld]
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
innodb_buffer_pool_size = 12G
#innodb_additional_mem_pool_size=128M
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
# These are commonly set, remove the # and set as required.
# basedir = .....
datadir = /home/mysql/mysqldb
# port = .....
server_id = 94
log-bin=mysql-bin
expire_logs_days = 60
binlog-do-db=gomeet
binlog-do-db=gomeetLog
binlog_format=mixed
#innodb_file_per_table=1
#thread_concurrency=8
back_log=600
#innodb_force_recovery = 1
#innodb_file_format=Barracuda
#innodb_log_file_size=1024M
#innodb_strict_mode=0
#innodb_page_size=32K
#sort_buffer_size=8M
#read_buffer_size=8M
#read_rnd_buffer_size=8M
#table_open_cache=2048
max_allowed_packet=64M
#tmp_table_size=2G
#innodb_log_file_size=148M
# socket = .....
max_connections=1500
wait_timeout = 600
interactive_timeout = 600
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values# join_buffer_size = 128M
# join_buffer_size = 8M
# read_rnd_buffer_size = 2M
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
If I operate in the program api_worker_face_back MySQL will be triggered to restart once.
2021-05-18 03:16:10 5328 [ERROR] InnoDB: The OS said file flush did not succeed
2021-05-18 03:16:10 7f6a83305700 InnoDB: Operating system error number 5 in a file operation.
InnoDB: Error number 5 means 'Input/output error'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
2021-05-18 03:16:10 5328 [ERROR] InnoDB: File (unknown): 'flush' returned OS error 105. Cannot continue operation
210518 03:16:11 mysqld_safe Number of processes running now: 0
210518 03:16:11 mysqld_safe mysqld restarted
2021-05-18 03:16:11 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2021-05-18 03:16:11 5389 [Note] Plugin 'FEDERATED' is disabled.
2021-05-18 03:16:11 7f2d6eefe740 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2021-05-18 03:16:11 5389 [Note] InnoDB: Using atomics to ref count buffer pool pages
2021-05-18 03:16:11 5389 [Note] InnoDB: The InnoDB memory heap is disabled
2021-05-18 03:16:11 5389 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2021-05-18 03:16:11 5389 [Note] InnoDB: Compressed tables use zlib 1.2.3
2021-05-18 03:16:11 5389 [Note] InnoDB: Using CPU crc32 instructions
2021-05-18 03:16:11 5389 [Note] InnoDB: Initializing buffer pool, size = 12.0G
2021-05-18 03:16:11 5389 [Note] InnoDB: Completed initialization of buffer pool
2021-05-18 03:16:11 5389 [Note] InnoDB: Highest supported file format is Barracuda.
2021-05-18 03:16:11 5389 [Note] InnoDB: Log scan progressed past the checkpoint lsn 474072587915
2021-05-18 03:16:11 5389 [Note] InnoDB: Database was not shutdown normally!
2021-05-18 03:16:11 5389 [Note] InnoDB: Starting crash recovery.
2021-05-18 03:16:11 5389 [Note] InnoDB: Reading tablespace information from the .ibd files...
2021-05-18 03:16:11 5389 [Note] InnoDB: Restoring possible half-written data pages
2021-05-18 03:16:11 5389 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 474077830656
InnoDB: Doing recovery: scanned up to log sequence number 474083073536
InnoDB: Doing recovery: scanned up to log sequence number 474084218025
InnoDB: Transaction 7266397060 was in the XA prepared state.
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 0 row operations to undo
InnoDB: Trx id counter is 7266397440
2021-05-18 03:16:11 5389 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 8891015, file name mysql-bin.000851
2021-05-18 03:16:13 5389 [Note] InnoDB: 128 rollback segment(s) are active.
InnoDB: Starting in background the rollback of uncommitted transactions
2021-05-18 03:16:13 7f2a0da01700 InnoDB: Rollback of non-prepared transactions completed
2021-05-18 03:16:13 5389 [Note] InnoDB: Waiting for purge to start
2021-05-18 03:16:13 5389 [Note] InnoDB: 5.6.16 started; log sequence number 474084218025
2021-05-18 03:16:13 5389 [Note] Recovering after a crash using mysql-bin
2021-05-18 03:16:13 5389 [Note] Starting crash recovery...
2021-05-18 03:16:13 7f2d6eefe740 InnoDB: Starting recovery for XA transactions...
2021-05-18 03:16:13 7f2d6eefe740 InnoDB: Transaction 7266397060 in prepared state after recovery
2021-05-18 03:16:13 7f2d6eefe740 InnoDB: Transaction contains changes to 1 rows
2021-05-18 03:16:13 7f2d6eefe740 InnoDB: 1 transactions in prepared state after recovery
2021-05-18 03:16:13 5389 [Note] Found 1 prepared transaction(s) in InnoDB
2021-05-18 03:16:13 5389 [Note] Crash recovery finished.
2021-05-18 03:16:13 5389 [Note] Server hostname (bind-address): '*'; port: 3306
2021-05-18 03:16:13 5389 [Note] IPv6 is available.
2021-05-18 03:16:13 5389 [Note] - '::' resolves to '::';
2021-05-18 03:16:13 5389 [Note] Server socket created on IP: '::'.
2021-05-18 03:16:13 5389 [Note] Event Scheduler: Loaded 0 events
2021-05-18 03:16:13 5389 [Note] /home/mysql/software/bin/mysqld: ready for connections.
Version: '5.6.16-log' socket: '/home/mysql/software/mysql.sock' port: 3306 Source distribution
max_allowed_packet=64M
Adding this line into my.cnf file solves your problem.
This is useful when the columns have large values, which cause the issues, you can find the explanation here.
On Windows this file is located at: "C:\ProgramData\MySQL\MySQL Server 5.6"
On Linux (Ubuntu): /etc/mysql
Check this out: https://dev.mysql.com/doc/refman/8.0/en/replication-features-max-allowed-packet.html
I was adding a new field to an existing database with about 7 million records already within it. This modification suddenly caused mysql to crash and I cannot figure out how to recover things.
I am running a Vagrant/Homestead setup on my local windows 10 machine.
I run "vagrant ssh" to connect to the virtual box.
Output from /var/log/mysql/error.log
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 = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xeaf22b]
/usr/sbin/mysqld(handle_fatal_signal+0x48b)[0x7794ab]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f6eafeea890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f6eaf1e6e97]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f6eaf1e8801]
/usr/sbin/mysqld[0x74f996]
/usr/sbin/mysqld(_ZN2ib5fatalD1Ev+0x66)[0x1086196]
/usr/sbin/mysqld(_Z18os_file_flush_funci+0x1e0)[0xf69e00]
/usr/sbin/mysqld(_Z16os_file_set_sizePKc13pfs_os_file_tmb+0x324)[0xf71314]
/usr/sbin/mysqld(_ZN13SysTablespace8set_sizeER8Datafile+0x22b)[0x1156a8b]
/usr/sbin/mysqld(_ZN13SysTablespace14open_or_createEbbPmS0_+0xcf)[0x115921f]
/usr/sbin/mysqld(_Z34innobase_start_or_create_for_mysqlv+0x34c8)[0x1030628]
/usr/sbin/mysqld[0xef683d]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4f)[0x7cc69f]
/usr/sbin/mysqld[0xc888c5]
/usr/sbin/mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x1e5)[0xc8bde5]
/usr/sbin/mysqld[0x771770]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x795)[0x772e75]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f6eaf1c9b97]
/usr/sbin/mysqld(_start+0x2a)[0x76921a]
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.
2020-01-29T03:01:42.557756Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2020-01-29T03:01:42.558912Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.29-0ubuntu0.18.04.1) starting as process 10980 ...
2020-01-29T03:01:42.564351Z 0 [Note] InnoDB: PUNCH HOLE support available
2020-01-29T03:01:42.564377Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-01-29T03:01:42.564383Z 0 [Note] InnoDB: Uses event mutexes
2020-01-29T03:01:42.564388Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2020-01-29T03:01:42.564393Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-01-29T03:01:42.564397Z 0 [Note] InnoDB: Using Linux native AIO
2020-01-29T03:01:42.564680Z 0 [Note] InnoDB: Number of pools: 1
2020-01-29T03:01:42.564803Z 0 [Note] InnoDB: Using CPU crc32 instructions
2020-01-29T03:01:42.567749Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2020-01-29T03:01:42.579265Z 0 [Note] InnoDB: Completed initialization of buffer pool
2020-01-29T03:01:42.580822Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2020-01-29T03:01:42.592142Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2020-01-29T03:01:42.593066Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 62908547934
2020-01-29T03:01:42.601807Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 62909011867
2020-01-29T03:01:42.601920Z 0 [Note] InnoDB: Database was not shutdown normally!
2020-01-29T03:01:42.601926Z 0 [Note] InnoDB: Starting crash recovery.
2020-01-29T03:01:42.618100Z 0 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 16 17 18 19 20 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
2020-01-29T03:01:42.625779Z 0 [Note] InnoDB: Apply batch completed
2020-01-29T03:01:42.738017Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2020-01-29T03:01:42.738043Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-01-29T03:01:42.738085Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2020-01-29T03:01:42.748224Z 0 [ERROR] [FATAL] InnoDB: fsync() returned EIO, aborting.
2020-01-29 03:01:42 0x7fca264c1740 InnoDB: Assertion failure in thread 140506202642240 in file ut0ut.cc line 918
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.
03:01:42 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.
Any ideas how to proceed?
I attempted a reinstallation of mysql without any luck. The databases should still be there, but I am unsure if I am able to recover them now?
I was importing an old sql into existing schema. But the mysql service was stopped suddenly. Now I'm not able to start the service. It seems that the ibdata1 file is somehow corrupted. Here are the logs I got. I've tried several ways, such as adding the innodb_force_recovery in my.cnf, kill all of the mysql process. None of them works.
Could anyone help? Thanks in advance!!
I think I posted the wrong logs. This is the real log:
=======================
2017-12-08T17:56:24.927955Z 0 [Note] InnoDB: Using CPU crc32 instructions
2017-12-08T17:56:24.929802Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2017-12-08T17:56:24.942256Z 0 [Note] InnoDB: Completed initialization of buffer pool
2017-12-08T17:56:24.961017Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2017-12-08T17:56:24.962154Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 16417491586
2017-12-08T17:56:24.962169Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 16417493278
2017-12-08T17:56:24.963433Z 0 [Note] InnoDB: Database was not shutdown normally!
2017-12-08T17:56:24.963443Z 0 [Note] InnoDB: Starting crash recovery.
2017-12-08T17:56:24.996387Z 0 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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
2017-12-08T17:56:25.501869Z 0 [Note] InnoDB: Apply batch completed
2017-12-08T17:56:25.626479Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2017-12-08T17:56:25.626508Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2017-12-08T17:56:25.626637Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2017-12-08T17:56:25.649790Z 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2017-12-08T17:56:25.650460Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
2017-12-08T17:56:25.650469Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
2017-12-08T17:56:25.650670Z 0 [Note] InnoDB: Waiting for purge to start
2017-12-08T17:56:25.655806Z 0 [ERROR] InnoDB: Operating system error number 13 in a file operation.
2017-12-08T17:56:25.655825Z 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
2017-12-08 12:56:25 0x7000049f8000 InnoDB: Assertion failure in thread 123145379872768 in file fil0fil.cc line 896
InnoDB: Failing assertion: success
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.
17:56:25 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=8388608
read_buffer_size=131072
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 = 68218 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7f9792000000
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 = 7000049f7e20 thread_stack 0x40000
0 mysqld 0x000000010caa714a my_print_stacktrace + 58
1 mysqld 0x000000010ca039d0 handle_fatal_signal + 688
2 libsystem_platform.dylib 0x00007fffb8d52b3a _sigtramp + 26
3 mysqld 0x000000010d3bac17 _ZZN10binary_log4Uuid9to_stringEPKhPcE11byte_to_hex + 41879
4 libsystem_c.dylib 0x00007fffb8bd7420 abort + 129
5 mysqld 0x000000010ccfd9c1 _Z23ut_dbg_assertion_failedPKcS0_m + 161
6 mysqld 0x000000010cb623bc _ZL18fil_node_open_fileP10fil_node_t + 3948
7 mysqld 0x000000010cb6d962 _ZL23fil_node_prepare_for_ioP10fil_node_tP12fil_system_tP11fil_space_t + 194
8 mysqld 0x000000010cb6e418 _Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_ + 1096
9 mysqld 0x000000010cb27073 _ZL17buf_read_page_lowP7dberr_tbmmRK9page_id_tRK11page_size_tb + 387
10 mysqld 0x000000010cb27288 _Z13buf_read_pageRK9page_id_tRK11page_size_t + 56
11 mysqld 0x000000010cb0bb7a _Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb + 1290
12 mysqld 0x000000010cae91e8 _Z27btr_cur_search_to_nth_levelP12dict_index_tmPK8dtuple_t15page_cur_mode_tmP9btr_cur_tmPKcmP5mtr_t + 4008
13 mysqld 0x000000010cc97824 _Z21row_search_on_row_refP10btr_pcur_tmPK12dict_table_tPK8dtuple_tP5mtr_t + 164
14 mysqld 0x000000010cc956a6 _ZL34row_purge_remove_clust_if_poss_lowP12purge_node_tm + 438
15 mysqld 0x000000010cc93a68 _Z14row_purge_stepP9que_thr_t + 1944
16 mysqld 0x000000010cc55919 _Z15que_run_threadsP9que_thr_t + 937
17 mysqld 0x000000010ccd9c4d _Z9trx_purgemmb + 2973
18 mysqld 0x000000010ccc2d57 srv_purge_coordinator_thread + 2871
19 libsystem_pthread.dylib 0x00007fffb8d5c93b _pthread_body + 180
20 libsystem_pthread.dylib 0x00007fffb8d5c887 _pthread_body + 0
21 libsystem_pthread.dylib 0x00007fffb8d5c08d thread_start + 13
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
After setting innodb_file_format_max to Antelope instead of default Barraccuda and innodb_force_recovery to 2 (SRV_FORCE_NO_BACKGROUND) mysqld 10.2.17-MariaDB runs faultlessly in my development environment.
mysqld --innodb-force-recovery=2 --innodb-file-format-max=Antelope
As mentioned in innodb_force_recovery it wouldn't be wise to use this approach in production.
I used xampp v3.2.1 on windows 10. I have got Error: MySQL shutdown unexpectedly. problem. But apache is ok.
I already search a lot of answer with this problem by googling and it didn't match with my problem.
I already try to change port number to others one in my.ini but it didn't work.
I tried to delete all files except database folder in c:\xampp\mysql\data. But still getting the same error.
Here is my error log:
2017-03-02 11:53:53 a3c InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
170302 11:53:53 [Note] InnoDB: Using mutexes to ref count buffer pool pages
170302 11:53:53 [Note] InnoDB: The InnoDB memory heap is disabled
170302 11:53:53 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
170302 11:53:53 [Note] InnoDB: Memory barrier is not used
170302 11:53:53 [Note] InnoDB: Compressed tables use zlib 1.2.3
170302 11:53:53 [Note] InnoDB: Not using CPU crc32 instructions
170302 11:53:53 [Note] InnoDB: Initializing buffer pool, size = 16.0M
170302 11:53:53 [Note] InnoDB: Completed initialization of buffer pool
170302 11:53:53 [Note] InnoDB: Highest supported file format is Barracuda.
170302 11:53:53 [Note] InnoDB: Log scan progressed past the checkpoint lsn 49463
170302 11:53:53 [Note] InnoDB: Database was not shutdown normally!
170302 11:53:53 [Note] InnoDB: Starting crash recovery.
170302 11:53:53 [Note] InnoDB: Reading tablespace information from the .ibd files...
170302 11:53:53 [Note] InnoDB: Restoring possible half-written data pages
170302 11:53:53 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1600614
170302 11:53:53 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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
InnoDB: Apply batch completed
170302 11:53:54 [Note] InnoDB: 128 rollback segment(s) are active.
170302 11:53:54 [Note] InnoDB: Waiting for purge to start
170302 11:53:54 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.22-72.0 started; log sequence number 1600614
170302 11:53:54 [Note] Plugin 'FEEDBACK' is disabled.
170302 11:53:54 [Note] Server socket created on IP: '::'.
Check you have this two lines in the my.ini
[mysqld]
#
# * Basic Settings
#
port = 3306
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
Try to change mysql port:
xampp/mysql/bin/my.ini
In the last few weeks our mysql DB has been crashing randomly. -
I have ran a check against all the databases for corruption but all are OK.
EDIT 2016.01.14 - The error that keeps popping up commonly is the following -
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 0.
Although, the 'File Read Page' is always different, the last time it was Zero, but before that it was 4500.
A little background.
Been running Xampp for over a year without a problem
We have Applications constantly inserting data into MYSQL from lots of data sources, this is 24/7.
Apart from the above applications, nothing else runs around the time of the crash, I have also checked the system logs to see if anything sticks out but it doesn't.
Two weeks ago, we moved to another server with better spec, the old server was cloned and place on the new one.
Nothing has been altered in DB or new tables added.
Within a week, mysql started to produce errors.
The new server specs are as follows -
Windows Server 2008 R2 Standard - Running Service Pack 1
Proccessor: Intel(R) Xeon(R) # 3.3ghz 2x Dual processor
8GB Ram
64Bit OS (Same as old server)
MySQL Version: 5.6.20
PHP Version 5.5.15
Here are the recent error logs -
*************MYSQL ERROR LOG*****************
//////////////////////////////////*********************
ERROR on 2016-01-05
******************///////////////////////
InnoDB: The error means that the I/O operation has been aborted
InnoDB: because of either a thread exit or an application request.
InnoDB: Retry attempt is made.
2016-01-05 08:42:52 cc8 InnoDB: Operating system error number 995 in a file operation.
InnoDB: The error means that the I/O operation has been aborted
InnoDB: because of either a thread exit or an application request.
InnoDB: Retry attempt is made.
2016-01-05 08:42:52 cc8 InnoDB: Operating system error number 995 in a file operation.
InnoDB: The error means that the I/O operation has been aborted
InnoDB: because of either a thread exit or an application request.
InnoDB: Retry attempt is made.
2016-01-05 08:42:53 cc8 InnoDB: Operating system error number 995 in a file operation.
InnoDB: The error means that the I/O operation has been aborted
InnoDB: because of either a thread exit or an application request.
InnoDB: Retry attempt is made.
2016-01-05 08:42:53 cc8 InnoDB: Operating system error number 995 in a file operation.
InnoDB: The error means that the I/O operation has been aborted
InnoDB: because of either a thread exit or an application request.
InnoDB: Retry attempt is made.
//////////////////////////////////*********************
Error- 2015-12-22
********************************///////////////////////////
2015-12-22 16:46:02 12d4 InnoDB: uncompressed page, stored checksum in field1 1169359801, calculated checksums for field1: crc32 4003191917, innodb 1169359801, none 3735928559, stored checksum in field2 4049981449, calculated checksums for field2: crc32 4003191917, innodb 587193584, none 3735928559, page LSN 128 4137924960, low 4 bytes of LSN at page end 4137853843, page number (if stored to page already) 0, space id (if created with >= MySQL-4.1.1 and stored already) 252
InnoDB: Page may be a file space header page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 0.
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: Database page corruption on disk or a failed
InnoDB: file read of page 0.
InnoDB: You may have to recover from a backup.
2015-12-22 16:46:02 12d4 InnoDB: Page dump in ascii and hex (16384 bytes): // Lots of binary here ..
InnoDB: End of page dump
2015-12-22 16:46:03 12d4 InnoDB: uncompressed page, stored checksum in field1 1169359801, calculated checksums for field1: crc32 4003191917, innodb 1169359801, none 3735928559, stored checksum in field2 4049981449, calculated checksums for field2: crc32 4003191917, innodb 587193584, none 3735928559, page LSN 128 4137924960, low 4 bytes of LSN at page end 4137853843, page number (if stored to page already) 0, space id (if created with >= MySQL-4.1.1 and stored already) 252
InnoDB: Page may be a file space header page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 0.
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: Error: Unable to read tablespace 252 page no 0 into the buffer pool after 100 attempts
InnoDB: The most probable cause of this error may be that the table has been corrupted.
InnoDB: You can try to fix this problem by using innodb_force_recovery.
InnoDB: Please see reference manual for more details.
InnoDB: Aborting...
2015-12-22 16:46:03 12d4 InnoDB: Assertion failure in thread 4820 in file buf0buf.cc line 2641
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.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:46:03 UTC - mysqld got exception 0x80000003 ;
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.
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.
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=107
max_threads=151
thread_count=5
connection_count=5
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133778 K bytes
of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x22020238
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...
50a500
mysqld.exe!my_thread_name()
74392d mysqld.exe!my_mb_ctype_mb()
5ecdb6
mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
61d611
mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
647350
mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
6492fa
mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
649383
mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
6493b3
mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
64945d
mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
6495cb
mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
5d48e3
mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
53f011
mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
2be48e
mysqld.exe!?ha_write_row#handler##QAEHPAE#Z()
3d8d10
mysqld.exe!?write_record##YAHPAVTHD##PAUTABLE##PAVCOPY_INFO##2#Z()
3df599
mysqld.exe!?mysql_insert##YA_NPAVTHD##PAUTABLE_LIST##AAV?$List#VItem####AAV?$List#V?$List#VItem######22W4enum_duplicates##_N#Z()
2ecdf5
mysqld.exe!?mysql_execute_command##YAHPAVTHD###Z()
2ef81e
mysqld.exe!?mysql_parse##YAXPAVTHD##PADIPAVParser_state###Z()
2f06f8
mysqld.exe!?dispatch_command##YA_NW4enum_server_command##PAVTHD##PADI#Z()
2f135a
mysqld.exe!?do_command##YA_NPAVTHD###Z()
364e59 mysqld.exe!?do_handle_one_connection##YAXPAVTHD###Z()
364efd
mysqld.exe!handle_one_connection()
6bb8cb mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
510336
mysqld.exe!win_pthread_mutex_trylock()
746c00 mysqld.exe!my_mb_ctype_mb()
746c8a
mysqld.exe!my_mb_ctype_mb()
7728338a kernel32.dll!BaseThreadInitThunk()
77c297f2
ntdll.dll!RtlInitializeExceptionChain()
77c297c5
ntdll.dll!RtlInitializeExceptionChain()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (21e3387c): INSERT INTO 'WPM'(
`Pos`,
`FileMod`,
`Duration`) VALUES (
'IWM',
'2015-12-14 07:47:47 ',
0)Connection ID (thread ID): 3722
Status: NOT_KILLED
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.
2015-12-23 08:21:58 4920
[Note] Plugin 'FEDERATED' is disabled.
2015-12-23 08:21:58 10c4 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2015-12-23 08:21:58 4920 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-12-23 08:21:58 4920 [Note] InnoDB: The InnoDB memory heap is disabled
2015-12-23 08:21:58 4920 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2015-12-23 08:21:58 4920 [Note] InnoDB: Memory barrier is not used
2015-12-23 08:21:58 4920 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-12-23 08:21:58 4920 [Note] InnoDB: Not using CPU crc32 instructions
2015-12-23 08:21:58 4920 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2015-12-23 08:21:58 4920 [Note] InnoDB: Completed initialization of buffer pool
2015-12-23 08:21:58 4920 [Note] InnoDB: Highest supported file format is Barracuda.
2015-12-23 08:21:58 4920 [Note] InnoDB: Log scan progressed past the checkpoint lsn 553893690098
2015-12-23 08:21:58 4920 [Note] InnoDB: Database was not shutdown normally!
2015-12-23 08:21:58 4920 [Note] InnoDB: Starting crash recovery.
2015-12-23 08:21:58 4920 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-12-23 08:21:59 4920 [Note] InnoDB: Restoring possible half-written data pages
2015-12-23 08:21:59 4920 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 553893828751
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 151 row operations to undo
InnoDB: Trx id counter is 152858880
2015-12-23 08:22:00 4920 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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
InnoDB: Apply batch completed
2015-12-23 08:22:00 4920 [Note] InnoDB: 128 rollback segment(s) are active.
InnoDB: Starting in background the rollback of uncommitted transactions
2015-12-23 08:22:00 2c4 InnoDB: Rolling back trx with id 152858375, 151 rows to undo
2015-12-23 08:22:00 4920 [Note] InnoDB: Waiting for purge to start
2015-12-23 08:22:00 4920 [Note] InnoDB: Rollback of trx with id 152858375 completed
2015-12-23 08:22:00 2c4 InnoDB: Rollback of non-prepared transactions completed
2015-12-23 08:22:00 4920 [Note] InnoDB: 5.6.20 started; log sequence number 553893828751
2015-12-23 08:22:00 4920 [Note] Server hostname (bind-address): '*'; port: 3306
2015-12-23 08:22:00 4920 [Note] IPv6 is available.
2015-12-23 08:22:00 4920 [Note] - '::' resolves to '::';
2015-12-23 08:22:00 4920 [Note] Server socket created on IP: '::'.
2015-12-23 08:22:00 4920 [Note] Event Scheduler: Loaded 11 events
2015-12-23 08:22:00 4920 [Note] c:\xampp\mysql\bin\mysqld.exe: ready for connections.
Version: '5.6.20' socket: '' port: 3306 MySQL Community Server (GPL)
2015-12-23 08:24:07 5736 [Note] Plugin 'FEDERATED' is disabled.
2015-12-23 08:24:07 fc8 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2015-12-23 08:24:07 5736 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-12-23 08:24:07 5736 [Note] InnoDB: The InnoDB memory heap is disabled
2015-12-23 08:24:07 5736 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2015-12-23 08:24:07 5736 [Note] InnoDB: Memory barrier is not used
2015-12-23 08:24:07 5736 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-12-23 08:24:07 5736 [Note] InnoDB: Not using CPU crc32 instructions
2015-12-23 08:24:07 5736 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2015-12-23 08:24:07 5736 [Note] InnoDB: Completed initialization of buffer pool
2015-12-23 08:24:07 5736 [Note] InnoDB: Highest supported file format is Barracuda.
2015-12-23 08:24:07 5736 [Note] InnoDB: Log scan progressed past the checkpoint lsn 553896050587
2015-12-23 08:24:07 5736 [Note] InnoDB: Database was not shutdown normally!
2015-12-23 08:24:07 5736 [Note] InnoDB: Starting crash recovery.
2015-12-23 08:24:07 5736 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-12-23 08:24:07 5736 [Note] InnoDB: Restoring possible half-written data pages
2015-12-23 08:24:07 5736 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 553896774958
2015-12-23 08:24:07 5736 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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
InnoDB: Apply batch completed
//////////////////////////////////*********************
Error on 2016-01-08
********************////////////////////////
2016-01-08 00:00:14 1584 InnoDB: uncompressed page, stored checksum in field1 1299653197, calculated checksums for field1: crc32 90466284, innodb 1299653197, none 3735928559, stored checksum in field2 341870525, calculated checksums for field2: crc32 90466284, innodb 3590763946, none 3735928559, page LSN 129 3920058837, low 4 bytes of LSN at page end 3920015931, page number (if stored to page already) 75791, space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an update undo log page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 75791.
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.
2016-01-08 00:00:14 1584 InnoDB: Assertion failure in thread 5508 in file buf0buf.cc line 4195
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.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
00:00:14 UTC - mysqld got exception 0x80000003 ;
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.
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.
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=113
max_threads=151
thread_count=5
connection_count=4
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133778 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...
116a500 mysqld.exe!my_thread_name()
13a392d mysqld.exe!my_mb_ctype_mb()
12c7aa2 mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
12c82ad mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
1225a72 mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
11d423b mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
11d4694 mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
11d548a mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
11b147d mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
11b167d mysqld.exe!?my_aes_create_key##YAXPBEIPAEW4my_aes_opmode###Z()
7728338a kernel32.dll!BaseThreadInitThunk()
77c297f2 ntdll.dll!RtlInitializeExceptionChain()
77c297c5 ntdll.dll!RtlInitializeExceptionChain()
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.
InnoDB: Warning: a long semaphore wait:
--Thread 6764 has waited at trx0undo.cc line 1778 for 29770.00 seconds the semaphore:
Mutex at 1B4F60EC created file trx0rseg.cc line 196, lock var 1
waiters flag 1
InnoDB: ###### Starts InnoDB Monitor for 30 secs to print diagnostic info:
InnoDB: Pending preads 0, pwrites 0
Here is the mysql.ini settings file (If this helps)
# The MySQL server
[mysqld]
port= 3306
socket = "C:/xampp/mysql/mysql.sock"
basedir = "C:/xampp/mysql"
tmpdir = "C:/xampp/tmp"
datadir = "C:/xampp/mysql/data"
pid_file = "mysql.pid"
# enable-named-pipe
key_buffer = 16M
max_allowed_packet = 1M
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
log_error = "mysql_error.log"
# Change here for bind listening
# bind-address="127.0.0.1"
# bind-address = ::1 # for ipv6
# Where do all the plugins live
plugin_dir = "C:/xampp/mysql/lib/plugin/"
# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the "enable-named-pipe" option) will render mysqld useless!
#
# commented in by lampp security
#skip-networking
skip-federated
# Replication Master Server (default)
# binary logging is required for replication
# log-bin deactivated by default since XAMPP 1.4.11
#log-bin=mysql-bin
# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id = 1
# Replication Slave (comment out master section to use this)
#
# To configure this host as a replication slave, you can choose between
# two methods :
#
# 1) Use the CHANGE MASTER TO command (fully described in our manual) -
# the syntax is:
#
# CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>,
# MASTER_USER=<user>, MASTER_PASSWORD=<password> ;
#
# where you replace <host>, <user>, <password> by quoted strings and
# <port> by the master's port number (3306 by default).
#
# Example:
#
# CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306,
# MASTER_USER='joe', MASTER_PASSWORD='secret';
#
# OR
#
# 2) Set the variables below. However, in case you choose this method, then
# start replication for the first time (even unsuccessfully, for example
# if you mistyped the password in master-password and the slave fails to
# connect), the slave will create a master.info file, and any later
# change in this file to the variables' values below will be ignored and
# overridden by the content of the master.info file, unless you shutdown
# the slave server, delete master.info and restart the slaver server.
# For that reason, you may want to leave the lines below untouched
# (commented) and instead use CHANGE MASTER TO (see above)
#
# required unique id between 2 and 2^32 - 1
# (and different from the master)
# defaults to 2 if master-host is set
# but will not function as a slave if omitted
#server-id = 2
#
# The replication master for this slave - required
#master-host = <hostname>
#
# The username the slave will use for authentication when connecting
# to the master - required
#master-user = <username>
#
# The password the slave will authenticate with when connecting to
# the master - required
#master-password = <password>
#
# The port the master is listening on.
# optional - defaults to 3306
#master-port = <port>
#
# binary logging - not required for slaves, but recommended
#log-bin=mysql-bin
# Point the following paths to different dedicated disks
#tmpdir = "C:/xampp/tmp"
#log-update = /path-to-dedicated-directory/hostname
# Uncomment the following if you are using BDB tables
#bdb_cache_size = 4M
#bdb_max_lock = 10000
# Comment the following if you are using InnoDB tables
#skip-innodb
innodb_data_home_dir = "C:/xampp/mysql/data"
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = "C:/xampp/mysql/data"
#innodb_log_arch_dir = "C:/xampp/mysql/data"
## You can set .._buffer_pool_size up to 50 - 80 %
## of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 16M
innodb_additional_mem_pool_size = 2M
## Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 5M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50
## UTF 8 Settings
#init-connect=\'SET NAMES utf8\'
#collation_server=utf8_unicode_ci
#character_set_server=utf8
#skip-character-set-client-handshake
#character_sets-dir="C:/xampp/mysql/share/charsets"
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates
[isamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M
[myisamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M
[mysqlhotcopy]
interactive-timeout
I simply have no idea what to do, I have no experience in the technical side to troubleshooting Mysql. I have looked on the MYsql site, are apparently error code 995 is a known bug, it was meant to be fixed, but I read that it never got pushed into the build.
If you need any more info please ask!
InnoDB deliberately crashes MySQL if it reads a page from "disk" (might come from RAM though if the relevant blocks are in OS cache) and the checksum mismatches with the one in the page header. This is what's happening to you.
Reasons could be:
If you're not using ECC ram you might just have some corrupted data in OS cache. Rebooting the server will clear the cache and you can get some ECC ram to prevent it happening. (less likely)
On disk corruption (more likely):
If you're lucky the corruption is on index pages and you can fully recover by doing a innodb_recovery (http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html)
If the corruption is on data page you most certainly will lose data but you still should be able to recover most of the information using the same method.
In such cases I would just restore from backup if that's possible. The other error you pasted also indicates system level I/O issues so I would look into it soon before it crashes completely.
I believe some pages in Innodb tablespace got corrupted..
First backup your DB!
First suggestion would be to run check table using this command:
mysqlcheck -A --auto-repair
Reference: Here
Add the following line below the mysqld section in the mysql config file (my.ini) and restart both the apache and mysql service afterwards.
innodb_force_recovery = 1
For your information: read this
Note: Innodb becomes read only for data operations when running in innodb_force_recovery mode
If this is not working, my second suggestion would be to decrease the innodb_buffer_pool_size and convert some "heavey loading" tables into MyISAM:
ALTER TABLE table_name ENGINE=MYISAM
Although you increased the specs of your machine, due to high usage of your DB table can still cause a problem.
(Please update me and which you good luck!)