首页 > 解决方案 > 您如何从从驱动器访问和使用先前的 MongoDB 数据库?

问题描述

我有两台 Windows 10 电脑,并且 MongoDB 3.6 都在两台电脑上运行。

然后 PC#1 的主板死机。

现在我被困在尝试从 PC#2 上的先前硬盘驱动器(现在是驱动器 E)访问旧的 MongoDB 数据库。

到目前为止,其他帖子中的这些“解决方案”都没有奏效:

1.使用--dbpath

这失败了,我得到的错误是:

C:\Users\User1>mongod --dbpath "E:\data\db"
2020-09-24T14:50:46.231-0700 I CONTROL  [initandlisten] MongoDB starting : pid=20304 port=27017 dbpath=E:\data\db 64-bit host=USER-PC
2020-09-24T14:50:46.232-0700 I CONTROL  [initandlisten] targetMinOS: Windows 7/Windows Server 2008 R2
2020-09-24T14:50:46.233-0700 I CONTROL  [initandlisten] db version v3.6.2
2020-09-24T14:50:46.233-0700 I CONTROL  [initandlisten] git version: 489d177dbd0f0420a8ca04d39fd78d0a2c539420
2020-09-24T14:50:46.233-0700 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.1u-fips  22 Sep 2016
2020-09-24T14:50:46.233-0700 I CONTROL  [initandlisten] allocator: tcmalloc
2020-09-24T14:50:46.233-0700 I CONTROL  [initandlisten] modules: none
2020-09-24T14:50:46.233-0700 I CONTROL  [initandlisten] build environment:
2020-09-24T14:50:46.233-0700 I CONTROL  [initandlisten]     distmod: 2008plus-ssl
2020-09-24T14:50:46.233-0700 I CONTROL  [initandlisten]     distarch: x86_64
2020-09-24T14:50:46.234-0700 I CONTROL  [initandlisten]     target_arch: x86_64
2020-09-24T14:50:46.234-0700 I CONTROL  [initandlisten] options: { storage: { dbPath: "E:\data\db" } }
2020-09-24T14:50:46.239-0700 I -        [initandlisten] Detected data files in E:\data\db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2020-09-24T14:50:46.240-0700 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=7652M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2020-09-24T14:50:46.264-0700 E STORAGE  [initandlisten] WiredTiger error (-31802) [1600984246:264159][20304:140736298704464], txn-recover: unsupported WiredTiger file version: this build  only supports versions up to 2, and the file is version 3: WT_ERROR: non-specific WiredTiger error
2020-09-24T14:50:46.265-0700 E STORAGE  [initandlisten] WiredTiger error (0) [1600984246:265156][20304:140736298704464], txn-recover: WiredTiger is unable to read the recovery log.
2020-09-24T14:50:46.265-0700 E STORAGE  [initandlisten] WiredTiger error (0) [1600984246:265156][20304:140736298704464], txn-recover: This may be due to the log files being encrypted, being from an older version or due to corruption on disk
2020-09-24T14:50:46.266-0700 E STORAGE  [initandlisten] WiredTiger error (0) [1600984246:265156][20304:140736298704464], txn-recover: You should confirm that you have opened the database with the correct options including all encryption and compression options
2020-09-24T14:50:46.266-0700 E STORAGE  [initandlisten] WiredTiger error (-31802) [1600984246:266156][20304:140736298704464], txn-recover: Recovery failed: WT_ERROR: non-specific WiredTiger error
2020-09-24T14:50:46.272-0700 E -        [initandlisten] Assertion: 28595:-31802: WT_ERROR: non-specific WiredTiger error src\mongo\db\storage\wiredtiger\wiredtiger_kv_engine.cpp 413
2020-09-24T14:50:46.272-0700 I STORAGE  [initandlisten] exception in initAndListen: Location28595: -31802: WT_ERROR: non-specific WiredTiger error, terminating
2020-09-24T14:50:46.272-0700 I NETWORK  [initandlisten] shutdown: going to close listening sockets...
2020-09-24T14:50:46.273-0700 I CONTROL  [initandlisten] now exiting
2020-09-24T14:50:46.273-0700 I CONTROL  [initandlisten] shutting down with code:100

2. 创建一个空的 E:/data/db,运行 --dbpath "E:/data/db",CTRL + C 停止它,然后将所有数据移回,删除 mongod.lock,然后重新运行 --dbpath “E:/数据/分贝”

这最初起作用,直到我将所有数据移回并重新运行命令的最后一部分。

有谁知道我能做什么?我需要从第二个硬盘驱动器访问我的数据并且卡住了。

标签: mongodb

解决方案


那里的相关错误是:

txn-recover: 不支持的 WiredTiger 文件版本:此构建仅支持最高 2 的版本,并且文件是版本 3:WT_ERROR: non-specific WiredTiger 错误

WiredTiger 无法读取恢复日志。

这是在告诉你,WiredTiger 无法阅读之前编写的日志。

要尝试的事情(按顺序):

  1. 检查其他服务器使用的配置文件或启动脚本。确保您使用任何加密、每个 DB 的目录或以前使用的其他数据路径相关选项。

  2. 升级到更新版本的 MongoDB。
    如果文件是由较新版本写入的,则旧版本将无法读取它们。

  3. 删除日志目录中的文件。
    这可能会导致在崩溃前最后几分钟写入其他节点的数据丢失,但也可能允许服务器启动。

  4. 从备份中恢复。
    虽然从服务器上的文件中恢复很好,但有时最好硬着头皮回到已知的好点。

  5. 尝试从 --repair 命令行选项开始。
    这很丑陋。
    真的很丑。
    虽然它可能会让服务器启动,但您肯定会在此过程中丢失一些数据。


推荐阅读