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:
- Backup one of the QueryGrid Managers in Cluster B.
- Copy the Cluster B backup to a QueryGrid Manager on Cluster A.
- Run the migrate command on Cluster A with the backup from Cluster B.
- Join the QueryGrid Managers from Cluster B to Cluster A.
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.