| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Using mqsirestorebroker as a deployment approach. |
« View previous topic :: View next topic » |
| Author |
Message
|
| alaychem |
 Posted: Mon Aug 27, 2018 3:48 am Post subject: Using mqsirestorebroker as a deployment approach. |
 |
|
Acolyte
Joined: 10 Feb 2016
Posts: 66
|
An ESB team at my work place is using mqsibackupbroker on a pre-prod environment (with the same OS, broker names and QM names), and then mqsirestorebroker, to perform whole-state deployment.
The team says it's a faster way to deploy then calling mqsideploy on every bar file.
Are there any disadvantages with their approach? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Aug 27, 2018 4:59 am Post subject: Re: Using mqsirestorebroker as a deployment approach. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| alaychem wrote: |
| Are there any disadvantages with their approach? |
The obvious one is having 2 queue managers with the same name on the same estate, which is a recipe for disaster.
I think you should also question how they've managed to have everything they use (web end points, ftp source and target, etc., etc.) the same in QA and Prod with the same security credentials working in both environments. The first point is a great way for test data to escape into Prod (and if they're testing something customer facing, your customers could get some unexpected emails). The second point is a data breach my cat could get through!
I wonder how they're controling what's being deployed to QA, and thereby controlling what you're running in Prod.
| alaychem wrote: |
| The team says it's a faster way to deploy then calling mqsideploy on every bar file. |
Faster than what? I bet I can trigger a script that deploys all their bar files faster than they can type a backup command, copy the file and type the restore command. If they're using a script to run the backup, why aren't they running a script to deploy the files.
If their answer is "the backup / restore takes less elapsed time than all the deploys" then what, exactly, is the hurry? If they're running a backup /restore pair at 2am that finishes by 3am, and a similar deploy script doesn't finish until 5am, so what? Are they charged by the elapsed second for server use?
There is nothing about this that makes sense.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 28, 2018 1:59 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Vitor didn't mention it, but backup and restore procedures are only meant to be running in the same environment.
Imagine all your configurable services have now a different value (pre prod instead of prod) and all your policies (and I am thinking specifically at the endpoint defining policies) are wrong and picking up messages from the wrong environment.
If you have a complete break down you should have everything scripted and be able to restore the environment via the scripts and deploys.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
