enter image description here
nnoDB: ###### Diagnostic info printed to the standard error stream
2023-02-15T03:39:09.042343+05:30 0 [ERROR] [MY-012872] [InnoDB] [FATAL] Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.
2023-02-15T03:39:09.085843+05:30 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: ut0ut.cc:553 thread 140316173764352
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/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
Related
I have an Innodb database which have a big table with many rows. Once I'm trying to access the data or run any query(like "check table_name") against this specific table mysql crashes(restarts) and I'm getting the error:
ERROR 2013 (HY000): Lost connection to MySQL server during query
I have already tried to increase max_packetsize and the net_timeouts flags.
Any help will be appreciated, Thanks!
Edit:
Crash log:
2022-12-30T16:25:56.676880Z 208 [ERROR] InnoDB: In pages [page id: space=372, pa ge number=11135] and [page id: space=372, page number=11136] of index `GEN_CLUST _INDEX` of table `SHAS_2015_NEW`.`b_media_21_646_0000_11925`
InnoDB: broken FIL_PAGE_NEXT or FIL_PAGE_PREV links
2022-12-30T16:25:56.676925Z 208 [ERROR] InnoDB: In pages [page id: space=372, pa ge number=11135] and [page id: space=372, page number=11136] of index `GEN_CLUST _INDEX` of table `SHAS_2015_NEW`.`b_media_21_646_0000_11925`
InnoDB: 'compact' flag mismatch
2022-12-30T16:25:56.676936Z 208 [ERROR] InnoDB: Page index id 0 != data dictiona ry index id 577
2022-12-30 18:25:56 0x7fa1384e9700 InnoDB: Assertion failure in thread 14033041 1136768 in file btr0btr.cc line 4710
InnoDB: Failing assertion: !page_is_empty(page) || (level == 0 && page_get_page_ no(page) == dict_index_get_page(index))
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.
16:25:56 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=16777216
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 76388 K b ytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7fa0f81dd110
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 = 7fa1384e8e70 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xe8e68b]
/usr/sbin/mysqld(handle_fatal_signal+0x36f)[0x77524f]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7fa67f45d390]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7fa67e816438]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fa67e81803a]
/usr/sbin/mysqld[0x74a77c]
/usr/sbin/mysqld[0x10dd73d]
/usr/sbin/mysqld(_Z18btr_validate_indexP12dict_index_tPK5trx_tb+0x264)[0x10dec34 ]
/usr/sbin/mysqld(_ZN11ha_innobase5checkEP3THDP15st_ha_check_opt+0x278)[0xf2a378]
/usr/sbin/mysqld(_ZN7handler8ha_checkEP3THDP15st_ha_check_opt+0x7b)[0x7cd71b]
/usr/sbin/mysqld[0xdb48f4]
/usr/sbin/mysqld(_ZN19Sql_cmd_check_table7executeEP3THD+0x97)[0xdb5497]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THDb+0x2160)[0xc42570]
/usr/sbin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x3dd)[0xc473ad]
/usr/sbin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x11a 0)[0xc48610]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x1c7)[0xc49ae7]
/usr/sbin/mysqld(handle_connection+0x290)[0xd0e140]
/usr/sbin/mysqld(pfs_spawn_thread+0x1b4)[0xeb03e4]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7fa67f4536ba]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fa67e8e851d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7fa0f8072240): check table b_media_21_646_0000_11925
Connection ID (thread ID): 208
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.
2022-12-30T16:25:56.970335Z 0 [Warning] Changed limits: max_open_files: 1024 (re quested 5000)
2022-12-30T16:25:56.970397Z 0 [Warning] Changed limits: table_open_cache: 431 (r equested 2000)
2022-12-30T16:25:57.145883Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see doc umentation for more details).
2022-12-30T16:25:57.148901Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.33-0ubuntu0.16 .04.1-log) starting as process 9454 ...
2022-12-30T16:25:57.153242Z 0 [Note] InnoDB: PUNCH HOLE support available
2022-12-30T16:25:57.153267Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-12-30T16:25:57.153272Z 0 [Note] InnoDB: Uses event mutexes
2022-12-30T16:25:57.153276Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2022-12-30T16:25:57.153283Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.8
2022-12-30T16:25:57.153286Z 0 [Note] InnoDB: Using Linux native AIO
2022-12-30T16:25:57.153526Z 0 [Note] InnoDB: Number of pools: 1
2022-12-30T16:25:57.153643Z 0 [Note] InnoDB: Using CPU crc32 instructions
2022-12-30T16:25:57.155093Z 0 [Note] InnoDB: Initializing buffer pool, total siz e = 20G, instances = 8, chunk size = 128M
2022-12-30T16:25:58.482523Z 0 [Note] InnoDB: Completed initialization of buffer pool
2022-12-30T16:25:58.719968Z 0 [Note] InnoDB: If the mysqld execution user is aut horized, page cleaner thread priority can be changed. See the man page of setpri ority().
2022-12-30T16:25:58.744995Z 0 [Note] InnoDB: Highest supported file format is Ba rracuda.
2022-12-30T16:25:58.915826Z 0 [Note] InnoDB: Log scan progressed past the checkp oint lsn 10408206134578
2022-12-30T16:25:58.915857Z 0 [Note] InnoDB: Doing recovery: scanned up to log s equence number 10408206134587
2022-12-30T16:25:58.915862Z 0 [Note] InnoDB: Database was not shutdown normally!
2022-12-30T16:25:58.915872Z 0 [Note] InnoDB: Starting crash recovery.
2022-12-30T16:25:59.270028Z 0 [Note] InnoDB: Last MySQL binlog file position 0 1 862900, file name mysql-bin.000001
2022-12-30T16:26:00.014203Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2022-12-30T16:26:00.014242Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-12-30T16:26:00.014281Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-12-30T16:26:00.075009Z 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-12-30T16:26:00.076863Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
2022-12-30T16:26:00.076904Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
2022-12-30T16:26:00.077640Z 0 [Note] InnoDB: Waiting for purge to start
2022-12-30T16:26:00.127880Z 0 [Note] InnoDB: 5.7.33 started; log sequence number 10408206134587
2022-12-30T16:26:00.128095Z 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2022-12-30T16:26:00.128605Z 0 [Note] Plugin 'FEDERATED' is disabled.
2022-12-30T16:26:00.138272Z 0 [Note] Recovering after a crash using /var/log/mysql/mysql-bin
2022-12-30T16:26:00.138325Z 0 [Note] Starting crash recovery...
2022-12-30T16:26:00.138384Z 0 [Note] Crash recovery finished.
If I'm Using select with Limit statement then I can select up to 681,000 rows
I would like to ask your support to solve my problem, I have a server in mysql which suffered a download, to ignite I realize that the MySQL service had died.
When you want to start it simply mark the following error in console.
Job failed to start
Reviewing the mysql error.log file here is what it shows:
170411 11:11:30 [Note] Plugin 'FEDERATED' is disabled.
170411 11:11:30 InnoDB: The InnoDB memory heap is disabled
170411 11:11:30 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170411 11:11:30 InnoDB: Compressed tables use zlib 1.2.3.4
170411 11:11:30 InnoDB: Initializing buffer pool, size = 128.0M
170411 11:11:30 InnoDB: Completed initialization of buffer pool
170411 11:11:30 InnoDB: highest supported file format is Barracuda.
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 1 row operations to undo
InnoDB: Trx id counter is F6B400
InnoDB: Starting in background the rollback of uncommitted transactions
170411 11:11:32 InnoDB: Rolling back trx with id F6B22B, 1 rows to undo
170411 11:11:32 InnoDB: Waiting for the background threads to start
170411 11:11:32 InnoDB: Assertion failure in thread 2791775040 in file fut0lst.ic line 83
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:11:32 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=16777216
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 = 346075 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 = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x33)[0xb72f0a43]
/usr/sbin/mysqld(handle_fatal_signal+0x484)[0xb719cfa4]
[0xb6e50400]
/usr/sbin/mysqld(+0x5cb933)[0xb743e933]
/usr/sbin/mysqld(+0x5490e7)[0xb73bc0e7]
/usr/sbin/mysqld(+0x55f4c2)[0xb73d24c2]
/usr/sbin/mysqld(+0x556c54)[0xb73c9c54]
/usr/sbin/mysqld(+0x558093)[0xb73cb093]
/usr/sbin/mysqld(+0x5510ba)[0xb73c40ba]
/usr/sbin/mysqld(+0x610f7a)[0xb7483f7a]
/usr/sbin/mysqld(+0x611524)[0xb7484524]
/usr/sbin/mysqld(+0x551645)[0xb73c4645]
/usr/sbin/mysqld(+0x551d19)[0xb73c4d19]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d4c)[0xb6dc9d4c]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb6bd8ace]
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.
170411 11:11:32 [Note] Plugin 'FEDERATED' is disabled.
170411 11:11:32 InnoDB: The InnoDB memory heap is disabled
170411 11:11:32 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170411 11:11:32 InnoDB: Compressed tables use zlib 1.2.3.4
170411 11:11:32 InnoDB: Initializing buffer pool, size = 128.0M
170411 11:11:32 InnoDB: Completed initialization of buffer pool
170411 11:11:32 InnoDB: highest supported file format is Barracuda.
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 1 row operations to undo
InnoDB: Trx id counter is F6B400
170411 11:11:32 InnoDB: Waiting for the background threads to start
InnoDB: Starting in background the rollback of uncommitted transactions
170411 11:11:32 InnoDB: Rolling back trx with id F6B22B, 1 rows to undo
170411 11:11:32 InnoDB: Assertion failure in thread 2791775040 in file fut0lst.ic line 83
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:11:32 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=16777216
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 = 346075 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 = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x33)[0xb731ca43]
/usr/sbin/mysqld(handle_fatal_signal+0x484)[0xb71c8fa4]
[0xb6e7c400]
/usr/sbin/mysqld(+0x5cb933)[0xb746a933]
/usr/sbin/mysqld(+0x5490e7)[0xb73e80e7]
/usr/sbin/mysqld(+0x55f4c2)[0xb73fe4c2]
/usr/sbin/mysqld(+0x556c54)[0xb73f5c54]
/usr/sbin/mysqld(+0x558093)[0xb73f7093]
/usr/sbin/mysqld(+0x5510ba)[0xb73f00ba]
/usr/sbin/mysqld(+0x610f7a)[0xb74aff7a]
/usr/sbin/mysqld(+0x611524)[0xb74b0524]
/usr/sbin/mysqld(+0x551645)[0xb73f0645]
/usr/sbin/mysqld(+0x551d19)[0xb73f0d19]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d4c)[0xb6df5d4c]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb6c04ace]
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.
170411 11:11:33 [Note] Plugin 'FEDERATED' is disabled.
170411 11:11:33 InnoDB: The InnoDB memory heap is disabled
170411 11:11:33 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170411 11:11:33 InnoDB: Compressed tables use zlib 1.2.3.4
170411 11:11:33 InnoDB: Initializing buffer pool, size = 128.0M
170411 11:11:33 InnoDB: Completed initialization of buffer pool
170411 11:11:33 InnoDB: highest supported file format is Barracuda.
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 1 row operations to undo
InnoDB: Trx id counter is F6B400
170411 11:11:33 InnoDB: Waiting for the background threads to start
InnoDB: Starting in background the rollback of uncommitted transactions
170411 11:11:33 InnoDB: Rolling back trx with id F6B22B, 1 rows to undo
170411 11:11:33 InnoDB: Assertion failure in thread 2791775040 in file fut0lst.ic line 83
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:11:33 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=16777216
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 = 346075 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 = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x33)[0xb72c5a43]
/usr/sbin/mysqld(handle_fatal_signal+0x484)[0xb7171fa4]
[0xb6e25400]
/usr/sbin/mysqld(+0x5cb933)[0xb7413933]
/usr/sbin/mysqld(+0x5490e7)[0xb73910e7]
/usr/sbin/mysqld(+0x55f4c2)[0xb73a74c2]
/usr/sbin/mysqld(+0x556c54)[0xb739ec54]
/usr/sbin/mysqld(+0x558093)[0xb73a0093]
/usr/sbin/mysqld(+0x5510ba)[0xb73990ba]
/usr/sbin/mysqld(+0x610f7a)[0xb7458f7a]
/usr/sbin/mysqld(+0x611524)[0xb7459524]
/usr/sbin/mysqld(+0x551645)[0xb7399645]
/usr/sbin/mysqld(+0x551d19)[0xb7399d19]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d4c)[0xb6d9ed4c]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb6badace]
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.
I would like to have your help, sorry if it is obvious the error in the log but I am not an expert in servers I only have a little knowledge.
I'm having problems with MariaDB, while it was first working fine. I only restarted the server, when I couldn't start the MySQL daemon anymore. It seems to still be using my old USB-stick's file path (/media/brood), while I already switched over to a new HDD instead (/media/seagate). This is the error I'm getting in /var/log/mysql/error.log:
160728 9:32:32 [ERROR] mysqld: Can't lock aria control file '/media/brood/mysql/aria_log_control' for exclusive use, error: 11. Will retry for 30 seconds
160728 9:33:03 [ERROR] mysqld: Got error 'Could not get an exclusive lock; file is probably in use by another process' when trying to use aria control file '/media/brood/mysql/aria_log_control'
160728 9:33:03 [ERROR] Plugin 'Aria' init function returned error.
160728 9:33:03 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
160728 9:33:03 [Note] InnoDB: Using mutexes to ref count buffer pool pages
160728 9:33:03 [Note] InnoDB: The InnoDB memory heap is disabled
160728 9:33:03 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
160728 9:33:03 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
160728 9:33:03 [Note] InnoDB: Compressed tables use zlib 1.2.8
160728 9:33:03 [Note] InnoDB: Using Linux native AIO
160728 9:33:03 [Note] InnoDB: Not using CPU crc32 instructions
160728 9:33:03 [Note] InnoDB: Initializing buffer pool, size = 128.0M
160728 9:33:03 [Note] InnoDB: Completed initialization of buffer pool
160728 9:33:03 [ERROR] InnoDB: Unable to lock ./ib_logfile0, error: 11
160728 9:33:03 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
160728 9:33:03 [ERROR] InnoDB: Unable to open './ib_logfile0'
160728 9:33:03 [ERROR] Plugin 'InnoDB' init function returned error.
160728 9:33:03 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
160728 9:33:03 [Note] Plugin 'FEEDBACK' is disabled.
mysqld: Too many arguments (first extra is 'stop').
160728 9:33:03 [ERROR] Aborting
160728 9:33:03 [Note] mysqld: Shutdown complete
It could also be permission issues, or maybe files are still locked (I don't know how that works), because the last time the Raspberry Pi restarted, it was because someone accidentally pulled out the power plug of the Pi.
Why the log contained the path to the old mysql data folder is still a mystery to me. (It's not even the previous USB-stick, to make the story more complete, it's actually the USB-stick I used before that!) But, the problem is solved! The answer was actually much simpler than I thought, it turns out, my brother uninstalled something (an emulator for playing old games, he said), when he noticed it uninstalled mariadb-server-10.0 (strange!). So I did a simple sudo apt-get install mariadb-server-10.0, and guess what! It solved my problem! :D
I hope someone can help me with this problem I'm having (I'm a newbie to Mysql and Stackoverflow, so it's probably something silly I'm missing)...
Whenever I build a large table in MySQL and then restart xampp's local MySQL server, the table then becomes unreadable under code runs that consider the 'whole' table - e.g. I can't drop it, run mySQLCheck on it or run any aggregation functions like sum / count.
This only happens after a server restart. It is fine when I build the table and then, without restarting, I run the 'whole table' codes on it I mentioned above.
Also, even after a server restart I can still do things like see the indexes in place, or sample the first x rows using Limit.
The error thrown is 'mysqld.exe has stopped working' - 'a problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available'
I stop and restart my server using the xampp start / stop control panel buttons
This only seems to happen when the table is more than 4gb. I'm using innodb
Thank you in advance!
Paul
===============================
An example of the error log result is below. This table (wikivisitstable10) was created by adding an index to the prior table. There are no crash issues with the prior table, just this one - and any similar tables >4gb:
`2016-08-25 0:22:57 6804 [Warning] option
'innodb-max-dirty-pages-pct': value 0 adjusted to 0.001
2016-08-25 0:22:57 6804 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-08-25 0:22:57 6804 [Note] InnoDB: The InnoDB memory heap is disabled
2016-08-25 0:22:57 6804 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions 2016-08-25 0:22:57 6804
[Note] InnoDB: Memory barrier is not used 2016-08-25 0:22:57 6804
[Note] InnoDB: Compressed tables use zlib 1.2.3
2016-08-25 0:22:57 6804 [Note] InnoDB: Using generic crc32 instructions
2016-08-25 0:22:57 6804 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2016-08-25 0:22:57 6804 [Note] InnoDB: Completed initialization of
buffer pool
2016-08-25 0:22:57 6804 [Note] InnoDB: Highest supported
file format is Barracuda.
2016-08-25 0:22:57 6804 [Note] InnoDB: The log sequence numbers 400931068139 and 400931068139 in ibdata files do not match the log sequence number 400931068159 in the ib_logfiles!
2016-08-25 0:22:57 6804 [Note] InnoDB: Database was not shutdown
normally!
2016-08-25 0:22:57 6804 [Note] InnoDB: Starting crash
recovery.
2016-08-25 0:22:57 6804 [Note] InnoDB: Reading tablespace
information from the .ibd files...
2016-08-25 0:22:58 6804 [Note] InnoDB: Restoring possible half-written data pages
2016-08-25 0:22:58 6804 [Note] InnoDB: from the doublewrite buffer...
2016-08-25 00:22:59 1a94 InnoDB: Error: table 'revil2/page'
InnoDB: in InnoDB data dictionary has tablespace id 180, InnoDB: but a tablespace with that id does not exist. There is InnoDB: a tablespace of name revil2/page and id 181, though. Have InnoDB: you deleted or moved .ibd files?
InnoDB: Please refer to InnoDB: DATADICT LINK (REMOVED)
InnoDB: for how to resolve the issue.
2016-08-25 0:22:59 6804 [ERROR] InnoDB: Table revil2/wikipages7 in the InnoDB data dictionary has tablespace id 175, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary.
InnoDB: Please refer to InnoDB: DATA DICT LINK (REMOVED)
InnoDB: for how to resolve the issue.
2016-08-25 0:22:59 6804 [Note] InnoDB: 128 rollback segment(s) are active.
2016-08-25 0:22:59 6804 [Note] InnoDB: Waiting for purge to start
2016-08-25 0:22:59 6804 [Note] InnoDB: Percona XtraDB (PERCONA
WEBSITE (REMOVED)) 5.6.28-76.1 started; log sequence number
400931068159
2016-08-25 0:22:59 5820 [Note] InnoDB: Dumping buffer pool(s) not yet started
2016-08-25 00:22:59 16bc InnoDB: Loading buffer pool(s) from .\\ib_buffer_pool
2016-08-25 0:22:59 6804 [Note] Plugin 'FEEDBACK' is disabled.
2016-08-25 0:22:59 6804 [Note] Server socket created on IP: '::'.
2016-08-25 00:22:59 16bc InnoDB: Buffer pool(s) load completed at 160825 0:22:59
2016-08-25 0:23:00 6804 [Note] c:\xampp\mysql\bin\mysqld.exe: ready for connections. Version: '10.1.13-MariaDB' socket: '' port: 3306 mariadb.org binary distribution
InnoDB: Error: trying to access page number 1794 in space 299, InnoDB: space name revil2/wikivisitstable10, 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.
2016-08-25 00:23:46 1388 InnoDB: Assertion failure in thread 5000 in file fil0fil.cc line 5866
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: FORCING INNODB RECOVERY LINK (REMOVED)
InnoDB: about forcing recovery. 160825 0:23:46
[ERROR] 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.
Server version: 10.1.13-MariaDB
key_buffer_size=268435456
read_buffer_size=268435456
max_used_connections=1
max_threads=1001
thread_count=1
It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 788380 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x1c172e20 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...
mysqld.exe!my_parameter_handler() mysqld.exe!my_mb_ctype_mb()
mysqld.exe!?get_ctx#MDL_ticket##QBEPAVMDL_context##XZ()
mysqld.exe!?get_ctx#MDL_ticket##QBEPAVMDL_context##XZ()
mysqld.exe!?functype#Item_func_dyncol_create##UBE?AW4Functype#Item_func##XZ()
mysqld.exe!?get_ctx#MDL_ticket##QBEPAVMDL_context##XZ()
mysqld.exe!?get_ctx#MDL_ticket##QBEPAVMDL_context##XZ()
mysqld.exe!?get_trg_event_map#Update_rows_log_event##UAEEXZ()
mysqld.exe!?ha_check#handler##QAEHPAVTHD##PAUst_ha_check_opt###Z()
mysqld.exe!??_9handler##$BBAE#AE()
mysqld.exe!?execute#Sql_cmd_check_table##UAE_NPAVTHD###Z()
mysqld.exe!?mysql_execute_command##YAHPAVTHD###Z()
mysqld.exe!?mysql_parse##YAXPAVTHD##PADIPAVParser_state###Z()
mysqld.exe!?dispatch_command##YA_NW4enum_server_command##PAVTHD##PADI#Z()
mysqld.exe!?do_command##YA_NPAVTHD###Z()
mysqld.exe!?threadpool_process_request##YAHPAVTHD###Z()
mysqld.exe!?tp_end##YAXXZ() KERNEL32.DLL!SetUserGeoID()
ntdll.dll!TpSimpleTryPost() ntdll.dll!EtwNotificationRegister()
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlUnicodeStringToInteger()
ntdll.dll!RtlUnicodeStringToInteger()
Trying to get some variables. Some pointers may be invalid and cause
the dump to abort. Query (0x1c232750): CHECK TABLE
`wikivisitstable10` Connection ID (thread ID): 2 Status: NOT_KILLED`
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on
I tried running optimize on one of my tables, and when I did the server crashed. Now when I try to restart it, I get this error:
The server quit without updating PID file (/usr/local/mysql/data/Diskise.pid).
Then when I look at the error log to help me see what happened, I don't really understand it. What can I do to get my server back up?
131117 17:13:43 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data
2013-11-17 17:13:44 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2013-11-17 17:13:44 29352 [Note] Plugin 'FEDERATED' is disabled.
2013-11-17 17:13:44 29352 [Note] InnoDB: The InnoDB memory heap is disabled
2013-11-17 17:13:44 29352 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2013-11-17 17:13:44 29352 [Note] InnoDB: Compressed tables use zlib 1.2.3
2013-11-17 17:13:44 29352 [Note] InnoDB: Using Linux native AIO
2013-11-17 17:13:44 29352 [Note] InnoDB: Not using CPU crc32 instructions
2013-11-17 17:13:44 29352 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2013-11-17 17:13:44 29352 [Note] InnoDB: Completed initialization of buffer pool
2013-11-17 17:13:44 29352 [Note] InnoDB: Highest supported file format is Barracuda.
2013-11-17 17:13:44 29352 [Note] InnoDB: Log scan progressed past the checkpoint lsn 57196040504
2013-11-17 17:13:44 29352 [Note] InnoDB: Database was not shutdown normally!
2013-11-17 17:13:44 29352 [Note] InnoDB: Starting crash recovery.
2013-11-17 17:13:44 29352 [Note] InnoDB: Reading tablespace information from the .ibd files...
2013-11-17 17:13:44 29352 [Note] InnoDB: Restoring possible half-written data pages
2013-11-17 17:13:44 29352 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 57201283072
InnoDB: Doing recovery: scanned up to log sequence number 57204973005
InnoDB: Error: trying to access page number 377945542 in space 0,
InnoDB: space name ./ibdata1,
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.
2013-11-17 17:13:44 b73ae700 InnoDB: Assertion failure in thread 3074090752 in file fil0fil.cc line 5423
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.
17:13:44 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=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 = 67592 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 = 0 thread_stack 0x30000
/usr/local/mysql/bin/mysqld(my_print_stacktrace+0x33)[0x84e19b3]
/usr/local/mysql/bin/mysqld(handle_fatal_signal+0x3c8)[0x826c218]
[0xb76ef400]
[0xb76ef416]
/lib/i386-linux-gnu/libc.so.6(gsignal+0x4f)[0xb73de1df]
/lib/i386-linux-gnu/libc.so.6(abort+0x175)[0xb73e1825]
/usr/local/mysql/bin/mysqld[0x864f06f]
/usr/local/mysql/bin/mysqld[0x861d3f3]
/usr/local/mysql/bin/mysqld[0x861e03d]
/usr/local/mysql/bin/mysqld[0x8605e5c]
/usr/local/mysql/bin/mysqld[0x85d135f]
/usr/local/mysql/bin/mysqld[0x85c649d]
/usr/local/mysql/bin/mysqld[0x85c739e]
/usr/local/mysql/bin/mysqld[0x85c844f]
/usr/local/mysql/bin/mysqld[0x85b33d9]
/usr/local/mysql/bin/mysqld[0x84f593a]
/usr/local/mysql/bin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x43)[0x81c1c93]
/usr/local/mysql/bin/mysqld[0x82f32bd]
/usr/local/mysql/bin/mysqld(_Z11plugin_initPiPPci+0x7c8)[0x82f5058]
/usr/local/mysql/bin/mysqld(_Z11mysqld_mainiPPc+0x8c3)[0x81bae83]
/usr/local/mysql/bin/mysqld(main+0x1b)[0x819b30b]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb73c94d3]
/usr/local/mysql/bin/mysqld[0x81afa11]
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.
131117 17:13:44 mysqld_safe mysqld from pid file /usr/local/mysql/data/Diskise.pid ended