连接时MonetDB崩溃.不会重新启动.大型原木



我最近通过将机器映像从一个位置转移到另一个位置,将MonetDB的一个实例迁移到具有更多内存和更大硬盘的机器上。数据库工作得很短暂,但现在当我试图连接mclient时,我得到了以下错误:

$ mclient warehouse
user(monetdb):monetdb
password:
monetdbd: internal error while starting mserver 'database 'warehouse' has crashed after starting, manual intervention needed, check monetdbd's logfile (merovingian.log) for details'

在检查merovingian.log后,我可以看到数据库启动了,但在mclient尝试连接时崩溃了:

2022-02-09 14:11:29 MSG merovingian[4368]: database 'warehouse' has crashed after start on 2022-02-09 14:03:23, attempting restart, up min/avg/max: 2m/6w/22w, crash average: 1.00 1.00 0.97 (135-6=129)

然后,数据库尝试重新启动并显示正常,直到尝试读取引用到write-ahead log的内容。

2022-02-09 14:11:29 MSG warehouse[4403]: arguments:
2022-02-09 14:11:29 MSG warehouse[4403]: /usr/bin/mserver5 --dbpath=/home/db_user/monetDBDatabase/warehouse/warehouse --set merovingian_uri=mapi:monetdb://dev:50000/warehouse --set mapi_listenaddr=none --set mapi_usock=/home/db_user/monetDBDatabase/warehouse/warehouse/.mapi.sock --set monet_vault_key=/home/db_user/monetDBDatabase/warehouse/warehouse/.vaultkey --set
2022-02-09 14:11:29 MSG warehouse[4403]: gdk_nr_threads=36 --set max_clients=64 --set sql_optimizer=default_pipe
2022-02-09 14:11:40 MSG warehouse[4403]: # MonetDB 5 server v11.39.17 (Oct2020-SP5)
2022-02-09 14:11:40 MSG warehouse[4403]: # Serving database 'warehouse', using 36 threads
2022-02-09 14:11:40 MSG warehouse[4403]: # Compiled for x86_64-pc-linux-gnu/64bit with 128bit integers
2022-02-09 14:11:40 MSG warehouse[4403]: # Found 125.609 GiB available main-memory of which we use 102.371 GiB
2022-02-09 14:11:40 MSG warehouse[4403]: # Copyright (c) 1993 - July 2008 CWI.
2022-02-09 14:11:40 MSG warehouse[4403]: # Copyright (c) August 2008 - 2021 MonetDB B.V., all rights reserved
2022-02-09 14:11:40 MSG warehouse[4403]: # Visit https://www.monetdb.org/ for further information
2022-02-09 14:11:40 MSG warehouse[4403]: # Listening for UNIX domain connection requests on mapi:monetdb:///home/db_user/monetDBDatabase/warehouse/warehouse/.mapi.sock
2022-02-09 14:11:40 MSG warehouse[4403]: # still reading write-ahead log "/home/db_user/monetDBDatabase/warehouse/warehouse/sql_logs/sql/log.95638" (22% done)
2022-02-09 14:11:51 MSG warehouse[4403]: # still reading write-ahead log "/home/db_user/monetDBDatabase/warehouse/warehouse/sql_logs/sql/log.95638" (44% done)
2022-02-09 14:12:02 MSG warehouse[4403]: # still reading write-ahead log "/home/db_user/monetDBDatabase/warehouse/warehouse/sql_logs/sql/log.95638" (67% done)

这个过程一直持续到系统的虚拟内存耗尽,如下面的日志摘录所示:

2022-02-09 14:18:52 MSG warehouse[4403]: # still reading write-ahead log "/home/db_user/monetDBDatabase/warehouse/warehouse/sql_logs/sql/log.95650" (92% done)
2022-02-09 14:18:56 ERR warehouse[4403]: #main thread: GDKmmap: !ERROR: requested too much virtual memory; memory requested: 43317329920, memory in use: 208390400, virtual memory in use: 4354888091904

在整个过程中,我对系统进行了监控,内存使用率在可接受的范围内,在126GB中使用了大约1GB的内存。奇怪的是MonetDB正在生成的文件的大小。

原始数据库的大小约为5Tb,尽管我也可以看到在warehouse/sql_logs/sql中找到的write-ahead log是65GB,而另一个文件warehouse/mdbtrace.log占用了另一个5Tb。

如果我试图删除write-ahead log,那么数据库不会开始引用文件丢失的消息,mdbtrace.log也是如此(如果需要,我可以重新创建并发布确切的消息(。除此之外,我还试过重新启动机器。我得到的印象是,mdbtrace.log的大尺寸通过占用虚拟存储器所需的空间来阻止虚拟存储器空间读取write-ahead log

如果您能帮助我解决这些错误,以便我可以使用mclient启动并连接到数据库,我们将不胜感激。

问候,

James

首先,文件mdbtrace.log不是数据库的部分,因此可以(重新(移动。是数据库的部分,是预写日志,即sql_logs目录中的文件。这些是在启动过程中正在处理的。

Sjoerd在上面指出,可以安全地删除mtrace.log文件,以便在磁盘上腾出空间。我完成了这项工作,并在merovingian.log中得到以下错误:

2022-02-09 15:57:08 ERR control[8803]: !monetdbd: an internal error has occurred 'unknown or impossible state: 4'
2022-02-09 15:57:13 ERR merovingian[8803]: client error: unknown or impossible state: 4

这导致了关机,并通过重新启动计算机来解决。当从这一点开始尝试连接mclient时,write-ahead log(s(出现了与原始帖子中相同的错误。

在调查中,我注意到warehouse/sql_logs/sql中有一个名为log的文件,其结构如下:

052205
95662

以前,在该目录中找到的日志编号的范围是从95638到95662,当mclient尝试连接到最近启动的monetdbd实例时,修改第二个编号使其值接近95662会导致跳过这些write-ahead log,这意味着虚拟内存未满,客户端可以正常连接和查询数据库。

注意,采取此操作后观察到一些数据丢失

然而,考虑到另一种选择是删除5Tb的数据,并从原始CSV中重新加载所有内容,这一过程需要数周时间,因此该解决方案是受欢迎的使用风险自负

最新更新