community-catalog
community-catalog copied to clipboard
MongoDb does not shutdown gracefully
MongoDB does not shutdown gracefully and should have "trap" in the script to propagate signals properly to mongod process. Currently after the restart there is a recovery session. Log history:
2018-02-05T17:44:12.083+0000 W - [initandlisten] Detected unclean shutdown - /data/db/mongod.lock is not empty. 2018-02-05T17:44:12.088+0000 I - [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'. 2018-02-05T17:44:12.088+0000 W STORAGE [initandlisten] Recovering data from the last clean checkpoint. 2018-02-05T17:44:12.088+0000 I STORAGE [initandlisten] 2018-02-05T17:44:12.088+0000 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine 2018-02-05T17:44:12.088+0000 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem 2018-02-05T17:44:12.088+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=15559M,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),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0),verbose=(recovery_progress), 2018-02-05T17:44:12.235+0000 I STORAGE [initandlisten] WiredTiger message [1517852652:235137][19:0x7f36514c2d40], txn-recover: Main recovery loop: starting at 5/269312 2018-02-05T17:44:12.235+0000 I STORAGE [initandlisten] WiredTiger message [1517852652:235448][19:0x7f36514c2d40], txn-recover: Recovering log 5 through 6 2018-02-05T17:44:12.299+0000 I STORAGE [initandlisten] WiredTiger message [1517852652:299916][19:0x7f36514c2d40], file:sizeStorer.wt, txn-recover: Recovering log 6 through 6 2018-02-05T17:44:12.395+0000 I STORAGE [initandlisten] Starting WiredTigerRecordStoreThread local.oplog.rs 2018-02-05T17:44:12.395+0000 I STORAGE [initandlisten] The size storer reports that the oplog contains 723 records totaling to 70328 bytes 2018-02-05T17:44:12.395+0000 I STORAGE [initandlisten] Scanning the oplog to determine where to place markers for truncation