Recover a mongo database deleted by rmRecover deleted recordsMysql trying to recover from Hard disk...
How do I implement a file system driver driver in Linux?
Can I use my Chinese passport to enter China after I acquired another citizenship?
Wrapping Cryptocurrencies for interoperability sake
Do Legal Documents Require Signing In Standard Pen Colors?
Has Darkwing Duck ever met Scrooge McDuck?
Reply 'no position' while the job posting is still there
Why do IPv6 unique local addresses have to have a /48 prefix?
Greco-Roman egalitarianism
Did US corporations pay demonstrators in the German demonstrations against article 13?
We have a love-hate relationship
THT: What is a squared annular “ring”?
Is possible to search in vim history?
What is the grammatical term for “‑ed” words like these?
Proof of Lemma: Every nonzero integer can be written as a product of primes
Why has "pence" been used in this sentence, not "pences"?
What linear sensor for a keyboard?
How much character growth crosses the line into breaking the character
Why does Async/Await work properly when the loop is inside the async function and not the other way around?
What's the difference between 違法 and 不法?
Constructing Group Divisible Designs - Algorithms?
Do the concepts of IP address and network interface not belong to the same layer?
Is a model fitted to data or is data fitted to a model?
A social experiment. What is the worst that can happen?
What major Native American tribes were around Santa Fe during the late 1850s?
Recover a mongo database deleted by rm
Recover deleted recordsMysql trying to recover from Hard disk failureRecover deleted table from the databaseMongo repairDatabase procedureWhen upgrading config servers to use WireTiger, the running config server with wiredtiger does not authenticate the existing pass and user?'mongod wiredTiger' on Ubuntu?Issues in starting MongoDB servicecreating replica set between three similar mongo databases on my localReplica Set Question - one primary instance with two secondary instancesHow to Recover Mongodb database
My developer accidentally lost our database by a bash script, which turned out to run rm -rf /*
(see this thread). Thanks to extundelete, he just recovered the /data/db/
folder:
However, he could not successfully load the database in Robo 3T; it looks quite empty here:
Here is the result of running mongod --port 27017 --dbpath /data/db --bind_ip_all
:
root@iZj6c0pipuxk17pb7pbaw0Z:/data# mongod --port 27017 --dbpath /data/db --bind_ip_all
2019-03-25T10:27:55.565+0800 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] MongoDB starting : pid=7882 port=27017 dbpath=/data/db 64-bit host=iZj6c0pipuxk17pb7pbaw0Z
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] db version v4.0.7
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] git version: 1b82c812a9c0bbf6dc79d5400de9ea99e6ffa025
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] allocator: tcmalloc
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] modules: none
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] build environment:
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distmod: ubuntu1604
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distarch: x86_64
2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] target_arch: x86_64
2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] options: { net: { bindIpAll: true, port: 27017 }, storage: { dbPath: "/data/db" } }
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten]
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=256M,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),statistics_log=(wait=0),verbose=(recovery_progress),
2019-03-25T10:27:56.352+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:352123][7882:0x7fa21bb8fa40], txn-recover: Main recovery loop: starting at 5/20480 to 6/256
2019-03-25T10:27:56.467+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:467455][7882:0x7fa21bb8fa40], txn-recover: Recovering log 5 through 6
2019-03-25T10:27:56.538+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:538476][7882:0x7fa21bb8fa40], txn-recover: Recovering log 6 through 6
2019-03-25T10:27:56.595+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:595900][7882:0x7fa21bb8fa40], txn-recover: Set global recovery timestamp: 0
2019-03-25T10:27:56.627+0800 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: soft rlimits too low. rlimits set to 3824 processes, 65535 files. Number of processes should be at least 32767.5 : 0.5 times number of files.
2019-03-25T10:27:56.647+0800 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
2019-03-25T10:27:56.648+0800 I NETWORK [initandlisten] waiting for connections on port 27017
2019-03-25T10:27:59.725+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11181 #1 (1 connection now open)
2019-03-25T10:27:59.727+0800 I NETWORK [conn1] received client metadata from 221.8.173.30:11181 conn1: { application: { name: "robo3t" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }
2019-03-25T10:27:59.950+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11182 #2 (2 connections now open)
2019-03-25T10:27:59.952+0800 I NETWORK [conn2] received client metadata from 221.8.173.30:11182 conn2: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }
Does anyone understand what's happening? does anyone know how to recover this mongodb?
mongodb recovery disaster-recovery mongo-repair
add a comment |
My developer accidentally lost our database by a bash script, which turned out to run rm -rf /*
(see this thread). Thanks to extundelete, he just recovered the /data/db/
folder:
However, he could not successfully load the database in Robo 3T; it looks quite empty here:
Here is the result of running mongod --port 27017 --dbpath /data/db --bind_ip_all
:
root@iZj6c0pipuxk17pb7pbaw0Z:/data# mongod --port 27017 --dbpath /data/db --bind_ip_all
2019-03-25T10:27:55.565+0800 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] MongoDB starting : pid=7882 port=27017 dbpath=/data/db 64-bit host=iZj6c0pipuxk17pb7pbaw0Z
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] db version v4.0.7
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] git version: 1b82c812a9c0bbf6dc79d5400de9ea99e6ffa025
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] allocator: tcmalloc
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] modules: none
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] build environment:
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distmod: ubuntu1604
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distarch: x86_64
2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] target_arch: x86_64
2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] options: { net: { bindIpAll: true, port: 27017 }, storage: { dbPath: "/data/db" } }
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten]
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=256M,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),statistics_log=(wait=0),verbose=(recovery_progress),
2019-03-25T10:27:56.352+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:352123][7882:0x7fa21bb8fa40], txn-recover: Main recovery loop: starting at 5/20480 to 6/256
2019-03-25T10:27:56.467+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:467455][7882:0x7fa21bb8fa40], txn-recover: Recovering log 5 through 6
2019-03-25T10:27:56.538+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:538476][7882:0x7fa21bb8fa40], txn-recover: Recovering log 6 through 6
2019-03-25T10:27:56.595+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:595900][7882:0x7fa21bb8fa40], txn-recover: Set global recovery timestamp: 0
2019-03-25T10:27:56.627+0800 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: soft rlimits too low. rlimits set to 3824 processes, 65535 files. Number of processes should be at least 32767.5 : 0.5 times number of files.
2019-03-25T10:27:56.647+0800 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
2019-03-25T10:27:56.648+0800 I NETWORK [initandlisten] waiting for connections on port 27017
2019-03-25T10:27:59.725+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11181 #1 (1 connection now open)
2019-03-25T10:27:59.727+0800 I NETWORK [conn1] received client metadata from 221.8.173.30:11181 conn1: { application: { name: "robo3t" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }
2019-03-25T10:27:59.950+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11182 #2 (2 connections now open)
2019-03-25T10:27:59.952+0800 I NETWORK [conn2] received client metadata from 221.8.173.30:11182 conn2: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }
Does anyone understand what's happening? does anyone know how to recover this mongodb?
mongodb recovery disaster-recovery mongo-repair
add a comment |
My developer accidentally lost our database by a bash script, which turned out to run rm -rf /*
(see this thread). Thanks to extundelete, he just recovered the /data/db/
folder:
However, he could not successfully load the database in Robo 3T; it looks quite empty here:
Here is the result of running mongod --port 27017 --dbpath /data/db --bind_ip_all
:
root@iZj6c0pipuxk17pb7pbaw0Z:/data# mongod --port 27017 --dbpath /data/db --bind_ip_all
2019-03-25T10:27:55.565+0800 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] MongoDB starting : pid=7882 port=27017 dbpath=/data/db 64-bit host=iZj6c0pipuxk17pb7pbaw0Z
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] db version v4.0.7
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] git version: 1b82c812a9c0bbf6dc79d5400de9ea99e6ffa025
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] allocator: tcmalloc
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] modules: none
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] build environment:
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distmod: ubuntu1604
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distarch: x86_64
2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] target_arch: x86_64
2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] options: { net: { bindIpAll: true, port: 27017 }, storage: { dbPath: "/data/db" } }
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten]
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=256M,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),statistics_log=(wait=0),verbose=(recovery_progress),
2019-03-25T10:27:56.352+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:352123][7882:0x7fa21bb8fa40], txn-recover: Main recovery loop: starting at 5/20480 to 6/256
2019-03-25T10:27:56.467+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:467455][7882:0x7fa21bb8fa40], txn-recover: Recovering log 5 through 6
2019-03-25T10:27:56.538+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:538476][7882:0x7fa21bb8fa40], txn-recover: Recovering log 6 through 6
2019-03-25T10:27:56.595+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:595900][7882:0x7fa21bb8fa40], txn-recover: Set global recovery timestamp: 0
2019-03-25T10:27:56.627+0800 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: soft rlimits too low. rlimits set to 3824 processes, 65535 files. Number of processes should be at least 32767.5 : 0.5 times number of files.
2019-03-25T10:27:56.647+0800 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
2019-03-25T10:27:56.648+0800 I NETWORK [initandlisten] waiting for connections on port 27017
2019-03-25T10:27:59.725+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11181 #1 (1 connection now open)
2019-03-25T10:27:59.727+0800 I NETWORK [conn1] received client metadata from 221.8.173.30:11181 conn1: { application: { name: "robo3t" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }
2019-03-25T10:27:59.950+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11182 #2 (2 connections now open)
2019-03-25T10:27:59.952+0800 I NETWORK [conn2] received client metadata from 221.8.173.30:11182 conn2: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }
Does anyone understand what's happening? does anyone know how to recover this mongodb?
mongodb recovery disaster-recovery mongo-repair
My developer accidentally lost our database by a bash script, which turned out to run rm -rf /*
(see this thread). Thanks to extundelete, he just recovered the /data/db/
folder:
However, he could not successfully load the database in Robo 3T; it looks quite empty here:
Here is the result of running mongod --port 27017 --dbpath /data/db --bind_ip_all
:
root@iZj6c0pipuxk17pb7pbaw0Z:/data# mongod --port 27017 --dbpath /data/db --bind_ip_all
2019-03-25T10:27:55.565+0800 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] MongoDB starting : pid=7882 port=27017 dbpath=/data/db 64-bit host=iZj6c0pipuxk17pb7pbaw0Z
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] db version v4.0.7
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] git version: 1b82c812a9c0bbf6dc79d5400de9ea99e6ffa025
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] allocator: tcmalloc
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] modules: none
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] build environment:
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distmod: ubuntu1604
2019-03-25T10:27:55.569+0800 I CONTROL [initandlisten] distarch: x86_64
2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] target_arch: x86_64
2019-03-25T10:27:55.570+0800 I CONTROL [initandlisten] options: { net: { bindIpAll: true, port: 27017 }, storage: { dbPath: "/data/db" } }
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten]
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2019-03-25T10:27:55.570+0800 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=256M,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),statistics_log=(wait=0),verbose=(recovery_progress),
2019-03-25T10:27:56.352+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:352123][7882:0x7fa21bb8fa40], txn-recover: Main recovery loop: starting at 5/20480 to 6/256
2019-03-25T10:27:56.467+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:467455][7882:0x7fa21bb8fa40], txn-recover: Recovering log 5 through 6
2019-03-25T10:27:56.538+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:538476][7882:0x7fa21bb8fa40], txn-recover: Recovering log 6 through 6
2019-03-25T10:27:56.595+0800 I STORAGE [initandlisten] WiredTiger message [1553480876:595900][7882:0x7fa21bb8fa40], txn-recover: Set global recovery timestamp: 0
2019-03-25T10:27:56.627+0800 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten]
2019-03-25T10:27:56.635+0800 I CONTROL [initandlisten] ** WARNING: soft rlimits too low. rlimits set to 3824 processes, 65535 files. Number of processes should be at least 32767.5 : 0.5 times number of files.
2019-03-25T10:27:56.647+0800 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
2019-03-25T10:27:56.648+0800 I NETWORK [initandlisten] waiting for connections on port 27017
2019-03-25T10:27:59.725+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11181 #1 (1 connection now open)
2019-03-25T10:27:59.727+0800 I NETWORK [conn1] received client metadata from 221.8.173.30:11181 conn1: { application: { name: "robo3t" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }
2019-03-25T10:27:59.950+0800 I NETWORK [listener] connection accepted from 221.8.173.30:11182 #2 (2 connections now open)
2019-03-25T10:27:59.952+0800 I NETWORK [conn2] received client metadata from 221.8.173.30:11182 conn2: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "3.4.3-10-g865d2fb" }, os: { type: "Windows", name: "Microsoft Windows 8", architecture: "x86_64", version: "6.2 (build 9200)" } }
Does anyone understand what's happening? does anyone know how to recover this mongodb?
mongodb recovery disaster-recovery mongo-repair
mongodb recovery disaster-recovery mongo-repair
asked 7 mins ago
SoftTimurSoftTimur
1113
1113
add a comment |
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f232972%2frecover-a-mongo-database-deleted-by-rm%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f232972%2frecover-a-mongo-database-deleted-by-rm%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown