Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
I currently have the following live setup:
I now have access to 2 more servers and would like to deploy the following whilst maintaining the existing apps, security rules, users, licences and basically everything which is contained within the repository database
Ideally, in order to perform the cleanest install and to keep the lights on for users for the maximum time I would like
Could anyone please advise the best approach/path/method to this migration/upgrade ?
Hello!
The operation you want to do and the way you want to do it will require a lot of downtime and involve changes through postgre sql and many other changes in the settings xmls, probably also the certificates, especially since you want to change who will be the new central node.
I suggest an alternative that involves less downtime and fewer operations to perform, that you add the new node that you want to be central as a failover and then set it as a central node. in this way, you will have covered the situation in which the central node may have problems and drops, and you can also use it for activities such as reloads or consumption for the end-user.
my plan would be:
1. August 2023 installation on new nodes:
a. I add the node that I want to be central to the architecture as failover
b. I add the node that I want to be dev to the architecture as a normal node
2. proxies configuration, load balancing and what other configurations you have set in your architecture for the newly added nodes.
3. upgrade version August 2023 on old nodes.
4. stop services on the current central node so that the new failover node becomes central
5. start services on the old central node that has now become failover.
From point 2 on down, it will involve downtime for end-users.
Obviously, I expect that along the way you will encounter other atypical situations depending on the configurations you have in your architecture: load balancing, custom properties... etc.
The approximate duration of the operation is 8 hours, depending on the specifications of the new servers.
Have fun!
Hello!
The operation you want to do and the way you want to do it will require a lot of downtime and involve changes through postgre sql and many other changes in the settings xmls, probably also the certificates, especially since you want to change who will be the new central node.
I suggest an alternative that involves less downtime and fewer operations to perform, that you add the new node that you want to be central as a failover and then set it as a central node. in this way, you will have covered the situation in which the central node may have problems and drops, and you can also use it for activities such as reloads or consumption for the end-user.
my plan would be:
1. August 2023 installation on new nodes:
a. I add the node that I want to be central to the architecture as failover
b. I add the node that I want to be dev to the architecture as a normal node
2. proxies configuration, load balancing and what other configurations you have set in your architecture for the newly added nodes.
3. upgrade version August 2023 on old nodes.
4. stop services on the current central node so that the new failover node becomes central
5. start services on the old central node that has now become failover.
From point 2 on down, it will involve downtime for end-users.
Obviously, I expect that along the way you will encounter other atypical situations depending on the configurations you have in your architecture: load balancing, custom properties... etc.
The approximate duration of the operation is 8 hours, depending on the specifications of the new servers.
Have fun!
thx @kallay - how do I manage the upgrade of Postgres to 14.8 ( I understand there is a QPI installer tool from Qlik)- and then to make sure that on completion of the migration, that the repository and app/content file data all reside on the new central node ?
If I understood correctly from the first post, the postgre server is standalone in another location and I don't see a problem in upgrading it as long as you stop the services on all nodes during the upgrade.
The location of the QVF files is where it was initially set at the time of the architecture installation, and the method proposed above does not change their location.
The connection to the repository is made individually by each node through the "QlikSense Repository service" service and you don't have to do anything about it.
If you want to change their location, you must use the suite of tools that comes with QlikSense. https://community.qlik.com/t5/Official-Support-Articles/How-to-change-the-share-path-in-Qlik-Sense-S...
@kallay ..the current repository is 9.6 and not standalone - stored within the current Feb 2022 QS install folder
However, as part of the migration, I would like to upgrade to 14.8 (as reqd by newer versions) but also to install it to a separate folder (I know this is possible using the QPI util)
Finally I wold want to move the shared location of apps to the new central node so would need to repoint the repo service to this location - think this bit is answered by the article in the URL you posted, thx