2.10 - Overview of Merging QueryGrid Manager Clusters - Teradata QueryGrid

Teradata® QueryGrid™ Installation and User Guide

prodname
Teradata QueryGrid
vrm_release
2.10
created_date
September 2019
category
Administration
Configuration
Installation
User Guide
featnum
B035-5991-099K
A system can only be managed by a single QueryGrid Manager cluster, and systems within your environment must be managed by that same QueryGrid Manager cluster to communicate through QueryGrid. Therefore, only one QueryGrid Manager cluster in your environment is recommended. Beginning with QueryGrid version 2.08, you can merge two separate QueryGrid Manager clusters into a single QueryGrid Manager cluster to enable communication throughout your entire ecosystem.
If merging a site with a full Vantage stack and analytical nodes, open an incident with the QueryGrid GSO team for consultation before merging.
For clarity, this overview uses Cluster A and Cluster B as examples with the following characteristics:
  • Cluster A – The larger cluster of the two and designated to incorporate Cluster B information.
  • Cluster B – The cluster that is merged into Cluster A.
Merging QueryGrid Manager clusters consists of four main tasks:
  1. Backup one of the QueryGrid Managers in Cluster B
  2. Copy the Cluster B backup to a QueryGrid Manager on Cluster A
  3. Run the migrate command on Cluster A with the backup from Cluster B
  4. Join the QueryGrid Managers from Cluster B to Cluster A
During the migration process, Cluster A remains fully functional with no impact to any QueryGrid queries. Cluster B may have disruptions to any QueryGrid queries while the nodes are being migrated over and the fabric process is restarted.
The following tables list the objects that are and are not migrated from the backup file during the migration process.
Migrated
Software
Nodes (nodes register themselves as part of the migration process)
Data Centers
Systems
Bridges
Fabric
Connectors
Links
Network
Communication Policies
User Mappings
Not Migrated
Managers
Fabric Keys
Service Accounts
Manager Settings (log data retention, query data retention, query summary frequency, session timeout, and so on)
Issues
Captured Logs
Query Metrics

Merging Considerations

  • Migrating nodes require Cluster B to be online and both tdqg-manager and tdqg-node on Cluster B to be running QueryGrid version 02.08.00.00 and later. Also, the nodes must be able to access at least one of the QueryGrid Managers in Cluster A. If these conditions are not met, the nodes cannot be migrated and an option to cancel the migration becomes available. The nodes can be re-added using the method used to initially add the node to the system.
  • Object names for objects of the same type must have unique names. During the merging process, if objects in Cluster A and Cluster B share the same name (such as networks, data centers, or fabrics), two options are displayed for the Cluster B object.
    Option Result
    Skip object When the Cluster B object is skipped, the object is not migrated to Cluster A and all references to the Cluster B object are updated to the object in Cluster A with the same name.
    Rename object Rename the Cluster B object and copy the object to Cluster A.

    If a link is renamed, a warning displays that the new link name must be manually updated in the Foreign Server definition.

  • You have the option to merge the fabric from Cluster B with an existing fabric on Cluster A, or you can migrate the fabric.
    Option Result
    Merge The existing name, version, and port are used for the combined fabric. The connectors are added to the newly merged fabric.
    Migrate Potential port conflicts when a fabric is migrated over to a new cluster, may require selecting a new port for the migrated fabric.
  • If an object fails to migrate, you can run the migrate command again and any objects that have already been migrated are automatically skipped.