Восстановите mongoDB с помощью --repair и WiredTiger
Мы случайно удалили каталог rm -rf /data/db который был нашим MongoDB путь, и благодаря вытеснить, мы восстановили его и получили каталог /data/db.
Вот наши файлы в каталоге, и файлы были созданы под MongoDB версия 3.4.
Папка diagnostic.data:
Папка journal:
Шаг 1: попробуйте запустить mongod как обычно
а) Мы бежали mongod --port 27017 --dbpath /data/db --bind_ip_all и mongo, и ожидается, что там должна быть пользовательская база данных wecaXX, Но этого не произошло.
> show dbs
admin 0.000GB
config 0.000GB
local 0.000GB
В Robo3T
б) Затем я попытался бежать mongod --port 27017 --dbpath /data/db --bind_ip_all --repair. Результат был:
2019-03-25T14:10:02.170+0800 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-03-25T14:10:02.191+0800 I CONTROL [initandlisten] MongoDB starting : pid=23018 port=27017 dbpath=/data/db 64-bit host=iZj6c0pipuxk17pb7pbaw0Z
2019-03-25T14:10:02.191+0800 I CONTROL [initandlisten] db version v4.0.7
2019-03-25T14:10:02.191+0800 I CONTROL [initandlisten] git version: 1b82c812a9c0bbf6dc79d5400de9ea99e6ffa025
2019-03-25T14:10:02.191+0800 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
2019-03-25T14:10:02.191+0800 I CONTROL [initandlisten] allocator: tcmalloc
2019-03-25T14:10:02.191+0800 I CONTROL [initandlisten] modules: none
2019-03-25T14:10:02.191+0800 I CONTROL [initandlisten] build environment:
2019-03-25T14:10:02.191+0800 I CONTROL [initandlisten] distmod: ubuntu1604
2019-03-25T14:10:02.191+0800 I CONTROL [initandlisten] distarch: x86_64
2019-03-25T14:10:02.191+0800 I CONTROL [initandlisten] target_arch: x86_64
2019-03-25T14:10:02.191+0800 I CONTROL [initandlisten] options: { net: { bindIpAll: true, port: 27017 }, repair: true, storage: { dbPath: "/data/db" } }
2019-03-25T14:10:02.191+0800 W STORAGE [initandlisten] Detected unclean shutdown - /data/db/mongod.lock is not empty.
2019-03-25T14:10:02.194+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-25T14:10:02.194+0800 W STORAGE [initandlisten] Recovering data from the last clean checkpoint.
2019-03-25T14:10:02.194+0800 I STORAGE [initandlisten]
2019-03-25T14:10:02.194+0800 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2019-03-25T14:10:02.194+0800 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2019-03-25T14:10:02.194+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-25T14:10:02.818+0800 E STORAGE [initandlisten] WiredTiger error (17) [1553494202:818725][23018:0x7f6119074a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: File exists Raw: [1553494202:818725][23018:0x7f6119074a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: File exists
2019-03-25T14:10:02.818+0800 I STORAGE [initandlisten] WiredTiger message unexpected file WiredTiger.wt found, renamed to WiredTiger.wt.1
2019-03-25T14:10:03.832+0800 I STORAGE [initandlisten] WiredTiger message [1553494203:832267][23018:0x7f6119074a40], txn-recover: Main recovery loop: starting at 4/11366912 to 5/256
2019-03-25T14:10:03.832+0800 I STORAGE [initandlisten] WiredTiger message [1553494203:832674][23018:0x7f6119074a40], txn-recover: Recovering log 4 through 5
2019-03-25T14:10:03.898+0800 I STORAGE [initandlisten] WiredTiger message [1553494203:898252][23018:0x7f6119074a40], txn-recover: Recovering log 5 through 5
2019-03-25T14:10:03.964+0800 I STORAGE [initandlisten] WiredTiger message [1553494203:964880][23018:0x7f6119074a40], txn-recover: Set global recovery timestamp: 0
2019-03-25T14:10:03.998+0800 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2019-03-25T14:10:03.999+0800 E STORAGE [initandlisten] WiredTiger error (17) [1553494203:999855][23018:0x7f6119074a40], WT_SESSION.create: __posix_open_file, 715: /data/db/_mdb_catalog.wt: handle-open: open: File exists Raw: [1553494203:999855][23018:0x7f6119074a40], WT_SESSION.create: __posix_open_file, 715: /data/db/_mdb_catalog.wt: handle-open: open: File exists
2019-03-25T14:10:04.000+0800 I STORAGE [initandlisten] WiredTiger message unexpected file _mdb_catalog.wt found, renamed to _mdb_catalog.wt.1
2019-03-25T14:10:04.015+0800 I CONTROL [initandlisten]
2019-03-25T14:10:04.015+0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-03-25T14:10:04.015+0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2019-03-25T14:10:04.015+0800 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
2019-03-25T14:10:04.015+0800 I CONTROL [initandlisten]
2019-03-25T14:10:04.015+0800 I CONTROL [initandlisten]
2019-03-25T14:10:04.015+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-25T14:10:04.020+0800 I STORAGE [initandlisten] createCollection: admin.system.version with provided UUID: 47d8713d-ac61-4081-83bf-60209ad60a7d
2019-03-25T14:10:04.034+0800 W ASIO [initandlisten] No TransportLayer configured during NetworkInterface startup
2019-03-25T14:10:04.036+0800 I COMMAND [initandlisten] setting featureCompatibilityVersion to 4.0
2019-03-25T14:10:04.036+0800 I STORAGE [initandlisten] repairDatabase admin
2019-03-25T14:10:04.037+0800 I STORAGE [initandlisten] Repairing collection admin.system.version
2019-03-25T14:10:04.040+0800 I STORAGE [initandlisten] Verify succeeded on uri table:collection-0-4352287918877967674. Not salvaging.
2019-03-25T14:10:04.048+0800 I INDEX [initandlisten] build index on: admin.system.version properties: { v: 2, key: { _id: 1 }, name: "_id_", ns: "admin.system.version" }
2019-03-25T14:10:04.048+0800 I INDEX [initandlisten] building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2019-03-25T14:10:04.055+0800 I STORAGE [initandlisten] finished checking dbs
2019-03-25T14:10:04.055+0800 I STORAGE [initandlisten] WiredTigerKVEngine shutting down
2019-03-25T14:10:04.056+0800 I STORAGE [initandlisten] Shutting down session sweeper thread
2019-03-25T14:10:04.057+0800 I STORAGE [initandlisten] Finished shutting down session sweeper thread
2019-03-25T14:10:04.140+0800 I STORAGE [initandlisten] shutdown: removing fs lock...
2019-03-25T14:10:04.140+0800 I CONTROL [initandlisten] now exiting
2019-03-25T14:10:04.140+0800 I CONTROL [initandlisten] shutting down with code:0
в) После ремонта повторно запустил mongod --port 27017 --dbpath /data/db --bind_ip_all, это все еще показывало ничего (тот же результат, что и на шаге а)).
Шаг 2. Используйте инструмент WiredTiger
Поскольку это не сработало, как я ожидал, я начал искать другие инструменты или подходы, которые могут мне помочь. Вот ссылка Восстановление коллекции WiredTiger из поврежденной установки MongoDB который знакомит с тем, как использовать WiredTiger для восстановления коллекций. И я решил попробовать.
Я создал папку db_backup и поместил в него все свои файлы. И я создал папку wiredtiger-3.0.0 под db_backup.Я установил wiredtiger в папке wiredtiger-3.0.0:
а) Спасти коллекцию
root@iZj6c0pipuxk17pb7pbaw0Z:/data/db_backup/# cd ./wiredtiger-3.0.0
root@iZj6c0pipuxk17pb7pbaw0Z:/data/db_backup/wiredtiger-3.0.0# ./wt -v -h ../db_for_wt -C "extensions=[./ext/compressors/snappy/.libs/libwiredtiger_snappy.so]" -R salvage collection-23--360946650994865928.wt
WT_SESSION.salvage 100
Судя по статье выше, это означает, что мы успешно спасли эту коллекцию.
Произошла ошибка:
б) Сбросить коллекцию
root@iZj6c0pipuxk17pb7pbaw0Z:/data/db_backup/wiredtiger-3.0.0# ./wt -v -h ../../db_backup -C "extensions=[./ext/compressors/snappy/.libs/libwiredtiger_snappy.so]" -R dump -f ../collection.dump collection-23--360946650994865928
lt-wt: cursor open(table:collection-23--360946650994865928) failed: No such file or directory
Обратите внимание, что приведенная выше команда действительно завершилась без .wt.
Я проверил свой аргумент каталога и не нашел вины. На картинке файл collection-23--360946650994865928.wt прямо здесь.
Снимок collection-23--360946650994865928.wt только что был спасен.
В нем можно было увидеть некоторые английские или китайские иероглифы. И эти данные действительно взяты из одной из коллекций базы данных. wecaXX.
Вопросы:
1) Теперь я застрял, выбрасывая коллекцию. Кто-нибудь знает, что в этом плохого?
2) collection-23--360946650994865928.wt содержит наши самые важные данные. Если мы не сможем восстановить всю базу данных, извлечение данных из этого файла все равно будет очень полезно. Однако, если мы копируем вставку вручную, не все символы хорошо написаны; их еще нужно расшифровать. Кто-нибудь знает как это сделать?
3) возможно ли, что мы не восстановили все файлы (или все тело всех файлов) в /data/db?
Любой комментарий или ответ будут оценены !!