Is there a supported way to manually create/configure Failover from a MySQL based DMA that is already in service using a Backup of the active DMA. I ask because I often have to build/rebuild FO starting with a single DMA with a MySQL database of significant size (~100G) and when creating the FO configuration through the Cube’s standard way the automatic database sync is either unreliable, takes very long (multiple days) and/or results in RTEs and large numbers of SLDataminer thread problems with ReplicationDBTread notices getting logged. I assume this is due to the failover database sync mechanism having to compete with the standard database syncing happening on the system due to the level trending that the system. For example, I am currently building a FO from a DMA that has the MySQL sldmadb folder ~110G and it has been syncing for 2 days and is only about 2/3 complete and has been logging endless ReplicationDBTread notices and now a Replication thread RTE.
I know that I can take a full backup of the primary DMA ~1 Hr copy it over to the BU DMA and recover the DMA from the backup in just a couple of hours. So back to my main question:
- Is there a way to manually force a FO config say using a full backup and making changes to the DMS.xml file.
- Is there a way to interrupt/stop the current FO dbase sync that is in process? If I could do that then I could just manually export the database from the PRI DMA and then simply Import it into the BU DMA.
- Is there any other recomendations on how to config FO from a MySQL base DMA with a database of any real world size, say 50G or larger
I have a customer’s production system with dbase ~ 150G that I need to config FO on in the next few days and do not want any issues.
Thanks for any advice.
Hi Jeff
- From my testing, it looks like the DMS.xml file isn’t included in the DM backups so this option wouldn’t really work.
- Not that I’m aware of since this would most likely create more issues since it would break the sync process
- My recommendation would be to get a full backup of the primary DMA prior to creating the failover configuration. Restore this backup package on to the standby agent while still in standalone configuration. Once the restore process has finished, create the failover setup. I tested this on our internal lab and I did not see any duplicate DataMiner views, elements, protocols, etc., nor did I see the DB have duplicate information.
Thanks Luis,
1) My idea for item #1 was similar to your suggestion except I was basically asking if after using the backup package created from the PRI single threaded DMA on the new BU DMA you could then just manually edit the DMS.xml files on both DMAs to represent Failover config and restart the DMAs. This way I would think would keep the PRI from trying to sync the database to the BU DMA
2) In your suggestion, once you go through the standard Failover config process wont the PRI DMA attempt to Sync the dbase over to the BU DMA even though it already has the complete database? Can you test that by performing your suggested procedure but before configuring FO delete the “System Cache/FailoverSync” folder on the PRI and then monitor it after configuring Failover. I believe that if the PRI starts trying to sync the dbase to the BU DMA then you will see this in this folder?
As this question has been inactive for a long time, we will now close it. If you still want further information, could you post a new question?