Merge QueryGrid Manager Clusters | Overview | QueryGrid - Overview of Merging QueryGrid Manager Clusters - Teradata QueryGrid

QueryGrid™ Installation and User Guide - 3.06

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
Lake
VMware
Product
Teradata QueryGrid
Release Number
3.06
Published
December 2024
ft:locale
en-US
ft:lastEdition
2024-12-07
dita:mapPath
ndp1726122159943.ditamap
dita:ditavalPath
ft:empty
dita:id
lxg1591800469257
Product Category
Analytical Ecosystem
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, run the migrate command again. Any objects that have already been migrated are automatically skipped.