Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Upgrading Syndeia Cloud:

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-<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.
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 N, proceed to the next step. If Y, skip the next step.

Upgrade with no Schema Changes:

6. If N, stop the syndeia-cloud service for the old build and start it with the new build. 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.

Upgrade with Schema Changes:

7. If Y, 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),
8. Update the application.conf's keyspace line to point to the new keyspace name,
9. Run the schema generation .CQL script/code included with the new build to generate the new keyspace,
10. Run the migration .CQL script/code included with the new build to migrate your data from your old to new keyspace,
11. Start the service with the new build,
12. 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.
13. If the validation is successful, stop the Syndeia Cloud service,
14. In CQLSH, DROP (or if a backup is desired, export) the old keyspace (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.
15. Update the application.conf to point back to the original, pre-suffixed name, syndeia.
16. Restart the 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:

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

  • No labels