0

我有几个数据库：
- curr
- curr_add

和许多其他人在同一个 MariaDB 实例上。当我向curr_add提交 sql 时，我得到了连接和结果。当我将查询发送到curr时，出现错误：
MariaDB: ERROR 2013 (HY000): Lost connection to MySQL server during query

在此处输入图像描述

服务停止。每次我想访问数据库curr时重新启动服务时，服务就会停止。对于同一实例的所有其他数据库，情况并非如此。实例和数据库存在一年以来，我从来没有这样的问题。有没有办法找出问题所在以及如何解决？

工作环境：

  • Windows 7的
  • MariaDB 10.2.6
  • 我以root身份输入：mysql -uroot -h localhost -p

在此处输入图像描述

在此处输入图像描述

更新（1）：

我可以访问数据库information_schema。例如，我可以计算表system_variables :的行数SELECT COUNT(*) FROM system_variables。但是，如果我尝试对表列:进行相同SELECT COUNT(*) FROM columns操作，则连接将丢失（见图）。

在此处输入图像描述

我提交：
SELECT COUNT(*) FROM tables
或者
SELECT table_schema, table_name FROM tables
我得到结果。
但是如果我提交
SELECT * FROM tables
或
SELECT table_schema, table_name, engine, table_rows FROM tables LIMIT 10
连接将丢失。

摘要：一些数据库断开了 mysql-server 以及一些表的列。

更新（2）：来自文件 .err 的错误信息

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.
2017-11-28 19:42:43 7820 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2017-11-28 19:42:43 7820 [Note] InnoDB: Uses event mutexes
2017-11-28 19:42:43 7820 [Note] InnoDB: Compressed tables use zlib 1.2.3
2017-11-28 19:42:43 7820 [Note] InnoDB: Number of pools: 1
2017-11-28 19:42:43 7820 [Note] InnoDB: Using generic crc32 instructions
2017-11-28 19:42:43 7820 [Note] InnoDB: Initializing buffer pool, total size = 14G, instances = 8, chunk size = 128M
2017-11-28 19:42:44 7820 [Note] InnoDB: Completed initialization of buffer pool
2017-11-28 19:42:44 7820 [Note] InnoDB: Highest supported file format is Barracuda.
2017-11-28 19:42:44 7820 [Note] InnoDB: Starting crash recovery from checkpoint LSN=556718604758
2017-11-28 19:42:52 7820 [Note] InnoDB: 128 out of 128 rollback segments are active.
2017-11-28 19:42:52 7820 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2017-11-28 19:42:52 7820 [Note] InnoDB: Creating shared tablespace for temporary tables
2017-11-28 19:42:52 7820 [Note] InnoDB: Setting file '.\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2017-11-28 19:42:52 7820 [Note] InnoDB: File '.\ibtmp1' size is now 12 MB.
2017-11-28 19:42:52 7820 [Note] InnoDB: 5.7.14 started; log sequence number 556718604767
2017-11-28 19:42:52 4868 [Note] InnoDB: page_cleaner: 1000ms intended loop took 7784ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
2017-11-28 19:42:52 7380 [Note] InnoDB: Loading buffer pool(s) from C:\Program Files\MariaDB 10.2\data\ib_buffer_pool
2017-11-28 19:42:52 7820 [Note] Server socket created on IP: '::'.
2017-11-28 19:42:52 7820 [Note] Reading of all Master_info entries succeded
2017-11-28 19:42:52 7820 [Note] Added new Master_info '' to hash table
2017-11-28 19:42:52 7820 [Note] C:\Program Files\MariaDB 10.2\bin\mysqld.exe: ready for connections.
Version: '10.2.6-MariaDB'  socket: ''  port: 3306  mariadb.org binary distribution
2017-11-28 19:44:08 7380 [Note] InnoDB: Buffer pool(s) load completed at 171128 19:44:08
2017-11-28 19:44:20 9820 [Warning] InnoDB: Retry attempts for reading partial data failed.
2017-11-28 19:44:20 9820 [ERROR] InnoDB: Tried to read 16384 bytes at offset 4947968, but was only able to read 0
2017-11-28 19:44:20 9820 [ERROR] InnoDB: File (unknown): 'read' returned OS error 0. Cannot continue operation
171128 19:44:20 [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.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

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.2.6-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=1
max_threads=65537
thread_count=7
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 136026 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7d1b9fd8
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()[my_init.c:259]
mysqld.exe!raise()[signal.cpp:516]
mysqld.exe!abort()[abort.cpp:71]
mysqld.exe!os_file_handle_error_cond_exit()[os0file.cc:5209]
mysqld.exe!os_file_read_page()[os0file.cc:5091]
mysqld.exe!os_file_read_func()[os0file.cc:5433]
mysqld.exe!fil_io()[fil0fil.cc:5436]
mysqld.exe!buf_read_page_low()[buf0rea.cc:179]
mysqld.exe!buf_read_page()[buf0rea.cc:436]
mysqld.exe!buf_page_get_gen()[buf0buf.cc:4267]
mysqld.exe!btr_cur_search_to_nth_level()[btr0cur.cc:1115]
mysqld.exe!btr_pcur_open_low()[btr0pcur.ic:457]
mysqld.exe!btr_pcur_open_on_user_rec_func()[btr0pcur.cc:597]
mysqld.exe!dict_load_foreign()[dict0load.cc:3334]
mysqld.exe!dict_load_foreigns()[dict0load.cc:3587]
mysqld.exe!dict_load_table_one()[dict0load.cc:2958]
mysqld.exe!dict_load_table()[dict0load.cc:2670]
mysqld.exe!dict_table_open_on_name()[dict0dict.cc:1174]
mysqld.exe!ha_innobase::open_dict_table()[ha_innodb.cc:6976]
mysqld.exe!ha_innobase::open()[ha_innodb.cc:6618]
mysqld.exe!handler::ha_open()[handler.cc:2507]
mysqld.exe!open_table_from_share()[table.cc:3278]
mysqld.exe!open_table()[sql_base.cc:1874]
mysqld.exe!open_and_process_table()[sql_base.cc:3409]
mysqld.exe!open_tables()[sql_base.cc:3926]
mysqld.exe!open_and_lock_tables()[sql_base.cc:4682]
mysqld.exe!execute_sqlcom_select()[sql_parse.cc:6352]
mysqld.exe!mysql_execute_command()[sql_parse.cc:3448]
mysqld.exe!mysql_parse()[sql_parse.cc:7879]
mysqld.exe!dispatch_command()[sql_parse.cc:1814]
mysqld.exe!do_command()[sql_parse.cc:1361]
mysqld.exe!threadpool_process_request()[threadpool_common.cc:346]
mysqld.exe!tp_callback()[threadpool_common.cc:192]
ntdll.dll!TpPostWork()
ntdll.dll!RtlRealSuccessor()
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x78b38ff0): SELECT COUNT(*) FROM curr.patient
Connection ID (thread ID): 9
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,orderby_uses_equalities=on,condition_pushdown_for_derived=on

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.
4

2 回答 2

2

根据堆栈跟踪，似乎是 InnoDB 系统表空间比预期的要短。当函数dict_load_foreigns()正在访问 InnoDB 系统表SYS_FOREIGN时SYS_FOREIGN_COLS，它正在请求一个不在缓冲池中的页面。页面读取请求导致 InnoDB 自杀，因为文件太短。

众所周知，InnoDB 不会报告有问题的文件名。我们应该在某个时候重构 MariaDB 中的 I/O 代码。在这种情况下，我们确实知道问题出在 InnoDB 系统表空间中，因为 InnoDB 内部SYS_表位于那里。

MariaDB 跟踪器中已经存在一些相关的错误。我认为这种情况已经被这些覆盖了：

了解腐败最初是如何发生的会很有趣。在MDEV-11556之前，MariaDB 中的 InnoDB 数据文件扩展名不是完全安全的。（MySQL 根本不包含此修复程序。）

难道是文件在某个时候被复制了？复制过程中的错误？或者系统表空间可能最初由多个文件组成，但服务器启动错误innodb_data_file_path，导致最后一个文件被忽略？在访问“丢失”文件中的页面之前，一切都会看起来很好。

您可能会问：如何解决此错误？不幸的是，我认为目前没有任何方法可以跳过外键元数据的读取。因此，如果元数据表损坏，在最坏的情况下您将无法访问任何 InnoDB 表。为此，我欢迎一份MariaDB 错误报告。

于 2017-11-30T07:39:06.040 回答
1

我想重新安装 MariaDB。当我通过 Window 7 的应用程序向导开始卸载/更改 MaridaDB 时，它询问我是否要更改/修复/删除。我决定修理。之后，MariaDB 照常工作。那就是我可以在不丢失连接的情况下提交查询。

从 MariaDB 从 10.2.6 升级到 10.2.11 没有帮助。修复让我成功了。

在此处输入图像描述

经验教训：在要求 SO 修复 MariaDB 之前。

于 2017-12-08T07:25:33.607 回答