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:
The following tables list the objects that are and are not migrated from the backup file during the migration process.
|Nodes (nodes register themselves as part of the migration process)|
|Manager Settings (log data retention, query data retention, query summary frequency, session timeout, and so on)|
- 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.