Uploaded image for project: 'Service Packs and Hot Fixes'
  1. Service Packs and Hot Fixes
  2. MNT-17070

You can't re-use an existing Solr4 index backup if you repeat an upgrade from an Alfresco One prior to v5.0.x


    • Type: Feature
    • Status: Closed
    • Resolution: Won't Fix
    • Affects Version/s: 5.0.3, 5.1.1
    • Fix Version/s: None
    • Labels:
    • Environment:
      Client: MacBook Pro with OS X 10.11.6 and Firefox
      Server: Ubuntu, 2x CPUs and 8 GB RAM; Alfresco v5.0.3.5
    • ACT Numbers:



      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
      DB anymore.

      [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 v3.4.14.24, take a backup of content store and DB from Alf 3.4.2 and migrate to v3.4.14.24 => OK
      3.) Set up an Alf v4.2.6.1, take a backup of content store and DB from Alf and migrate to v4.2.6.1 => OK
      4.) Set up an Alf v5.0.3.5, take a backup of content store and DB from Alf v4.2.6.1 and migrate to v5.0.3.5 with Solr1/4 disabled => OK
      5.) Enable Solr4 on the Alf v5.0.3.5, 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 v5.0.3.5, restart in order to allow Solr4 to catch up with recently added content => Fail

      [Expected Behaviour]:
      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.

      [Observed Behaviour]:
      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:

      ERR [AclTracker] First acl transaction was not found with the correct timestamp. 
      SOLR has connected to your repository however the SOLR indexes and repository database do not match. 
      If this is a new or rebuilt database your SOLR indexes also need to be re-built to match the database. 

      2.) Workaround:
      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.

      1.) Get to your target version by following the upgrade path without any search index 
      2.) Enable Solr1 and rebuild a fresh search index and test the search functionality 
      3.) Take a backup of the Solr1 index 
      4.) Repeat the upgrade to the target version as often as needed and re-use you current Solr1 index 
      5.) On the cutover date migrate your latest content store and DB snapshot plus re-use your latest Solr1 backup 
      6.) Enabled Solr4 in order to build the corresponding index in the background 
      7.) Solr1 will catch up with the latest content and search functionality will be available to the end-users. In the meantime Solr4 will build another index in the background 
      8.) Once the Solr4 index is built, you can decommission Solr1 and its index 
      9.) From now on, you can carry forward the Solr4 index to later Alfresco One versions. 

      => 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.





              • Assignee:
                closedissues Closed Issues
                nkisa Nebil Kisa
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created:

                  Structure Helper Panel