I am facing a data synchronization challenge involving two geographically separated IBM MQ queue managers located in different data centers. I need to achieve real-time data replication and synchronization between these queue managers on the AIX Power platform. However, the traditional approach of using multi-instance queue managers with shared file systems is not applicable in this scenario due to the physical separation of the data centers.
Setup: I have two IBM MQ queue managers, one in Data Center A and another in Data Center B, both running on the AIX Power platform. These centers are separated by a considerable geographic distance.
Requirement: My goal is to ensure real-time or near-real-time data synchronization between these queue managers, so that messages sent to one queue manager are automatically replicated and available in the other.
It's important to note that IBM MQ data and log files are typically in a proprietary format and actively managed by the messaging system. Using a general-purpose tool like rsync won't be suitable for this purpose because it's not aware of the specific format and requirements of IBM MQ data and log files.
- What are the best practices for setting up real-time data synchronization between geographically separated IBM MQ queue managers running on the AIX Power platform?
- Are there specific IBM MQ features or solutions optimized for this scenario, especially when dealing with AIX Power?
- Are there any third-party tools or strategies that are well-suited for achieving real-time data replication in a geographically distributed environment, considering the AIX Power platform?
Other MQ technologies like Native HA and RDQM would be the likely choice for other platforms/deployment options.
But for AIX, I'd be looking at using IBM Storage Scale (aka GPFS) as the mechanism to do disk-level replication. You'd have to manage the failover to the DR site yourself, but the qmgr data/logs would be there to take over. Sync/async choices on the replication would determine how out-of-date the remote site is, but it would still be "reliable" and recoverable.