patternMinor
Is it safe to run "Repair - Reconcile component database from blob store job" in Nexus 3
Viewed 0 times
repairnexusstorereconciledatabasesafecomponentfromblobjob
Problem
We have a nexus 3.12.1 and its daily storing hundreds of artifacts which are build from Jenkins. The problem is there are too many files present in blob store are not showing in Nexus Console. Actually we don't want these files but that is filling up too much disk space. We ran all cleanup tasks on all of the repositories, but it is not cleaning the artifacts present in blob-store.
So our approach is to first run the task "Repair - Reconcile component database from blob store job" and then "Remove snapshots from Maven repository"
We have dry run the task "Repair - Reconcile component database from blob store job". The output of the log files is of 105079 lines, took ~15 min and we got only 2 warnings (no errors).
And summery logs are as below:
```
...............
2019-08-23 04:37:43,653+0000 INFO [quartz-5-thread-20] *SYSTEM org.sonatype.nexus.blobstore.restore.maven.internal.MavenRestoreBlobStrategy - ::DRY RUN:: Restored asset, blob store: default, repository: snapshots, path: com/CMP/MODULE/FUNCTION/ui/MODULE-FUNCTION-ui/2.14.2-SNAPSHOT/MODULE-FUNCTION-ui-2.14.2-20190502.152829-43.pom.md5, blob name: com/CMP/MODULE/FUNCTION/ui/MODULE-FUNCTION-ui/2.14.2-SNAPSHOT/MODULE-FUNCTION-ui-2.14.2-20190502.152829-43.pom.md5, blob id: bf5327dd-e386-4fc4-a625-9da968e99f64
2019-08-23 04:37:43,666+0000 INFO [quartz-5-thread-20] *SYSTEM org.sonatype.nexus.blobstore.restore.RestoreMetadataTask - ::DRY RUN:: Elapsed time: 9.276 min, processed: 376782, un-deleted: 0
2019-08-23 04:3
So our approach is to first run the task "Repair - Reconcile component database from blob store job" and then "Remove snapshots from Maven repository"
We have dry run the task "Repair - Reconcile component database from blob store job". The output of the log files is of 105079 lines, took ~15 min and we got only 2 warnings (no errors).
cat blobstore.rebuildComponentDB-20190823042827074.log | grep -v INFO
2019-08-23 04:33:04,902+0000 WARN [quartz-5-thread-20] *SYSTEM org.sonatype.nexus.blobstore.restore.maven.internal.MavenRestoreBlobStrategy - Skipping as no maven coordinates found and is not maven metadata
2019-08-23 04:33:39,633+0000 WARN [quartz-5-thread-20] *SYSTEM org.sonatype.nexus.blobstore.restore.maven.internal.MavenRestoreBlobStrategy - Skipping as no maven coordinates found and is not maven metadataAnd summery logs are as below:
```
...............
2019-08-23 04:37:43,653+0000 INFO [quartz-5-thread-20] *SYSTEM org.sonatype.nexus.blobstore.restore.maven.internal.MavenRestoreBlobStrategy - ::DRY RUN:: Restored asset, blob store: default, repository: snapshots, path: com/CMP/MODULE/FUNCTION/ui/MODULE-FUNCTION-ui/2.14.2-SNAPSHOT/MODULE-FUNCTION-ui-2.14.2-20190502.152829-43.pom.md5, blob name: com/CMP/MODULE/FUNCTION/ui/MODULE-FUNCTION-ui/2.14.2-SNAPSHOT/MODULE-FUNCTION-ui-2.14.2-20190502.152829-43.pom.md5, blob id: bf5327dd-e386-4fc4-a625-9da968e99f64
2019-08-23 04:37:43,666+0000 INFO [quartz-5-thread-20] *SYSTEM org.sonatype.nexus.blobstore.restore.RestoreMetadataTask - ::DRY RUN:: Elapsed time: 9.276 min, processed: 376782, un-deleted: 0
2019-08-23 04:3
Solution
And looking into the logs above, is it safe to run this task? And will
we need any downtime for this?
I would suggest to backup all artifacts and upload them to a new Nexus (I created n3dr for this) as I have seen multiple errors in Nexus that did not give me enough confidence to just run some tasks.
Once we deployed a new Nexus and included it in our build environment for two weeks we knew that everything was still working well. Then we applied some jobs to the old decommissioned Nexus and it turned out that it was fine.
In summary, ensure that you have a another Nexus that is working well before executing tasks that could go wrong.
we need any downtime for this?
I would suggest to backup all artifacts and upload them to a new Nexus (I created n3dr for this) as I have seen multiple errors in Nexus that did not give me enough confidence to just run some tasks.
Once we deployed a new Nexus and included it in our build environment for two weeks we knew that everything was still working well. Then we applied some jobs to the old decommissioned Nexus and it turned out that it was fine.
In summary, ensure that you have a another Nexus that is working well before executing tasks that could go wrong.
Context
StackExchange DevOps Q#8970, answer score: 2
Revisions (0)
No revisions yet.