Rolling Upgrades and High Availability Configuration

You can upgrade application servers using rolling upgrade, however with a few conditions.

The following conditions must be considered:

  • If database is changed, everything must be upgraded.
  • If application servers share configuration, upgrade requires change to configuration.

Version of Infrastructure

In general, most infrastructure upgrades require upgradation of all the components at the same time.

  • Database version – All database servers must be upgraded at the same time.
  • Operating system upgrade – Most operating system version upgrades can be done one server at a time depending on compatibility matrix published by TIBCO and OS vendor. In fact, all the servers are not required to be on the same OS platforms.
  • Web server upgrade – Web server upgrade can be done independent of other upgrades, each web server can be upgraded.
  • JMS server – JMS server can be upgraded independent of other servers. Within a JMS cluster, each of them must be upgraded at the same time.

TIBCO MDM Application Sever Upgrade

  • Application server version upgrade – As long as application server version is supported by a TIBCO MDM release, it can be upgraded one at a time.
  • TIBCO MDM version upgrade – TIBCO MDM version may require to upgrade.
  • Database schema or seed data changes – If schema changes are required, all TIBCO MDM instances must be upgraded together.
  • Configuration file changes – Each server can be upgraded by using a new ConfigValues.xml file; while the previous version continues to use the previous config file.
  • Executables – In some cases, all servers need to be upgraded at the same time (assuming there are no database schema changes). For example, when an object distributed over queue has changed, it requires that all recipient are on the same version to avoid de-serialization errors.
  • Cache server – The Cache server may require a restart when TIBCO MDM server is upgraded due to change in data objects, which are stored in cache. In this case, all TIBCO MDM instances and all cache instances must be upgraded at the same time.
  • Advanced Search Engine – It is shipped with TIBCO MDM and follows the same upgrade path as TIBCO MDM version upgrade.

High Availability

  • Each component can be clustered
    • Database, that is, Oracle RAC
    • TIBCO MDM instances
    • Web servers
    • Advanced Search Engines (Patterns)
    • Cache servers
    • JMS servers
  • TIBCO MDM can be configured to use clusters of other engines (database, cache, JMS, Advanced search engine, and so on).
  • When a component fails, work is transferred to another server except for the following points:
    • TIBCO MDM user sessions are not replicated. When TIBCO MDM server fails, in-progress user transactions are discarded and user is redirected to another server. The transactions or operations, which are incomplete only those are discarded. User must login again.
    • When workflows failover to another server; depending on the workflow configurations, sometimes a workflow activity may repeat. For example, when a work item is created, distributed cache is updated to indicate that the work item has been created. When workflow restarts, it does not generate duplicate work item if such a marker is found. However, if cache has also failed, this marker may be lost and a duplicate work item is generated. Same scenario applies for any outgoing messages generated by the workflow.
  • The workload is shared amongst all engines.
    • TIBCO MDM instances share the workload using JMS queues. On failure of an instance, workload is automatically redistributed.
    • Cache can be setup to replicate data to more than one instance. On cache failure, critical cached data is transferred to another server or a replicated copy is used. Most of the cached data does not have to be replicated as it is persisted to database.
    • TIBCO MDM server automatically connects to the next database, Advanced 
Search Engine, cache, or JMS server.
  • TIBCO MDM implements a wait and retry algorithm for transient system failures while executing workflows. For example, if an intermittent network failure happens, which causes database connection to be dropped, TIBCO MDM rolls back to the last commit state and retry the operation.
  • The web server can be setup to automatically redirect the users to next working TIBCO MDM instance.