We are glad that you are reading this page because that means you’re already convinced of the power of Syndeia 3.3 with all the cool, new features and you’ve either already installed Syndeia Cloud 3.3, or are in the process of doing so, and you are wondering what happens to the data that you’ve painstakingly created with Syndeia Cloud 3.2? Well, since Syndeia 3.3 was such a big release, a lot has changed behind the scenes, and that means, unavoidably, you’ll have to migrate your data so that it complies with the data format expected by Syndeia 3.3. This page explains what the entire migration process entails and the steps to successfully transition to Syndeia 3.3.

NOTE: For the remainder of the document, whenever Syndeia 3.3 is mentioned, it means Syndeia Cloud 3.3, and same for Syndeia 3.2.

...

1. Syndeia 3.2 installed and running on a server. Syndeia 3.2 requires the Cassandra database and a syndeia keyspace to hold 3.2 data. This is our source server (database).

2. Syndeia 3.3 installed and running on a server. Syndeia 3.3 also requires the Cassandra database and syndeia_cloud_store & syndeia_cloud_auth keyspaces to hold 3.3 data. Additionally, Syndeia 3.3 uses JanusGraph behind the scenes, which requires additional syndeia_cloud_graph & syndeia_cloud_graph_config keyspaces to hold graph data. This is our target server (database).

3. The superuser and the setup steps should’ve already been run on the Syndeia 3.3 server.

4. The migration process requires an additional syndeia_cloud_devops keyspace on the target 3.3 server. The schema/gen-schema.cql file contained in this utility has the required CQL statements to create the schema and tables. Please run this utility from a CQL shell or using a tool similar to DataStax Devcenter. This keyspace has three sets of tables - a pre_stage_* set, a migrate_stage_* set, and a duplicate_* set of tables.

5. The Syndeia-Migration-3.3 utility.

6. The user who is doing the migration should be an admin user. Additionally, he should have the credentials of each external repository (server) because one of the steps requires that you run the Syndeia dashboard and connect to each of the repositories using your credentials. Also, this user should have permission to view all the data in any of the external repositories (servers).

...

The conf/application.conf file contained in this application utility has to be supplied with the correct values for the source/target databases and whether the source server is LDAP enabled or not. It should also specify the Syndeia 3.3 server IP address and the port and the sign-in username and password for signing in to Syndeia Cloud 3.3 (preferably, this user should have admin rights so that he may create/update any data he likes). The relevant sections are -

target {
  db {
    host = "localhost",
    username = "cassandra-username",
    password = "cassandra-pwd",
    port = 9042
    keyspace = "syndeia_cloud_devops"
  }
}

source {
  db {
    host = "localhost",
    username = "cassandra-username",
    password = "cassandra-pwd",
    port = 9042
    keyspace = "syndeia"
  }

  server {
    isLdapEnabled = false
  }
}

sign-in {
  username = "super.user"
  password = "super.user.pwd"
}

server {
  ip-address = "localhost"
  port = 9000
}

api {
  default-wait-duration = 2
}

Similarly, we need to update a few lines in the bin/syndeia-migration.bat file (or the bin/syndeia-migration file, for Linux / Mac). The following is an example of changes made to the bin/syndeia-migration.batfile; please do the similar changes in bin/syndeia-migration file.

set CFG_OPTS=-Xms1G -Xmx8G
set _JAVA_PARAMS=-Djava.library.path=lib -Dconfig.file=conf/application.conf
set "APP_CLASSPATH=%APP_LIB_DIR%\*;%APP_LIB_DIR%\com.intercax.syndeia-migration-3.3.jar"

...

Step-by-Step Migration Process

...

Key: MIGCONT
Name: Migration container
Description: Container for migrating data from Syndeia 3.2 to 3.3, and press Create New button (as shown below).

...

NOTE: This is a sample project which can be deleted later once this migration activity is complete.

...

The picture above shows the username which is used for connecting to each of the repositories.
NOTE: The user used to connect to any repository, must have access to data in that repository, otherwise that data won’t be migrated.

...