[SERVER-41403] mongo无法启动 Created: 30/May/19 Updated: 11/Jul/19 Resolved: 11/Jul/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 3.4.9 |
| Fix Version/s: | None |
| Type: | Question | Priority: | Major - P3 |
| Reporter: | xu wang | Assignee: | Eric Sedor |
| Resolution: | Done | Votes: | 0 |
| Labels: | wtc | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
CentOS_7.2 vm |
||
| Participants: |
| Description |
|
启动时报以下错误,有没有遇到类似问题,谢谢! , processManagement: { fork: true }, replication: { replSet: "shardsvrReplC" }, security: { keyFile: "/data01/mongo.key" }, sharding: { clusterRole: "shardsvr" }, storage: { dbPath: "/data01/shardsvr/data" }, systemLog: { destination: "file", path: "/data01/shardsvr/log/mongod.log" } } ***aborting after fassert() failure 2019-05-31T02:00:11.491+0800 F - [initandlisten] Got signal: 6 (Aborted). 0x5604d5a695e1 0x5604d5a687f9 0x5604d5a68cdd 0x7f8d58d57370 0x7f8d589bc1d7 0x7f8d589bd8c8 0x5604d4d0fa33 0x5604d577baf6 0x5604d4d19d42 0x5604d4d19f5e 0x5604d4d1a1b6 0x5604d6373be5 0x5604d638d96b 0x5604d6394ac5 0x5604d63b59b0 0x5604d63838d2 0x5604d63d27d4 0x5604d646324e 0x5604d63f9020 0x5604d6463f72 0x5604d63c8f07 0x5604d63c1122 0x5604d57608ba 0x5604d5759105 0x5604d564b627 0x5604d4cfbc0c 0x5604d4d1b56b 0x7f8d589a8b35 0x5604d4d7a4ff |
| Comments |
| Comment by Eric Sedor [ 11/Jul/19 ] |
|
Hi, We haven’t heard back from you for some time, so I’m going to mark this ticket as resolved. If this is still an issue for you, please provide additional information and we will reopen the ticket. Be well! |
| Comment by Eric Sedor [ 24/Jun/19 ] |
|
Hi, We still need additional information to diagnose the problem. If this is still an issue for you, would you please consider my above questions? Thanks, |
| Comment by Eric Sedor [ 03/Jun/19 ] |
|
wangxu1234, this error message leads us to suspect some form of physical corruption. Please make a complete copy of the database's $dbpath directory to work off of and safeguard the current $dbpath. The ideal resolution is to perform a clean resync from an unaffected node. You can try mongod --repair], but this may be unlikely to work as the error message suggests physical corruption within an index file ( file:index-70441-3718103833483666497.wt). Our ability to determine the source of this corruption depends greatly on your ability to provide:
|