Ich bin sicher, dass es eine einfache Lösung gibt. Ich betreibe einen Mongodb-Dienst folgendermaßen:
[Unit]
Description=Mongo server for Open Quartermaster. Version ${version}, using MongoDB tagged to "4".
Documentation=https://github.com/Epic-Breakfast-Productions/OpenQuarterMaster/tree/main/software/Infrastructure
After=docker.service
Wants=network-online.target docker.socket
Requires=docker.socket
[Service]
Type=simple
Restart=always
TimeoutSec=5m
#ExecStartPre=/bin/bash -c "/usr/bin/docker container inspect oqm_mongo 2> /dev/null || "
ExecStartPre=/bin/bash -c "/usr/bin/docker stop -t 10 oqm_infra_mongo || echo 'Could not stop mongo container'"
ExecStartPre=/bin/bash -c "/usr/bin/docker rm oqm_infra_mongo || echo 'Could not remove mongo container'"
ExecStartPre=/bin/bash -c "/usr/bin/docker pull mongo:4"
ExecStart=/bin/bash -c "/usr/bin/docker run \
--name oqm_infra_mongo \
-p=27017:27017 \
-v /data/oqm/db/mongo/:/data/db \
mongo:4 mongod --replSet rs0"
ExecStartPost=/bin/bash -c "running=\"false\"; \
while [ \"$running\" != \"true\" ]; do \
sleep 1s; \
/usr/bin/docker exec oqm_infra_mongo mongo --eval \"\"; \
if [ \"$?\" = \"0\" ]; then \
echo \"Mongo container running and available!\"; \
running=\"true\"; \
fi \
done \
"
ExecStartPost=/bin/bash -c "/usr/bin/docker exec oqm_infra_mongo mongo --eval \"rs.initiate({'_id':'rs0', 'members':[{'_id':0,'host':'localhost:27017'}]})\" || echo 'Probably already initialized.'"
ExecStop=/bin/bash -c "/usr/bin/docker stop -t 10 oqm_infra_mongo || echo 'Could not stop mongo container'"
ExecStopPost=/bin/bash -c "/usr/bin/docker rm oqm_infra_mongo || echo 'Could not remove mongo container'"
[Install]
WantedBy=multi-user.target
Ich lasse Docker das Verzeichnis /data/oqm/db/mongo/ des Hosts zuordnen und es sieht so aus, als ob das gut funktioniert. Wenn ich vom Host aus schaue, sehe ich, dass das Verzeichnis beim Ausführen gefüllt ist. Dieses Setup scheint zwischen Neustarts gut zu funktionieren und bleibt einwandfrei bestehen.
Wenn ich jedoch versuche, die Daten zu sichern und wiederherzustellen, indem ich die Daten aus diesem Verzeichnis heraus- und wieder hineinkopiere, stürzt Mongo beim Versuch, den Dienst wieder zu starten, ab und behauptet, die Daten seien beschädigt. Irgendwelche Ideen?
Um es klarzustellen: Sowohl mein Backup als auch meine Wiederherstellung erfolgen, wenn der Dienst gestoppt ist, und bestehen aus:
Sichern:
- Beenden des Dienstes (mithilfe von systemd)
- Kopieren der Dateien im Datenverzeichnis
- Starten des Dienstes „Backup“ (mit systemd)
Wiederherstellen:
- Beenden des Dienstes (mithilfe von systemd)
- Löschen der vorhandenen Dateien im Datenverzeichnis
- Zurückkopieren der zuvor auskopierten Dateien
- Starten des Dienstes (mit systemd) (schlägt fehl)
Ich versuche diese Methode, wie sie allgemein in den Dokumenten beschrieben wird:https://www.mongodb.com/docs/manual/core/backups/#back-up-with-cp-or-rsync
Ausschnitt aus Fehlerprotokollen:
May 27 09:06:59 oqm-dev bash[41304]: {"t":{"$date":"2023-05-27T13:06:59.275+00:00"},"s":"I", "c":"STORAGE", "id":22315, "ctx":"initandlisten","msg":"Opening WiredTiger","attr":{"config":"create,cache_size=11224M,session_max=33000,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,close_scan_interval=10,close_handle_minimum=250),statistics_log=(wait=0),verbose=[recovery_progress,checkpoint_progress,compact_progress],"}}
May 27 09:06:59 oqm-dev bash[41304]: {"t":{"$date":"2023-05-27T13:06:59.686+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1685192819:686027][1:0x7fefd1197cc0], txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 1 through 3"}}
May 27 09:06:59 oqm-dev bash[41304]: {"t":{"$date":"2023-05-27T13:06:59.719+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1685192819:719823][1:0x7fefd1197cc0], txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 2 through 3"}}
May 27 09:06:59 oqm-dev bash[41304]: {"t":{"$date":"2023-05-27T13:06:59.749+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":"[1685192819:749492][1:0x7fefd1197cc0], txn-recover: [WT_VERB_RECOVERY_PROGRESS] Recovering log 3 through 3"}}
May 27 09:06:59 oqm-dev bash[41304]: {"t":{"$date":"2023-05-27T13:06:59.801+00:00"},"s":"E", "c":"STORAGE", "id":22435, "ctx":"initandlisten","msg":"WiredTiger error","attr":{"error":-31804,"message":"[1685192819:801911][1:0x7fefd1197cc0], txn-recover: __recovery_setup_file, 643: metadata corruption: files file:collection-0-6243490866083295563.wt and file:collection-0--9007965794334803376.wt have the same file ID 4: WT_PANIC: WiredTiger library panic"}}
May 27 09:06:59 oqm-dev bash[41304]: {"t":{"$date":"2023-05-27T13:06:59.801+00:00"},"s":"F", "c":"-", "id":23089, "ctx":"initandlisten","msg":"Fatal assertion","attr":{"msgid":50853,"file":"src/mongo/db/storage/wiredtiger/wiredtiger_util.cpp","line":481}}
May 27 09:06:59 oqm-dev bash[41304]: {"t":{"$date":"2023-05-27T13:06:59.802+00:00"},"s":"F", "c":"-", "id":23090, "ctx":"initandlisten","msg":"\n\n***aborting after fassert() failure\n\n"}
May 27 09:06:59 oqm-dev bash[41304]: {"t":{"$date":"2023-05-27T13:06:59.802+00:00"},"s":"F", "c":"CONTROL", "id":4757800, "ctx":"initandlisten","msg":"Writing fatal message","attr":{"message":"Got signal: 6 (Aborted).\n"}}
Update: Nachdem es vorgeschlagen wurde, habe ich noch einmal überprüft, ob die Berechtigungen erhalten bleiben, und jetzt bleiben sie definitiv erhalten. Leider tritt immer noch das gleiche Problem auf
Antwort1
Herausgefunden.
Berechtigungen mögen definitiv eine Rolle gespielt haben, aber ausschlaggebend war die Erkenntnis, dass:
rm -rf "/some/dir/*"!=rm -rf /some/dir*
Das Ändern des Befehls hat rm -rf "$root/some/dir"/*den Trick getan