Resolution: Won't Fix
Affects Version/s: 5.0.3, 5.1.1
Fix Version/s: None
Component/s: Search and Indexing (non-UI)
Environment:Client: MacBook Pro with OS X 10.11.6 and Firefox
Server: Ubuntu, 2x CPUs and 8 GB RAM; Alfresco v126.96.36.199
If you intend to switch straight to Solr4 on Alfresco One v5.0.x or later in case of an upgrade scenario and you know that you are going to
repeat the upgrade on cutover, hence a Solr4 index backup taken prior to the cutover upgrade run can't be used because the ACLs are modified during the
upgrade process and persisted with a new timestamp in the DB. Thus the ACLs stored in the Solr4 index backup don't match the timestamps of those in the
[Steps to reproduce]:
1.) Set up an Alf v3.4.2, log in as admin, create a test site with a folder, upload 2000+ docs and delete few of them => OK
2.) Set up an Alf v188.8.131.52, take a backup of content store and DB from Alf 3.4.2 and migrate to v184.108.40.206 => OK
3.) Set up an Alf v220.127.116.11, take a backup of content store and DB from Alf 18.104.22.168 and migrate to v22.214.171.124 => OK
4.) Set up an Alf v126.96.36.199, take a backup of content store and DB from Alf v188.8.131.52 and migrate to v184.108.40.206 with Solr1/4 disabled => OK
5.) Enable Solr4 on the Alf v220.127.116.11, restart in order to build the index for later use => OK
6.) Create a Solr4 backup for the archive & alfresco content store via jconsole => OK
7.) Go back to the Alf 3.4.2, upload some more content, delete few docs, create a folder on the same site, upload some docs there and take a fresh backup of both the content store and DB in order to walk through the upgrade process again - steps 2.) - 4.) => OK
8.) Restore Solr4 backup taken on step 6.) => OK
9.) Enable Solr4 on Alf v18.104.22.168, restart in order to allow Solr4 to catch up with recently added content => Fail
It should be possible to pre-build a Solr4 index and take backups of it for later use in order to prepare an environment for the cutover,
hence to save time and resources on the target architecture during the final upgrade.
Re-using a Solr4 index backup fails with the following error message: ERR [AclTracker] First acl transaction was not found with the correct timestamp.
[Analysis to date]:
1.) During the upgrade process the ACLs are modified and persisted in the DB with a new epoch timestamp. You can check that by comparing the content of the table "alf_acl_change_set" of the first upgrade dry-run with the one of the second run. Hence the timestamps of the ACLs indexed of the first run don't match those of the last run in the DB.
In conclusion Solr4 fails to track new content, i.e. content added to the environment post the first upgrade run, and throws the following exceptions:
a.) Pre-build the index on Solr1 on the first upgrade dry-run and re-use that index on any upgrade re-run
b.) Switch on Solr4 indexing in the background on the final cutover upgrade
c.) Wait till the Solr4 has been built completely
d.) Decommission Solr1 on the next maintenance window
=> The Solr4 index created can be re-used on later Alfresco One versions featuring Solr4
3.) For the time being, the best practise procedure seems to be as follows if you intended to re-run the upgrade several times du to time or project contraints or simply would like to pre-build the Solr index in order to save time during the cutover upgrade to the target version.
=> The drawbacks here, for a while there will be additional load on the system/s hosting both Solr1/4 or an additional time consuming step, i.e. rebuilding a new
Solr4 indexing on the cutover upgrade is required before concluding the migration to the traget version.