The admins would much prefer to move away from the use of glastDB and glastCalibDB in favor of mysql-node01 and mysql-node03. This can be an incremental change as I understand it. For CMT RM, this should not be a problem, there is one script involved that would require modification. I cannot speak for FSW or calibrations or opsLog. Hopefully those involved with those particular databases can chime in.
Note from Arash June, 2012
Panel |
---|
bgColor | yellow |
---|
borderStyle | solid |
---|
|
Right now, we're using aliases to point to our MySQL service nodes, e.g., mysql-node01, mysql-node02, mysql-node03, etc.. Each node has two servers, and at any time one server is primary and the other is standby. We move these aliases when we fail over and switch from one server to another. If you keep the glastDB and glastCalibDB aliases indefinitely going forward, it means db-admin now have additional, project-group-specific aliases on the MySQL servers that we would need to manage every time there is a switchover/failover. So the question is, will your group gradually modify your code to migrate out of the glastDB and glastCalibDB aliases, or will db-admin have to manage these additional aliases going forward? From db-admin's perspective, this is not a sustainable way of managing the service; imagine if every project group wanted to have their own aliases attached to our servers. Still, as it is it is only your group that has these aliases, and if you cannot modify your code by spending a reasonable amount of effort, to move away from using the aliases, then db-admin will have to manage them going forward. One way to make the process of managing the aliases less error prone, is to change them from being managed in CANDO, to being A-records that db-admin can script to bring up and down with our other aliases after a failover. I think all that is needed to do this is to change the IP address associated with the aliases. The names glastDB and glastCalibDB will remain the same. Cheers, |