Overview

The general process for upgrading Syndeia Cloud is to:

Download & extract the new build,
Import in settings from the old build to new build,
(Migrate any data, if a schema change has occurred- we will let you know of supported upgrade paths and whether any of them will involve any schema changes),

A schema describes the structure of an application database, ie: tables, data types, views, stored procedures, etc. If a schema change has occurred, this means the way the application represents your data has changed and will need converted to the new data representation model.
Stop the syndeia-cloud service from the old build,
Start the syndeia-cloud service from the new build.

Upgrading Syndeia Cloud

Download and extract new build

1. Download the new build,

2. Extract the new build to /opt/icx (for Linux) or %ProgramFiles%\Intercax (for Windows). It should create a new folder named syndeia-cloud-<version> or <YYYY-MM-DD>, where <YYYY-MM-DD> = the 4-digit year, 2-digit month, and 2-digit day respectively of the build date.

3. Read any release notes, if any.

Import in settings from old build to new build

4. Apply any settings from the old build’s application.conf file to the new build’s application.conf file, ie: database setttings (username, password, cluster setting- if any, etc.)

5. Are schema changes being introduced? If No, proceed to the next step. If Yes, skip the next step.

A. Upgrade with no Schema Changes

6. Stop the syndeia-cloud service for the old build.

7. If using symlinks, update the syndeia-cloud-current symlink to point from the old to the new build, ie: syndeia-cloud-current → /opt/icx/syndeia-cloud-<version> or <YYYY-MM-DD> (for Linux) or %ProgramFiles%\Intercax\syndeia-cloud-<version> or <YYYY-MM-DD> (for Windows) (for more information on symlinks see Appendix D4.1 if on Windows, or Appendix D4.2 if on Linux).

8. Start the syndeia-cloud service for the new build.

9. Validate it’s working by proceeding to Validating Build and if successful, skip the remaining steps below, otherwise, fall back to the old build and triage why the new build is not working until it is.

B. Upgrade with Schema Changes (migrate data)

10. Define a new keyspace for the new build, call it something different from the old build’s keyspace, ie: syndeia_new (see Appendix B2.7 on how to create a keyspace),

11. Update the new build's application.conf's keyspace line to point to the new keyspace name,

keyspace = "syndeia"

12. Run the schema generation .CQL script/code included with the new build to generate the new keyspace,

13. Stop the syndeia-cloud service from the old build.

14. Run the migration .CQL script/code included with the new build to migrate your data from your old to new keyspace,

Note, depending on the amount of data you have, this may take some time.

15. Start the syndeia-cloud service with the new build,

16. Validate it’s working by proceeding to Validating Build. If not successful, fall back to the old build and triage why the new build is not working until it is.

17. If the validation is successful, stop the syndeia-cloud service,

18. In CQLSH, DROP the old keyspace (or if a backup is desired, perform an export, see Backup & Restore Methods for Syndeia Cloud Keyspace in Cassandra) and use something like https://stackoverflow.com/questions/36493371/is-there-a-way-to-rename-a-keyspace-while-cloning-a-cluster-using-opscenter or http://blog.nkn.io/post/rename-cassandra-keyspace/ to rename the syndeia_new keyspace back to the original, pre-suffixed name, syndeia.

19. Update the application.conf to point back to the original, pre-suffixed name, syndeia.

20. Restart the syndeia-cloud service. Validate it’s working by proceeding to Validating Build. If successful, perform any other data-specific tests and either keep or delete the previously created backup/export now, or after a period of time you are comfortable with (ex: 1-2 weeks).

Validating Build

21. Follow the validation steps provided in the Validating Syndeia Cloud Installation & Configuration section.

Browser not supported