Install new version

Overview

As a general precondition, note that to be able to attach TSS application to an external database, your component manager must not host any prior install with replication or have any replication link setup.

Once an install attached with an external database attached, you will be no more able to setup a replication link.  In other words, we do not support mix installation (replication or using external database) on a Virtual Application component manager.

Unlike classic installation with replication in a VA environment, the primary node does not attempt to replicate any information on secondary nodes. So, deployment on primary  and secondary nodes are totally independent processes. For this reason, the whole deployment process is meant to begin with the installation on the primary node and then on the secondary ones.

Note that, it is the administrator responsibility to ensure that, at any time, nodes connected to the same database are running with a distinct identity.

Installation on primary node (redundancy identity = 1)

Bootstrap upgrade

To be able to install TSS firmware with an external database, you will need to upgrade your TSS bootstrap to a version greater or equal to 9.5.

Firmware upload

Like a classic installation via the Component Manager, the administrator will first need to upload a compatible version (>= 9.5) of TSS firmware. To be able to configure an external database attached with your TSS install, please check the 'Use external database' checkbox.

Database connection configuration

As second step, the administrator will have to instruct the database on which to connect its new TSS install.

Database name convention

The database name follows the same convention as in any of our other deployment methods. The name must be "dbipt_<TSS_VERSION>", where <TSS_VERSION> stands for the version of TSS you are about to install. Be aware of this convention and ensure that no other install in the same version is using the same database server for another Virtual Appliance running the same TSS version.

Database engine support

Supported database engines, at this time, are the same supported in our standalone server setup:

•Microsoft SQL Server 2016 or 2022

•Azure SQL

•Oracle MySQL 8.0

Database server host and port

The database server hostname or IP address and its listening port.

Note: The TSS Virtual Appliance's firewall does not block any outgoing network connections. Be sure that the database server address and port are accessible for the VA node. You will have an opportunity to test a connection to the database by pressing the "Test Connection" once every information is filled.

Database user credential and privileges

You will be asked to provide a user credential able to connect to the database used by the future TSS installation. The user must have been granted the following privileges on the target database:

For SQL Server, the user is expected to have been granted these fixed databases roles:

odb_datareader

odb_datawriter

odb_ddladmin

odb_backupoperator

odb_owner

If you want to let the installation process create databases for you (for both install and update process), the database user need to be granted the "CREATE DATABASE" privilege.

For MySQL, the user is expected to have been granted these privileges:

oCREATE (table level for minimal privileges)

oDROP (table level for minimal privileges)

oINDEX

oREFERENCES

oALTER

oSELECT

oINSERT

oUPDATE

oDELETE

oCREATE ROUTINE

oALTER ROUTINE

oEXECUTE

oEVENT

oLOCK TABLES

If you want to let the installation process create databases for you (for both install and update process), the database user need to be granted the CREATE and DROP privileges at database level.

When binary logging is enabled, the database user need to be granted the SUPER privilege, unless stored function creators are trusted not to create stored functions that will cause unsafe events to be written to the binary log (See the global log_bin_trust_function_creators system variable).

Database initialization options

The install of a new firmware can target an external database in several states:

1. The target database does not yet exist on the database server: given that the database user has been granted "CREATE DATABASE" privileges, the installation process will take care of the creation and initialization of the database schema.

2. The target database has been created by an administrator but no schema is present: the database user will be used for schema creation, then by the TSS applications themselves for read/write access.

3. The target database already exists and contains data linked to an older TSS version: This scenario is useful if you want to start with a backup of another version of TSS. Restore it to the new target database, and point your new installation to this database. The installation process will detect the previous version and upgrade the schema to be compatible with this new TSS version.

Database collation and default charset

If the database creation process is handled by the administrator, in addition of the database naming convention, the TSS applications also expects these default collation and charset on the target database:

For MySQL:

Collation: utf8_bin

Charset: utf8

For SQL Server:

Collation: Latin1_General_CS_AS

Installation on secondary nodes (redundancy identity from 2 to 6)

Deployment of secondary nodes consists uniquely in the TSS firmware installation and database configuration. No operation on the target database are made. The process assumes that a primary node has already been installed and initialized a database in this version.

Firmware upload

Deploy the same firmware version on your secondary nodes than on your primary. Confirm that you want to attach this secondary node to an external database by checking the 'Use external database' checkbox.

Database connection configuration

Provide the same information than for your primary node.