一、mongodb systemd failed[rootcementindustrynode5 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 (codekilled, signalTERM) Main PID: 1042 (codekilled, signalKILL) 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 (codekilled, signalKILL)这个1042很值得查说明系统中可能原本就有一个 mongod 进程/旧 MongoDB 进程不能直接假设当前只有一个 MongoDB1. 先不要反复 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很可能TimeoutStartUSec1min 30s8. 检查 systemd service执行systemctl cat mongodb-27017.service重点怀疑类似[Service] Typeforking ExecStart/mnt/allin_data/allin/mongodb-27017/bin/mongod \ --config /mnt/allin_data/allin/mongodb-27017/mongodb.conf TimeoutStartSec90如果 MongoDB 配置processManagement: fork: true那么systemd ↓ mongod ↓ fork ↓ parent exit ↓ child继续启动Typeforking通常是合理的但是如果 MongoDB 真正 ready 的时间超过 90 秒systemd 就会干掉它9. 可以先临时把 Timeout 调大如果日志确认只是 recovery 慢建议systemctl edit mongodb-27017.service写[Service] TimeoutStartSec10min TimeoutStopSec10min然后systemctl daemon-reload确认systemctl show mongodb-27017.service | \ grep Timeout应该看到类似TimeoutStartUSec10min TimeoutStopUSec10min然后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 文件而这个 PID1042对应其他进程就可能造成 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 ArbiterPSA架构同时启用了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 前后约 100200 行因为如果同时看到类似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.36708:00},s:I, c:REPL, id:4280506, ctx:initandlisten,msg:Reconstructing prepared transactions} {t:{$date:2026-10-16T15:48:30.36808: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.36808: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.36908:00},s:I, c:REPL, id:21315, ctx:ReplCoord-0,msg:,tags:[startupWarnings]} {t:{$date:2026-10-16T15:48:30.36908: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.36908: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.36908: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.36908:00},s:I, c:REPL, id:21319, ctx:ReplCoord-0,msg:,tags:[startupWarnings]} {t:{$date:2026-10-16T15:48:30.36908:00},s:I, c:REPL, id:4280509, ctx:ReplCoord-0,msg:Local configuration validated for startup} {t:{$date:2026-10-16T15:48:30.36908: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.36908: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.36908: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.36908: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.36908: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 Setmongo_repl架构cementindustrynode4 PRIMARY候选 priority2 cementindustrynode5 SECONDARY priority1 cementindustrynode6 ARBITER priority0也就是mongo_repl │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ node4:27017 node5:27017 node6:27017 priority2 priority1 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 信号结合之前 systemd15: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] TimeoutStartSec10min TimeoutStopSec10min保存后systemctl daemon-reload确认systemctl show mongodb-27017.service | grep -E TimeoutStart|TimeoutStop应该类似TimeoutStartUSec10min TimeoutStopUSec10min然后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 timeout5. 但生产环境建议解决 PSA你现在node4 DATA node5 DATA node6 ARBITER建议以后改成node4 DATA node5 DATA node6 DATA即Primary Secondary Secondary比Primary Secondary Arbiter可靠很多尤其这个 MongoDB 看起来是重要业务库不建议长期 PSA6. 现在还需要确认 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 SetMongoDB 成功启动以后mongosh --host 127.0.0.1 --port 27017然后rs.status()重点看 node5name: cementindustrynode5:27017 stateStr: SECONDARY如果 node4 当前是 Primarycementindustrynode4 PRIMARY cementindustrynode5 SECONDARY cementindustrynode6 ARBITER这是正常的也可以rs.printSecondaryReplicationInfo()检查 node5 是否存在同步延迟9. 建议直接操作第一步systemctl edit mongodb-27017.service加入[Service] TimeoutStartSec10min TimeoutStopSec10min然后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 Setmongo_replnode5 状态STARTUP2PSA warning⚠️ 非致命MongoDB 主体启动⚠️ 超过 90 秒systemd❌TimeoutStartSec90sshutdown is in progresssystemd 超时后触发当前最优先处理把 TimeoutStartSec 调大所以暂时不要做--repair、删除WiredTiger*、删除 journal 等危险操作。日志证明 MongoDB 正在正常走启动流程只是被 systemd 的 90 秒启动超时提前杀掉了
