一、mongodb systemd failed
[root@cementindustrynode5 monit.d]# systemctl status mongodb-27017.service ● mongodb-27017.service - mongodb Loaded: loaded (/etc/systemd/system/mongodb-27017.service; enabled; vendor preset: disabled) Active: failed (Result: timeout) since Fri 2026-10-16 15:48:41 CST; 29s ago Process: 3547030 ExecStart=/mnt/allin_data/allin/mongodb-27017/bin/mongod --config /mnt/allin_data/allin/mongodb-27017/mongodb.conf (code=killed, signal=TERM) Main PID: 1042 (code=killed, signal=KILL) Oct 16 15:46:55 cementindustrynode5 systemd[1]: Starting mongodb... Oct 16 15:46:55 cementindustrynode5 mongod[3547030]: about to fork child process, waiting until server is ready for connections. Oct 16 15:46:55 cementindustrynode5 mongod[3547032]: forked process: 3547032 Oct 16 15:48:25 cementindustrynode5 systemd[1]: mongodb-27017.service: start operation timed out. Terminating. Oct 16 15:48:41 cementindustrynode5 systemd[1]: mongodb-27017.service: Failed with result 'timeout'. Oct 16 15:48:41 cementindustrynode5 systemd[1]: Failed to start mongodb.
从这段日志看，MongoDB 本身不一定启动失败，而是 systemd 等待 MongoDB “ready” 超时后把它杀掉了
关键点：
15:46:55 mongod about to fork child process, waiting until server is ready for connections. 15:46:55 forked process: 3547032 15:48:25 systemd start operation timed out. Terminating. 15:48:41 Failed with result 'timeout'也就是：
systemd │ │ 启动 mongod ▼ mongod 父进程 │ └── fork → 3547032 │ ├── 初始化数据目录 ├── recovery ├── journal ├── WiredTiger └── 等待 27017 ready │ │ 超过 systemd TimeoutStartSec ▼ systemd TERM ▼ MongoDB 被杀另外：
Main PID: 1042 (code=killed, signal=KILL)这个1042很值得查，说明系统中可能原本就有一个 mongod 进程/旧 MongoDB 进程，不能直接假设当前只有一个 MongoDB
1. 先不要反复 systemctl restart
先执行下面这一组，确认 MongoDB 实际状态：
ps -ef | grep '[m]ongod' ss -lntp | grep 27017 pgrep -a mongod systemctl cat mongodb-27017.service cat /mnt/allin_data/allin/mongodb-27017/mongodb.conf重点看：
dbPath logpath fork pidFilePath port bindIp2. 最重要：直接看 MongoDB 日志
先从配置里面找日志：
grep -Ei 'dbPath|path|log|fork|pid|port' \ /mnt/allin_data/allin/mongodb-27017/mongodb.conf如果是类似：
systemLog: destination: file path: /mnt/allin_data/allin/mongodb-27017/log/mongod.log直接：
tail -200 /mnt/allin_data/allin/mongodb-27017/log/mongod.log然后：
grep -Ei \ 'error|fatal|panic|fail|exception|recovery|repair|wiredtiger|lock|permission|disk|corrupt|timeout' \ /mnt/allin_data/allin/mongodb-27017/log/mongod.log | tail -100MongoDB 卡在哪里，基本都能从这里判断
3. 检查数据盘
MongoDB 路径在：
/mnt/allin_data/allin/mongodb-27017所以首先检查：
df -h /mnt/allin_data df -ih /mnt/allin_data du -sh /mnt/allin_data/allin/mongodb-27017 du -sh /mnt/allin_data/allin/mongodb-27017/*尤其注意：
磁盘空间 inode WiredTiger 文件 journal再检查：
mount | grep /mnt/allin_data findmnt /mnt/allin_data如果这是 NFS/CFS/SeaweedFS 等网络存储，要特别注意
MongoDB 的 WiredTiger 数据目录不建议放在不满足 MongoDB 存储语义要求的网络文件系统上
4. 检查磁盘 I/O
这个现象很像：
MongoDB fork 成功，但是初始化/recovery 很慢，systemd 90 秒超时
执行：
iostat -xm 1 10如果没有：
iostat安装：
yum install -y sysstat然后：
iostat -xm 1 10重点看：
%util await r_await w_await如果类似：
await 500 %util 100甚至：
await 1000+那么不是 MongoDB 配置问题，而是底层存储 I/O 卡住
5. 检查 MongoDB 进程到底有没有被 OOM Killer 干掉
执行：
dmesg -T | grep -Ei \ 'oom|out of memory|killed process|mongod'以及：
journalctl -k --since "2026-10-16 15:40:00" | \ grep -Ei 'oom|memory|killed|mongod'如果出现：
Out of memory: Killed process xxxx (mongod)那就是内存问题
再：
free -h swapon --show vmstat 1 106. 检查是不是 MongoDB recovery
这是目前比较怀疑的一种情况
MongoDB 非正常停止以后重新启动：
mongod ↓ 读取 WiredTiger metadata ↓ 检查 journal ↓ recovery ↓ 恢复 checkpoint ↓ 完成 ↓ 27017 ready如果数据库非常大，例如几百 GB / TB：
启动恢复可能超过 90 秒systemd 就会认为：
MongoDB 启动失败实际上 MongoDB 可能只是启动得比较慢
日志里如果看到：
Recovering log Recovering WiredTiger WT_SESSION recovery checkpoint journal基本可以确定
7. systemd 超时很可能只有 90 秒
从日志看：
15:46:55到：
15:48:25正好：
90 秒所以先确认：
systemctl show mongodb-27017.service | grep -E \ 'TimeoutStartSec|Type|KillMode|PIDFile'很可能：
TimeoutStartUSec=1min 30s8. 检查 systemd service
执行：
systemctl cat mongodb-27017.service重点怀疑类似：
[Service] Type=forking ExecStart=/mnt/allin_data/allin/mongodb-27017/bin/mongod \ --config /mnt/allin_data/allin/mongodb-27017/mongodb.conf TimeoutStartSec=90如果 MongoDB 配置：
processManagement: fork: true那么：
systemd ↓ mongod ↓ fork ↓ parent exit ↓ child继续启动Type=forking通常是合理的
但是如果 MongoDB 真正 ready 的时间超过 90 秒，systemd 就会干掉它
9. 可以先临时把 Timeout 调大
如果日志确认只是 recovery 慢，建议：
systemctl edit mongodb-27017.service写：
[Service] TimeoutStartSec=10min TimeoutStopSec=10min然后：
systemctl daemon-reload确认：
systemctl show mongodb-27017.service | \ grep Timeout应该看到类似：
TimeoutStartUSec=10min TimeoutStopUSec=10min然后：
systemctl start mongodb-27017.service观察：
systemctl status mongodb-27017.service同时：
tail -f /mnt/allin_data/allin/mongodb-27017/log/mongod.log10. 更关键：手工启动 MongoDB
如果仍然失败，我建议不要继续通过 systemd 猜
先停止：
systemctl stop mongodb-27017.service确认：
pgrep -a mongod如果还有：
kill <PID>等几秒：
pgrep -a mongod确认没有残留
然后用 MongoDB 原配置启动：
/mnt/allin_data/allin/mongodb-27017/bin/mongod \ --config /mnt/allin_data/allin/mongodb-27017/mongodb.conf如果配置里已经：
processManagement: fork: true那么终端可能直接返回
此时：
tail -100 \ /mnt/allin_data/allin/mongodb-27017/log/mongod.log以及：
ss -lntp | grep 2701711. 特别检查 PID 文件
日志里：
Main PID: 1042但是本次启动：
mongod[3547030] forked process: 3547032这个现象需要重点确认 PID 配置
执行：
grep -Ei 'pid|fork' \ /mnt/allin_data/allin/mongodb-27017/mongodb.conf以及：
find /mnt/allin_data/allin/mongodb-27017 -type f \ \( -name '*.pid' -o -name 'mongod.pid' \) -ls如果：
pidFilePath指向一个旧 PID 文件，而这个 PID：
1042对应其他进程，就可能造成 systemd / mongod PID 管理混乱
不要直接 rm PID 文件，先：
cat <pid文件> ps -fp 1042确认 PID 1042 到底是谁
12. 检查 27017 是否被旧 MongoDB 占用
执行：
ss -lntp | grep ':27017' lsof -nP -iTCP:27017 -sTCP:LISTEN正常应该看到：
mongod如果是：
mongod 1042说明很可能已经有一个 MongoDB
进一步：
ps -fp 1042 readlink -f /proc/1042/exe tr '\0' ' ' < /proc/1042/cmdline echo这个非常重要
可能存在：
旧 mongod 新 mongod systemd三者之间的 PID 管理问题
13. 检查 MongoDB 是否已经启动成功，只是 systemd 判断失败
直接：
/mnt/allin_data/allin/mongodb-27017/bin/mongosh \ --host 127.0.0.1 \ --port 27017 \ --eval 'db.adminCommand({ping:1})'如果版本比较老，没有mongosh：
/mnt/allin_data/allin/mongodb-27017/bin/mongo \ --host 127.0.0.1 \ --port 27017 \ --eval 'db.adminCommand({ping:1})'如果返回：
{"ok":1}说明：
MongoDB 实际是好的，是 systemd service 定义有问题
这种情况下重点修：
Type= PIDFile= TimeoutStartSec= ExecStart= fork而不是 MongoDB 数据库
14. 不建议现在执行这些操作
目前不要执行：
rm -rf WiredTiger*不要执行：
mongod --repair不要删除：
journal/更不要：
rm -rf /mnt/allin_data/allin/mongodb-27017/*因为如果是 WiredTiger recovery 问题，这些操作可能进一步破坏数据库
二、This replica set has a Primary-Secondary-Arbiter architecture, but readConcern:majority is enabled ","tags":["startupWarnings"]}
这个信息不是 MongoDB 启动失败的报错，而是一个startupWarnings（启动警告）
它的意思是：
Replica Set 是Primary + Secondary + Arbiter（PSA）架构，同时启用了
readConcern: majority
为什么 MongoDB 会警告？
架构：
Replica Set │ ┌────────────┼────────────┐ ▼ ▼ ▼ Primary Secondary Arbiter P S A │ │ │ └──────────┴──────────────┘其中：
- Primary：保存完整数据，可读写
- Secondary：保存完整数据，可提供读取/故障切换
- Arbiter：不保存数据，只参与选举投票
PSA 的核心问题是：
真正保存数据的节点 = 2 投票节点 = 3当readConcern: majority开启时，MongoDB 要考虑“多数节点已经确认”的语义
在 PSA 架构中，Arbiter不能确认数据已经写入磁盘/数据集，所以会产生这个 warning
这跟前面的启动超时有没有关系？
有可能相关，但不能仅凭这一条判断
如果MongoDB 日志是：
startupWarnings This replica set has a Primary-Secondary-Arbiter architecture, but readConcern: majority is enabled那么它本身通常不会导致 mongod 启动失败
前面的真正问题仍然是：
15:46:55 started ↓ forked ↓ 等待 MongoDB ready ↓ 15:48:25 systemd TimeoutStartSec ↓ TERM ↓ MongoDB failed所以现在应该继续找startup warning 前后真正的错误日志
建议检查 Replica Set 状态
MongoDB 启动成功后执行：
mongosh --port 27017然后：
rs.status()重点看：
PRIMARY SECONDARY ARBITER例如：
cement-mongo-01 PRIMARY cement-mongo-02 SECONDARY cement-mongo-03 ARBITER再：
rs.conf()检查 majority
执行：
db.adminCommand({ getDefaultRWConcern: 1 })可能看到：
{ "defaultReadConcern": { "level": "majority" }, "defaultWriteConcern": { "w": "majority" } }PSA + majority 的实际影响
假设：
P = Primary S = Secondary A = Arbiter正常：
P ───────── S │ │ └────── A ──┘如果 Primary 挂掉：
P ❌ S + A │ │ └───┘ ↓ S 可以选举成为 Primary这是 PSA 架构存在的主要意义
但是如果：
P 正常 S ❌ A 正常那么：
P = 唯一的数据节点 S = offline A = 只有投票能力这时候majority相关读写行为就可能受到影响
架构更建议
如果这是生产 MongoDB，最好：
MongoDB 3 Data Nodes ┌───────────────┐ │ Replica Set │ └───────┬───────┘ │ ┌───────┼───────┐ ▼ ▼ ▼ P S S也就是：
Primary Secondary Secondary而不是：
Primary Secondary Arbiter因为：
P + S + S三个节点都是真正的数据副本
而：
P + S + A实际上只有两个数据副本
如果暂时必须使用 PSA
不建议因为这个 warning 就直接关闭readConcern: majority
先确认：
rs.status()和：
db.adminCommand({ getDefaultRWConcern: 1 })然后查看：
grep -Ei \ 'majority|rollback|recovery|WiredTiger|error|fatal|exception|failed' \ /mnt/allin_data/allin/mongodb-27017/log/mongod.log | tail -100特别是现在这个启动超时问题
建议查看MongoDB 日志中这条 warning 前后约 100～200 行
因为如果同时看到类似：
Recovering WiredTiger Recovering log rollback No space left on device WiredTiger error Failed to start waiting for connections就可以直接定位到底是：
① PSA warning
还是
② WiredTiger recovery 慢
还是
③ Replica Set 初始化/连接异常
还是
④ 磁盘 I/O 导致 systemd 90 秒超时
目前这条Primary-Secondary-Arbiter + readConcern:majority更像是伴随性的启动警告，不是前面Result: timeout的直接原因
三、error log
{"t":{"$date":"2026-10-16T15:48:30.367+08:00"},"s":"I", "c":"REPL", "id":4280506, "ctx":"initandlisten","msg":"Reconstructing prepared transactions"} {"t":{"$date":"2026-10-16T15:48:30.368+08:00"},"s":"I", "c":"REPL", "id":4280507, "ctx":"initandlisten","msg":"Loaded replica set config, scheduled callback to set local config"} {"t":{"$date":"2026-10-16T15:48:30.368+08:00"},"s":"I", "c":"REPL", "id":4280508, "ctx":"ReplCoord-0","msg":"Attempting to set local replica set config; validating config for startup"} {"t":{"$date":"2026-10-16T15:48:30.369+08:00"},"s":"I", "c":"REPL", "id":21315, "ctx":"ReplCoord-0","msg":"","tags":["startupWarnings"]} {"t":{"$date":"2026-10-16T15:48:30.369+08:00"},"s":"I", "c":"REPL", "id":21316, "ctx":"ReplCoord-0","msg":"** WARNING: This replica set has a Primary-Secondary-Arbiter architecture, but readConcern:majority is enabled ","tags":["startupWarnings"]} {"t":{"$date":"2026-10-16T15:48:30.369+08:00"},"s":"I", "c":"REPL", "id":21317, "ctx":"ReplCoord-0","msg":"** for this node. This is not a recommended configuration. Please see ","tags":["startupWarnings"]} {"t":{"$date":"2026-10-16T15:48:30.369+08:00"},"s":"I", "c":"REPL", "id":21318, "ctx":"ReplCoord-0","msg":"** https://dochub.mongodb.org/core/psa-disable-rc-majority","tags":["startupWarnings"]} {"t":{"$date":"2026-10-16T15:48:30.369+08:00"},"s":"I", "c":"REPL", "id":21319, "ctx":"ReplCoord-0","msg":"","tags":["startupWarnings"]} {"t":{"$date":"2026-10-16T15:48:30.369+08:00"},"s":"I", "c":"REPL", "id":4280509, "ctx":"ReplCoord-0","msg":"Local configuration validated for startup"} {"t":{"$date":"2026-10-16T15:48:30.369+08:00"},"s":"W", "c":"STORAGE", "id":4747501, "ctx":"initandlisten","msg":"Not starting periodic jobs as shutdown is in progress"} {"t":{"$date":"2026-10-16T15:48:30.369+08:00"},"s":"I", "c":"REPL", "id":6015317, "ctx":"ReplCoord-0","msg":"Setting new configuration state","attr":{"newState":"ConfigSteady","oldState":"ConfigStartingUp"}} {"t":{"$date":"2026-10-16T15:48:30.369+08:00"},"s":"I", "c":"REPL", "id":21392, "ctx":"ReplCoord-0","msg":"New replica set config in use","attr":{"config":{"_id":"mongo_repl","version":1,"term":61,"protocolVersion":1,"writeConcernMajorityJournalDefault":true,"members":[{"_id":0,"host":"cementindustrynode4:27017","arbiterOnly":false,"buildIndexes":true,"hidden":false,"priority":2.0,"tags":{},"slaveDelay":0,"votes":1},{"_id":1,"host":"cementindustrynode5:27017","arbiterOnly":false,"buildIndexes":true,"hidden":false,"priority":1.0,"tags":{},"slaveDelay":0,"votes":1},{"_id":2,"host":"cementindustrynode6:27017","arbiterOnly":true,"buildIndexes":true,"hidden":false,"priority":0.0,"tags":{},"slaveDelay":0,"votes":1}],"settings":{"chainingAllowed":true,"heartbeatIntervalMillis":2000,"heartbeatTimeoutSecs":10,"electionTimeoutMillis":10000,"catchUpTimeoutMillis":-1,"catchUpTakeoverDelayMillis":30000,"getLastErrorModes":{},"getLastErrorDefaults":{"w":1,"wtimeout":0},"replicaSetId":{"$oid":"66d1bb28aaf5b30dce579681"}}}}} {"t":{"$date":"2026-10-16T15:48:30.369+08:00"},"s":"I", "c":"REPL", "id":21393, "ctx":"ReplCoord-0","msg":"Found self in config","attr":{"hostAndPort":"cementindustrynode5:27017"}} {"t":{"$date":"2026-10-16T15:48:30.369+08:00"},"s":"I", "c":"REPL", "id":21358, "ctx":"ReplCoord-0","msg":"Replica set state transition","attr":{"newState":"STARTUP2","oldState":"STARTUP"}}
日志非常关键。现在基本可以确定：MongoDB 的 Replica Set 配置加载成功了，PSA warning 不是启动失败原因。真正的问题是 systemd 在 MongoDB 完成启动前把它终止了
从日志可以确定的事情
节点是：
cementindustrynode5:27017Replica Set：
mongo_repl架构：
cementindustrynode4 PRIMARY候选 priority=2 cementindustrynode5 SECONDARY priority=1 cementindustrynode6 ARBITER priority=0也就是：
mongo_repl │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ node4:27017 node5:27017 node6:27017 priority=2 priority=1 arbiter DATA DATA NO DATA P S A关键时间线
日志：
15:48:30.367 Reconstructing prepared transactions 15:48:30.368 Loaded replica set config 15:48:30.369 Local configuration validated for startup 15:48:30.369 New replica set config in use 15:48:30.369 Found self in config 15:48:30.369 Replica set state transition newState: STARTUP2这说明：
MongoDB 已经成功读取数据目录、加载 Replica Set 配置，并识别自己是cementindustrynode5
但是：
Not starting periodic jobs as shutdown is in progress这个才是非常重要的一句
它说明：
MongoDB 收到了 shutdown 信号
结合之前 systemd：
15:48:25 systemd[1]: mongodb-27017.service: start operation timed out. Terminating.可以把因果关系串起来：
15:46:55 systemd 启动 mongod │ ▼ fork 3547032 │ ▼ MongoDB 开始恢复/初始化 │ ├── Reconstructing prepared transactions ├── 加载 Replica Set ├── 验证 Replica Set └── 进入 STARTUP2 │ ▼ 15:48:25 systemd 等待 90 秒超时 │ ▼ systemd 发送 TERM │ ▼ MongoDB 开始 shutdown │ ▼ 15:48:30 Not starting periodic jobs as shutdown is in progress所以现在结论非常明确：
systemd TimeoutStartSec 太短，是当前最直接的问题
1. 先修改 systemd 超时时间
执行：
systemctl edit mongodb-27017.service增加：
[Service] TimeoutStartSec=10min TimeoutStopSec=10min保存后：
systemctl daemon-reload确认：
systemctl show mongodb-27017.service | grep -E 'TimeoutStart|TimeoutStop'应该类似：
TimeoutStartUSec=10min TimeoutStopUSec=10min然后：
systemctl start mongodb-27017.service2. 不要马上判断“启动成功”
启动后立即观察：
systemctl status mongodb-27017.service同时：
tail -f /mnt/allin_data/allin/mongodb-27017/log/mongod.log重点等待：
waiting for connections或者类似：
Listening on Waiting for connections3. MongoDB 目前已经进入 STARTUP2
这一点很重要：
newState":"STARTUP2"说明它不是卡在：
Replica Set config也不是：
Found self而是已经进入 Replica Set 启动阶段
MongoDB Replica Set 节点通常：
STARTUP ↓ STARTUP2 ↓ RECOVERING ↓ SECONDARY或者最终：
STARTUP2 ↓ PRIMARY取决于选举状态
4. PSA warning 暂时不用管
这几行：
WARNING: This replica set has a Primary-Secondary-Arbiter architecture, but readConcern:majority is enabled只是警告。
你的配置：
"writeConcernMajorityJournalDefault": true而且：
"getLastErrorDefaults": { "w": 1, "wtimeout": 0 }这里其实还有一个值得注意的点：
默认 write concern 是w:1，并不是w:majority。
所以目前这条 PSA warning 不会解释你此次systemd timeout
5. 但生产环境建议解决 PSA
你现在：
node4 DATA node5 DATA node6 ARBITER建议以后改成：
node4 DATA node5 DATA node6 DATA即：
Primary Secondary Secondary比：
Primary Secondary Arbiter可靠很多
尤其这个 MongoDB 看起来是重要业务库，不建议长期 PSA
6. 现在还需要确认 STARTUP2 为什么这么慢
虽然 systemd timeout 已经基本定位，但还应该知道为什么启动超过 90 秒
日志中：
Reconstructing prepared transactions说明启动过程中正在处理事务恢复
因此建议继续搜索：
grep -Ei \ 'recover|recovery|WiredTiger|checkpoint|journal|prepared|rollback|startup2|secondary|sync' \ /mnt/allin_data/allin/mongodb-27017/log/mongod.log | tail -200再执行：
du -sh /mnt/allin_data/allin/mongodb-27017 du -sh /mnt/allin_data/allin/mongodb-27017/journal以及：
df -h /mnt/allin_data df -ih /mnt/allin_data7. 强烈建议检查磁盘 I/O
如果 MongoDB 数据量比较大，真正的问题可能是：
MongoDB recovery ↓ WiredTiger ↓ 磁盘 I/O 很慢 ↓ 启动 > 90 秒 ↓ systemd kill执行：
iostat -xm 1 10重点看：
await %util r_await w_await如果看到：
await 500ms+ %util 100%或者更严重：
await 1000ms+那么需要进一步查底层存储
8. 启动后检查 Replica Set
MongoDB 成功启动以后：
mongosh --host 127.0.0.1 --port 27017然后：
rs.status()重点看 node5：
name: "cementindustrynode5:27017" stateStr: "SECONDARY"如果 node4 当前是 Primary：
cementindustrynode4 PRIMARY cementindustrynode5 SECONDARY cementindustrynode6 ARBITER这是正常的
也可以：
rs.printSecondaryReplicationInfo()检查 node5 是否存在同步延迟
9. 建议直接操作
第一步
systemctl edit mongodb-27017.service加入：
[Service] TimeoutStartSec=10min TimeoutStopSec=10min然后：
systemctl daemon-reload systemctl start mongodb-27017.service第二步
另开一个窗口：
tail -f /mnt/allin_data/allin/mongodb-27017/log/mongod.log第三步
如果超过几分钟仍然没有：
waiting for connections马上执行：
grep -Ei \ 'error|fatal|panic|exception|recover|recovery|WiredTiger|rollback|sync|oplog|startup2' \ /mnt/allin_data/allin/mongodb-27017/log/mongod.log | tail -200以及：
iostat -xm 1 10当前判断
| 项目 | 判断 |
|---|---|
| MongoDB 二进制 | ✅ 能启动 |
| 数据目录 | ✅ 能读取 |
| Replica Set 配置 | ✅ 正常 |
| 找到自身节点 | ✅ 正常 |
| Replica Set | mongo_repl |
| node5 状态 | STARTUP2 |
| PSA warning | ⚠️ 非致命 |
| MongoDB 主体启动 | ⚠️ 超过 90 秒 |
| systemd | ❌TimeoutStartSec=90s |
shutdown is in progress | systemd 超时后触发 |
| 当前最优先处理 | 把 TimeoutStartSec 调大 |
所以暂时不要做--repair、删除WiredTiger*、删除 journal 等危险操作。日志证明 MongoDB 正在正常走启动流程，只是被 systemd 的 90 秒启动超时提前杀掉了
