Estoy seguro de que hay una solución sencilla. Estoy ejecutando un servicio Mongodb de la siguiente manera:
[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
Estoy haciendo que Docker asigne el directorio /data/oqm/db/mongo/ del host y parece que esto funciona bien; Mirando desde el host, veo el directorio lleno cuando se ejecuta. Esta configuración parece funcionar bien entre reinicios y persiste bien.
Sin embargo, cuando intento hacer una copia de seguridad y restaurar los datos copiándolos en este directorio y luego volviendo a ingresarlos, al intentar restablecer el servicio, Mongo vomita, alegando que los datos están dañados. ¿Algunas ideas?
Para que quede claro, tanto mi copia de seguridad como mi restauración ocurren cuando se detiene el servicio y consisten en:
Copia de seguridad:
- Detener el servicio (usando systemd)
- Copiar los archivos en el directorio de datos
- Iniciar la copia de seguridad del servicio (usando systemd)
Restaurando:
- Detener el servicio (usando systemd)
- bombardear los archivos existentes en el directorio de datos
- volver a copiar los archivos copiados anteriormente
- Iniciando el servicio (usando systemd) (falla)
Estoy probando este método como se describe generalmente en los documentos:https://www.mongodb.com/docs/manual/core/backups/#back-up-with-cp-or-rsync
Fragmento de registros de errores:
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"}}
Actualización: después de que se sugirió, verifiqué dos veces que los permisos se estén conservando y definitivamente se están conservando ahora. Desafortunadamente, sigo teniendo el mismo problema.
Respuesta1
Lo averigué.
Los permisos definitivamente podrían haber influido, pero lo que realmente lo hizo fue darse cuenta de que:
rm -rf "/some/dir/*"!=rm -rf /some/dir*
Cambiar el comando rm -rf "$root/some/dir"/*funcionó