javascript - mongodb 无法在 mac os 上启动

Question

mongod 没有在我的 mac 上启动。

这是我在运行 mongod 时遇到的错误

2019-02-05T18:30:15.744-0800 I CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-02-05T18:30:15.822-0800 I CONTROL  [initandlisten] MongoDB starting : pid=34864 port=27017 dbpath=/data/db 64-bit host=Dawits-MacBook-Pro.local
2019-02-05T18:30:15.822-0800 I CONTROL  [initandlisten] db version v4.0.5
2019-02-05T18:30:15.822-0800 I CONTROL  [initandlisten] git version: 3739429dd92b92d1b0ab120911a23d50bf03c412
2019-02-05T18:30:15.822-0800 I CONTROL  [initandlisten] allocator: system
2019-02-05T18:30:15.822-0800 I CONTROL  [initandlisten] modules: none
2019-02-05T18:30:15.822-0800 I CONTROL  [initandlisten] build environment:
2019-02-05T18:30:15.822-0800 I CONTROL  [initandlisten]     distarch: x86_64
2019-02-05T18:30:15.822-0800 I CONTROL  [initandlisten]     target_arch: x86_64
2019-02-05T18:30:15.822-0800 I CONTROL  [initandlisten] options: {}
2019-02-05T18:30:15.825-0800 F STORAGE  [initandlisten] An incomplete repair has been detected! This is likely because a repair operation unexpectedly failed before completing. MongoDB will not start up again without --repair.
2019-02-05T18:30:15.825-0800 F -        [initandlisten] Fatal Assertion 50922 at src/mongo/db/storage/storage_engine_init.cpp 86
2019-02-05T18:30:15.825-0800 F -        [initandlisten] 

***aborting after fassert() failure

我确实运行了 mongod --repair 并且我收到如下错误。我不确定如何解决这个问题。过去几周前工作正常。这是最近发生的

00 I CONTROL  [initandlisten] 
2019-02-05T18:32:34.607-0800 I CONTROL  [initandlisten] 
2019-02-05T18:32:34.607-0800 I CONTROL  [initandlisten] ** WARNING: soft rlimits too low. Number of files is 256, should be at least 1000
2019-02-05T18:32:34.612-0800 I STORAGE  [initandlisten] repairDatabase admin
2019-02-05T18:32:34.612-0800 I STORAGE  [initandlisten] Repairing collection admin.system.version
2019-02-05T18:32:34.613-0800 I STORAGE  [initandlisten] Verify succeeded on uri table:collection-2-6265190839484826835. Not salvaging.
2019-02-05T18:32:34.639-0800 I INDEX    [initandlisten] build index on: admin.system.version properties: { v: 1, key: { _id: 1 }, name: "_id_", ns: "admin.system.version" }
2019-02-05T18:32:34.639-0800 I INDEX    [initandlisten]      building index using bulk method; build may temporarily use up to 250 megabytes of RAM
2019-02-05T18:32:34.654-0800 I INDEX    [initandlisten] build index on: admin.system.version properties: { v: 2, key: { version: 1 }, name: "incompatible_with_version_32", ns: "admin.system.version" }
2019-02-05T18:32:34.655-0800 I INDEX    [initandlisten]      building index using bulk method; build may temporarily use up to 250 megabytes of RAM
2019-02-05T18:32:34.691-0800 I STORAGE  [initandlisten] repairDatabase local
2019-02-05T18:32:34.691-0800 I STORAGE  [initandlisten] Repairing collection local.startup_log
2019-02-05T18:32:34.693-0800 I STORAGE  [initandlisten] Verify succeeded on uri table:collection-0-6265190839484826835. Not salvaging.
2019-02-05T18:32:34.718-0800 I INDEX    [initandlisten] build index on: local.startup_log properties: { v: 1, key: { _id: 1 }, name: "_id_", ns: "local.startup_log" }
2019-02-05T18:32:34.718-0800 I INDEX    [initandlisten]      building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2019-02-05T18:32:34.738-0800 I STORAGE  [initandlisten] repairDatabase loginapp
2019-02-05T18:32:34.739-0800 I STORAGE  [initandlisten] Repairing collection loginapp.users
2019-02-05T18:32:34.740-0800 I STORAGE  [initandlisten] Verify succeeded on uri table:collection-0-7733536157857540484. Not salvaging.
2019-02-05T18:32:34.755-0800 I INDEX    [initandlisten] build index on: loginapp.users properties: { v: 2, key: { _id: 1 }, name: "_id_", ns: "loginapp.users" }
2019-02-05T18:32:34.756-0800 I INDEX    [initandlisten]      building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2019-02-05T18:32:34.770-0800 I STORAGE  [initandlisten] repairDatabase test_1
2019-02-05T18:32:34.770-0800 I STORAGE  [initandlisten] Repairing collection test_1.test_1
2019-02-05T18:32:34.774-0800 I STORAGE  [initandlisten] Verify succeeded on uri table:collection-0-3774245883137780326. Not salvaging.
2019-02-05T18:32:34.807-0800 I INDEX    [initandlisten] build index on: test_1.test_1 properties: { v: 2, key: { _id: 1 }, name: "_id_", ns: "test_1.test_1" }
2019-02-05T18:32:34.807-0800 I INDEX    [initandlisten]      building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2019-02-05T18:32:34.823-0800 F CONTROL  [initandlisten] ** IMPORTANT: UPGRADE PROBLEM: The data files need to be fully upgraded to version 3.6 before attempting an upgrade to 4.0; see http://dochub.mongodb.org/core/4.0-upgrade-fcv for more details.
2019-02-05T18:32:34.824-0800 I STORAGE  [initandlisten] WiredTigerKVEngine shutting down
2019-02-05T18:32:34.930-0800 I STORAGE  [initandlisten] Downgrading WiredTiger datafiles.
2019-02-05T18:32:35.116-0800 I STORAGE  [initandlisten] WiredTiger message [1549420355:116716][34873:0x7fffa63ce380], txn-recover: Main recovery loop: starting at 29/24576 to 30/256
2019-02-05T18:32:35.241-0800 I STORAGE  [initandlisten] WiredTiger message [1549420355:241902][34873:0x7fffa63ce380], txn-recover: Recovering log 29 through 30
2019-02-05T18:32:35.326-0800 I STORAGE  [initandlisten] WiredTiger message [1549420355:326013][34873:0x7fffa63ce380], txn-recover: Recovering log 30 through 30
2019-02-05T18:32:35.394-0800 I STORAGE  [initandlisten] WiredTiger message [1549420355:394299][34873:0x7fffa63ce380], txn-recover: Set global recovery timestamp: 0
2019-02-05T18:32:35.617-0800 I STORAGE  [initandlisten] shutdown: removing fs lock...
2019-02-05T18:32:35.618-0800 I CONTROL  [initandlisten] now exiting
2019-02-05T18:32:35.618-0800 I CONTROL  [initandlisten] shutting down with code:62

Answer 1

我相信您会收到此错误，因为数据文件最初是使用与您尝试运行的版本(显然是 4.0.5)不同的 Mongo 版本编写的。如果是这种情况，您需要降级到正确的版本——可能是 3.6.x 或更低版本。关注these procedures正确升级。