SOLR 4 subsystem includes by default following scheduled jobs:
search.indexBackupJobDetail > index.backup.cronExpression=0 0 3 * * ?
search.alfrescoCoreBackupJobDetail > solr.backup.alfresco.cronExpression=0 0 2 * * ?
search.archiveCoreBackupJobDetail > solr.backup.archive.cronExpression=0 0 4 * * ?
I've been trying to guess what backup is done by everyone, but I've not been able to follow all the threads. Probably, this could fit the following folders:
/opt/alf_data/solr4/content
/opt/alf_data/solr4/index/archive
/opt/alf_data/solr4/index/workspace
But then, default cron expressions have no sense for me.
Is this documented in any place?
Solved! Go to Solution.
You are misunderstanding what contentStoreCleanerJobDetail does. It does not cause any new entries in archive SOLR indexes to be created. When content is moved from contentstore into contentstore.deleted, it has already been removed from the archive (or it has never been there in case the content was not archived / transferred into the trash can). So there is no competition between the contentStoreCleanerJobDetail and the archive index backup, if that is what you find weird.
Not sure exact things about this stuff, but if you analyse below files you will definitely get an idea.
community-edition-old/solr-backup-context.xml at master · Alfresco/community-edition-old · GitHub
community-edition-old/SolrBackupJob.java at master · Alfresco/community-edition-old · GitHub
community-edition-old/SolrBackupClient.java at master · Alfresco/community-edition-old · GitHub
Thanks for your comments.
I analysed those source files and also the ones related with Lucene. It looks like search.indexBackupJobDetail is not used anymore, as it was only relevant for Lucene.
So in current versions we have a backup for both SOLR cores: alfresco and archive. The first one is performed at 2:00 AM and the second one at 4:00 AM. This last scheduling happens at the same time than contentStoreCleanerJobDetail, which is moving files from contentstore to contentstore.deleted. So we have Alfresco backing archive SOLR indexes and creating new entries in archive SOLR indexes at the same time.
It could be a designed behaviour but I found it weird.
You are misunderstanding what contentStoreCleanerJobDetail does. It does not cause any new entries in archive SOLR indexes to be created. When content is moved from contentstore into contentstore.deleted, it has already been removed from the archive (or it has never been there in case the content was not archived / transferred into the trash can). So there is no competition between the contentStoreCleanerJobDetail and the archive index backup, if that is what you find weird.
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.