MySQL большие таблицы (>4 ГБ) повреждены после перезагрузки локального сервера
Я надеюсь, что кто-то может помочь мне с этой проблемой, которую я имею (я новичок в Mysql и Stackru, так что это, вероятно, что-то глупое, что мне не хватает)...
Всякий раз, когда я собираю большую таблицу в MySQL, а затем перезапускаю локальный сервер MySQL xampp, эта таблица становится недоступной для чтения при выполнении кода, который рассматривает "целую" таблицу - например, я не могу ее отбросить, запустить mySQLCheck или запустить какие-либо функции агрегирования, такие как sum / count,
Это происходит только после перезапуска сервера. Это нормально, когда я строю таблицу, а затем, не перезапускаясь, запускаю коды "всей таблицы", о которых я упоминал выше.
Кроме того, даже после перезапуска сервера я все еще могу делать такие вещи, как просмотр индексов на месте или выборку первых x строк, используя Limit,
Выдается сообщение об ошибке: "mysqld.exe перестал работать" - из-за проблемы программа перестала работать правильно. Windows закроет программу и сообщит вам, если решение доступно ".
Я останавливаю и перезагружаю свой сервер с помощью кнопок панели запуска / остановки xampp
Кажется, это происходит только тогда, когда размер таблицы превышает 4 ГБ. Я пользуюсь innodb
Заранее спасибо!
Павел
===============================
Пример результата журнала ошибок приведен ниже. Эта таблица (wikivisitstable10) была создана путем добавления индекса к предыдущей таблице. С предыдущей таблицей проблем сбоев нет, только эта - и любые подобные таблицы>4 ГБ:
`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