Announcement

Collapse
No announcement yet.

"best practice" or advice for managing upgrades?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • jbartels
    replied
    Re:

    jacobb wrote:
    That sounds like a decent path, jbartels. How are you going to route a copy of ALL messages to the 1.7 machine?
    This instance of Mirth exists as a message router to begin with so its getting EVERYTHING coming into our hosted environment.

    Leave a comment:


  • jacobb
    replied
    Re:"best practice" or advice for managing upgrades?

    That sounds like a decent path, jbartels. How are you going to route a copy of ALL messages to the 1.7 machine? You'd have to hook into each channel and resend the source message. An easier path, if possible, would be to have the senders send a second copy to the other mirth IP.

    Streamlining upgrading is something we will definitely look at improving in Mirth 2.0. Any suggestions people have would be much appreciated.

    Leave a comment:


  • dfelton
    replied
    Re:"best practice" or advice for managing upgrades?

    We migrated VM's + hardware and upgraded versions in our production environment last week, using virutally the same approach you've described. Downtime occurred in the equivalent of your step 6, amounting to about 15 seconds while we changed NIC IP addresses. I considered that acceptable, especially because nobody noticed a blip. I'd do it the same way again.

    Leave a comment:


  • jbartels
    started a topic "best practice" or advice for managing upgrades?

    "best practice" or advice for managing upgrades?

    We've got a critical production system running Mirth 1.6 that we would like to upgrade to 1.7. I'm looking for suggestions, ideas, and advice for how to manage this without taking the system down for too long.

    The machine is running as a VM on ESX Server so we've got a lot of options for making backups and running two at once.

    My plan is:

    1. Create a new VM with the same specs.
    2. Install Mirth 1.7 to that
    3. Import my channels to it from the 1.6 machine
    4. Set up a new channel on the 1.6 machine to route a copy of messages to the 1.7 machine
    5. Confirm that our destinations are getting messages from each machine correctly.
    6. Take the 1.6 machine offline and route messages directly to the 1.7 machine. I would probably do this by just updating the DNS record or using tools in ESX to swap the virtual NICs around.

    Step 6 is the critical one where we would see a small blip of downtime.

    Is there a better way to handle this? I trust the Mirth software to work well, but I want to minimize downtime as much as possible.
Working...
X