Announcement

Collapse

Mirth Connect 3.12.0 Released!

Mirth Connect 3.12.0 is now available as an appliance update and on our GitHub page. This release includes database performance improvements, improves visual HL7 representation, message pruning, keystore handling, PDF generation, community contributions, and fixes several security vulnerabilities. This release also contains many improvements to commercial extensions. See the release notes for the list of fixes and updates.

Download | See What's New | Upgrade Guide | Release Notes

For discussion on this release, see this thread.
See more
See less

"best practice" or advice for managing upgrades?

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

  • "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.
    Jon Bartels

    Zen is hiring!!!!
    http://consultzen.com/careers/
    Talented healthcare IT professionals wanted. Engineers to sales to management.
    Good benefits, great working environment, genuinely interesting work.

  • #2
    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.

    Comment


    • #3
      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.
      Jacob Brauer
      Director, Software Development
      NextGen Healthcare

      sigpic

      Comment


      • #4
        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.
        Jon Bartels

        Zen is hiring!!!!
        http://consultzen.com/careers/
        Talented healthcare IT professionals wanted. Engineers to sales to management.
        Good benefits, great working environment, genuinely interesting work.

        Comment

        Working...
        X