You are here

Upgrading Alfresco Content Services

Use this procedure to upgrade from a previous version of Alfresco Content Services using the distribution zip. The process involves a new installation of the Alfresco Content Services binaries and configuration, and an in-place upgrade of a copy of the repository.

In-place upgrade of the binaries and configuration is not recommended. Creating a new installation ensures that if anything goes wrong during the upgrade, the original (not upgraded) system is still intact and available for immediate restart.

These steps assume that you have an existing Alfresco Content Services installation (alfresco-v.1) with the following settings:
File Name Properties dir.root=/alfresco-v.1/alf_data db.url=url<v.1> data.dir.root=/alfresco-v.1/solr/myindexes
  1. Install the new version of Alfresco Content Services using the distribution zip.
    1. Shut down your existing instance.
    2. Back up your existing repository (alfresco-v.1) and the database. See Backing up and restoring the repository.

      Note: Back up any configuration overrides from the <extension> directory.
    3. Install the new version (alfresco-v.2) into a different directory from the existing installation.

      For example, the new Alfresco installation will have the following settings:

  2. Validate the new 6.1.1 installation to check that it is working correctly.
    1. Configure the new installation with a new repository and database (not the existing one).
    2. Start the server and validate that the system works correctly.

    For more information, see Validating the upgrade.

  3. Apply all customizations to the new 6.1.1 installation.
    1. Stop the server.
    2. Remove any unwanted applications.
    3. Modify applications.
    4. Install the required AMP files. See Installing an Alfresco Module Package.
    5. Do not copy the files. Copy only the override settings so that you will not overwrite the new extension files in the upgraded version.
    6. Start the Alfresco server.

      Monitor the startup log messages for information on the status of the upgrade. If any issue(s) occur in the logs during startup, you need to rollback the whole repository to fix the issue(s) and then try again.

    7. Fully test the working and configuration of your customizations.
    8. Stop the server.
  4. Restore production data.
    1. Remove all the files and directories under the contentstore directory of the new installation. Also, delete the database.
    2. Delete the files in the two Solr alfrescoModels directories, and the indexes in the two directories (solr/workspace/ and solr/archive/) of the new installation.
    3. Restore the backup of the indexes, contentstore directory, files, and database from your previous installation into the new installation. See Restoring production data.
    4. Start the server.

      If any issue(s) occur in the logs during startup, you need to rollback the whole repository to fix the issue(s) and then try again.

  5. If you are happy with the upgraded system, remove the old installation and repository.
  6. [Optional] Perform this additional step only if you have configured multi-tenancy and are upgrading.

    If upgrading to the latest version, your existing MT sample extension files are no longer relevant and must be deleted. It is also recommended that you backup your existing MT files.

    1. Take a backup of the following three existing MT extension files and delete them from the existing MT extension directory:

      • alfresco/extension/mt/mt-context.xml to alfresco/extension/mt/mt-context.xml
      • alfresco/extension/mt/mt-admin-context.xml to alfresco/extension/mt/mt-admin-context.xml
      • alfresco/extension/mt/mt-contentstore-context.xml to alfresco/extension/mt/mt-contentstore-context.xml
  7. [Optional] Perform this step if you are working in a clustered environment:
    1. Shut down all nodes in the cluster.
    2. Perform steps 1 to 5 on each additional node in turn, ensuring that each node starts fully before restarting the next one.

      You need to copy the database once only as it is upgraded by the first node that is upgraded. The other nodes detect it has been upgraded and skip the database upgrade step.

      In a clustered environment, when the cloned nodes are restarted with a cluster license, the nodes may try to join the existing production cluster and point to a cloned database instead of the production cluster database. This can lead to corrupted data.

      Cause: It occurs because the cloned node contains the cluster id from production and tries to join that cluster.

      Solution: To avoid the problem you should ensure any cloned nodes required for upgrade testing are network isolated from the production nodes.

Sending feedback to the Alfresco documentation team

You don't appear to have JavaScript enabled in your browser. With JavaScript enabled, you can provide feedback to us using our simple form. Here are some instructions on how to enable JavaScript in your web browser.