This blog describes a specific situation in which we install Qlik Sense utilizing AWS RDS Postgres.
As stated in our last blog posted February 21, 2017, Qlik recently announced that as of Qlik Sense 4.0 (to be released later this year), shared persistence will be the only available storage architecture. This is big news as almost all new installations up until the latest version (3.2) have been completed using the synchronized persistence architecture (see the previous blog post on 2/21 for more information on the two architectures).
If you are looking at this and thinking you need to start thinking about a migration plan, you’ve come to the right place!
Bardess has Completed a Complex Sync to Shared Migration
Bardess has just completed a complex sync to shared migration of a 4 node environment housed entirely in AWS. Not only that, given the flexibility of shared persistence, we helped move the client’s Postgres database from local storage into AWS RDS. This enables resiliency and frees up time spent on routine admin tasks.
Migrating from sync to shared persistence was not without its challenges. Here are some quick pointers and pitfalls that we ran into.
Clean Up That Database
Synchronized architecture tends to leave behind many orphan records in the Postgres database when adding and removing Qlik resources, like apps or sheets in a multi-node site. It can get to a point where Qlik recommends running a manual cleanup process against the Postgres database before any type of upgrade or migration. In our case, the orphan records appeared to be active applications in the Qlik management console (QMC), however, they could not be deleted through the QMC because there wasn’t an actual .qvf file associated with the record. Cleaning up the database before backup should resolve this issue.
Backup Everything
This typically goes without saying, and if you’re on a virtual machine, a full snapshot should be taken in addition to the normal backup process. It’s also a good idea to take note of all custom security rules, custom properties, proxy authentication configuration, LDAP filters, and sync rules before you start.
Manually Configure Postgres RDS
Under normal circumstances with a local installation, Postgres config files need to be manually adjusted to fit the specifics of your environment and ensure that it can communicate securely between all of the Qlik nodes. In Postgres RDS, this is almost exclusively done through the AWS Console, so be sure you have access to manage these options (e.g. rds.force_ssl, max_connection, etc.) yourself or through a DBA before you get started.
Use Postgres Super User or Group?
In normal shared persistence migrations, the ‘qliksenserepository’ user must be created and granted super user privileges in Postgres in order to own the migrated repository. There are a few slight differences in super user privileges between RDS and local installs of Postgres so we had to make some on-the- fly adjustments. This meant that instead of just creating a user, we had to create a qliksenserepository Group Role and assign it the rds.superuser role. The master RDS user (default ‘postgres’ but is typically assigned a unique name when you sign up for RDS) is then assigned to that new group role. When you import your database, assign qliksenserepository as the owner and you’ll be good to go.
Restart
We had a little scare at the very end of the process when we started up the Qlik services and expected the apps to start migrating in the QMC. After a few minutes of staring at the screen, every single one changed to ‘Failed to Migrate’. After scouring websites and community forums, we decided to just give the server a reboot. As the Qlik services started back up, the migration process restarted successfully and we all started breathing again.
Enable SSL Encryption
We actually implemented SSL encryption between Qlik and the Postgres RDS instance some time after the initial upgrade. Amazon publishes steps on how to enable SSL encryption on your Postgres RDS instance and also provides the certificates you need. Once you have the cert from Amazon, install it on all of your Qlik nodes and drop it in your Postgres/bin folder. Update the Qlik connection string using the Connection Manager tool provided by Qlik to repoint to the correct port and require SSL. Restart services and you’re all set!
