Are upgrade instructions AWS Standard Edition 5.0.2(5) to 6.0.0 available?

Support
71

Okay, here is the process that I am currently following for the AWS OpenEMR 5.0.2(5) Cloud STANDARD to 6.0.0(1) upgrade. I have successfully upgraded twice using this procedure. Note that I cannot upgrade the existing EC2 because the docker volume is not big enough to accommodate 6.0.0. Thus, I had to create a duplicate system and then upgrade it. For some reason, when I create a new system using the cloudformation stack, the docker volume now has plenty of space.

Note that if the docker volume has enough room, it isn’t necessary to create a test system to upgrade, but it may be desirable to create and upgrade a test system just to make sure the desired upgrade procedure works.

Also, I’m not always 100% on whether to put a trailing / on the copies … if the files go into a subdirectory of where they should be, go in there and copy them out cp * …/

Anyway, here is my draft procedure. I was able to get it to work twice, and I am quite confident it works … although there may be minor errors that intelligent users should be able to compensate for. This will also allow you to test the upgrade (if it doesn’t work, you still have your relatively untouched production system).
One thing that is very touchy (can cause the webserver not to respond) is what the file permissions and ownership are on the openemr site. Compare the site on the production system and test system when in doubt.

Preparation:

  1. Make sure no one is currently using the system or will try to log into it for several hours.
  2. Back everything up. Create an AMI (image) of the production EC2 instance. Create a snapshot of the database RDS instance.
  3. Get authorization from AWS to have more than the default number of VPC 's so that you can create OpenEMR systems in other regions.
  4. Choose a new region (such as Ohio or any region you are not using currently on your continent)

Creating a duplicate system of your production OpenEMR STANDARD system

  1. Run cloudformation Stack from the Marketplace Openemr Standard edition, which you should already have a license for.
  • Be careful to choose a region OTHER THAN THE CURRENT REGION of your production OpenEMR system (the system you are using now).
  • Choose the latest 5.0.2 (or whatever version you are upgrading from)
  • Make careful note of the passwords for the administrator and database you use in your cloudformation stack.

  1. After the cloudformation stack has successfully completed, “apply immediately” every recommendation for the new RDS database instance (upgrading to 5.7.xx, GP2 instead of magnetic storage, etc.).

  2. Patch the system to the patch level you used (such as v5.0.2p5) in your production system so that everything is as similar as possible to your production system.

  3. Encrypt and replace and resize to 200GB the root volume of the duplicate system EC2. This involves making a snapshot of the root volume, copying the snapshot with encryption enabled, creating a new volume with the encrypted copied snapshot (and enlarging it to 200 GB at the same time), noting the device /dev/sda1 or whatever of the root volume, stopping the duplicate system EC2, detaching the current root volume, and attaching the encrypted, enlarged (new) root volume to your instance, and starting the duplicate EC2 back up.

On the duplicate OpenEMR system:

  • Add inbound ssh ip address you will need to connect to your new EC2 (security group change)
  • ssh to the test EC2 instance. Reboot if required. Then do a sudo apt update, and a sudo apt upgrade.
  • Consider changing the RDS instance to a type t3 instance type - it should have better performance at an identical or better price than the t2s. Unfortunately, the EC2’s can’t be upgraded hardware-wise this way.
  • Enable RDS storage autoscaling
  • Change rds backup retention to 14 days.
  • Enable enhanced monitoring.
  • Enable EC2 all log exports
  • Enable RDS performance insights
  • If necessary, make the following change so that the sudo apt update is successful: https://stackoverflow.com/questions/61074587/why-do-i-see-failed-to-fetch-error-while-dping-apt-get-update
  • Go to the new EC2 instance IP address with a browser (probably will need to use HTTP:// to connect). Make sure that the test system allows users to log in and seems to work.

Creating the mysqldump backup of the production database

  1. Perform a mysqldump of your existing database. NOTE THAT THIS WILL FREEZE ANY USERS OF THE SYSTEM UNTIL THIS IS COMPLETE.
  • Here is an example template of the command you should use (make sure your system is large enough to hold your database, which could be huge. If not, you will need to enlarge the root volume of your production EC2 first – I recommend at least 200GB, but yours might even need to be larger - check your database size!)

mysqldump -h fr1xhyxxxxxxx.cydpyyyyyy.us-east-1.rds.amazonaws.com --set-gtid-purged=OFF -u openemr -p openemr > mysqldumpfile-2021-06-06-2130h

where fr1xhyxxxxxxx.cydpyyyyyy.us-east-1.rds.amazonaws.com is the endpoint address of your PRODUCTION RDS database instance (you are copying your production data into a SQL file),.

  1. Make sure that your Production and Duplicate EC2 instance both have AmazonS3FullAccess permissions so that they can copy and write to S3 buckets. If not, go to the IAM role of your instance(s) and add a full permissions S3 policy (just search for S3). Otherwise, you won’t be able to use S3 to copy your system data.

  2. Copy the mysqldumpfile-2021-06-06-2130h to an S3 bucket of your choice (you may need to set one up if you don’t have any ready).
    The command will probably look something like this:
    sudo aws s3 mv mysqldumpfile-2021-06-06-2130h.sql s3://openemr-v502p5-2021-06-06-migration-data/

  3. Copy the openemr directory from the production instance to the duplicate instance EC2 file system to copy the documents from the EMR
    The command is as follows:
    sudo docker cp standard_openemr_1:/var/www/localhost/htdocs/openemr/ openemr-v502p5/

Then move this directory to an s3:
sudo aws s3 mv openemr-v502p5/ s3://openemr-v502p5-2021-06-06-migration-data/openemr-v502p5/ --recursive

Install the database on the duplicate OpenEMR system

  1. copy the mysqldump.sql file from s3 to the new (duplicate) EC2 test instance file system.
    The command to copy this file will look like this:
    sudo aws s3 cp s3://openemr-v502p5-2021-06-06-migration-data/mysqldump-v502p5-2021-06-06-1615h.sql

Also copy the openemr directory from the production system that was copied to s3:
sudo aws s3 mv s3://openemr-v502p5-2021-06-06-migration-data/openemr-v502p5/ openemr-v502p5/ --recursive

  1. Create a new parameter group for the duplicate RDS instance. Search for and replace every “timeout” containing parameter (except slave related) with maximum allowable so that the large mysqldump import does not time out.

  2. Install mysql client with sudo apt-get install mysql-client if necessary and Restore the mysqldump of the copied clinic OpenEMR mysqldump database backup file to the test RDS system database

The command will look something like this:
mysql -h xxxxxxxrrrrrssssss.ffaass33gg22.us-east-2.rds.amazonaws.com -u openemr -p openemr < mysqldumpfile-2021-06-06-2130h

where xxxxxxxrrrrrssssss.ffaass33gg22.us-east-2.rds.amazonaws.com is the new (duplicate) RDS instance

  1. Log into the duplicate OpenEMR system by opening the IP address of the duplicate Ec2 instance in a web browser.

Next, attempt to upgrade the duplicate system from 5.0.2p5 to 6.0.0:
16. Download the distribution of OpenEMR 6.0.0 Linux onto your personal computer and then transfer it to the duplicate EC2 (or do so directly if you know how using wget, for example).

  1. Backup the sqlconf.php file from the duplicate OpenEMR system:
    sudo docker cp standard_openemr_1:/var/www/localhost/htdocs/openemr/sites/default/sqlconf.php .

  2. Expand the 6.0.0 distribution onto the duplicate EC2 system file system rather than the openemr directory to have a bit more control of what happens in this step.
    tar -pxvzf openemr-6.0.0.tar.gz

  3. Copy the 6.0.0. distribution into the docker, overwriting the 5.0.2p5 files that are there.

  4. Copy the 5.0.2p5 documents into the openemr/sites/default/documents directory:
    sudo docker cp openemr-v502p5/sites/default/documents/
    standard_openemr_1:/var/www/localhost/htdocs/openemr/sites/default/documents
    (see where they went and, if necessary, move them out of a subdirectory)

  5. Make sure all the permissions are correct. Generally, go to the openemr site and execute chwon -R apache:apache * to change the owner. You may also need to change some read, write, and execute permissions.

  6. Open openemr/sql_upgrade.php (http://yourEC2ip/openemr/sql_upgrade.php) in web browser, choose 5.0.2 and click ‘Upgrade Database’

  7. Configure optional settings in openemr/sites/default/config.php files

  8. Log into the duplicate system and make sure all the data migrated properly by checking several charts and appointments. You may want to let your users test it out and make sure it is working.

  9. At some point, install 6.0.0 patch 1.

  10. Delete the sql_patch.php and sql_upgrade.php files … unless you like to leave scripts like that lying around for anyone to execute :wink:

Like I said above. I got this to work once. Still trying to reproduce it a second time. Feel free to correct any errors.

–RBL