Upgrade RDS Databases from MySQL 5.6 to 5.7

This article describes the upgrade path and expectations for IDAs moving from MySQL 5.6 to 5.7

External Links

• Product Deck

• Other Upgrades https://openedx.atlassian.net/wiki/pages/createpage.action?spaceKey=SRE&title=Upgrade%20Activity

• PSRE Epic: https://openedx.atlassian.net/browse/OPS-4627

Engineering Team Instructions

1. Coordinate with product to determine an upgrade timeframe for devstack.

   1. Update the “Planned 5.7 DevStack Upgrade” column below.

   2. Please link any created tickets to https://openedx.atlassian.net/browse/OPS-4652

2. Identify dependency changes

   1. If your app uses any python database libraries, please update these.

3. Upgrading Devstack

   1. Find your app’s docker-compose block(s) in https://github.com/edx/devstack

   2. Update your apps container to point at mysql57 instead of mysql and update any related make commands.
      (e.g. https://github.com/edx/devstack/blob/a76042b19aeb8fc8b02d93d3db4be783a54a0be1/docker-compose-marketing-site.yml#L15 )

   3. If possible run e2e tests to see if the change causes any issues.

   4. Merge your PR and notify engineering if any manual steps are needed to recreate data locally.
      (e.g. make dev.dbcopy57.<service> , see 10/6 “Discovery switching to mysql 5.7” email thread from Mike for examples)

   5. If manual steps are needed and your service is an Open edX service, please also post to Discourse (e.g. https://discuss.openedx.org/t/discovery-switching-to-mysql-5-7/3360) and add make sure the Koa release planning notes reflect your changes.

   6. If you learned any lessons that would be valuable to other teams, please describe or link to them here.

4. Upgrading Travis or CircleCI

   1. Make sure that whatever Travis or CircleCI tests you have which use MySQL are using a 5.7 container. (e.g. https://github.com/edx/xqueue/pull/783/files)

5. Upgrading Sandboxes

   1. SRE will be upgrading Sandboxes before we upgrade stage with this PR: https://github.com/edx/configuration/pull/5695/files

   2. However you may need to coordinate the timing of persistent sandbox deployments.
      (e.g. partner registrar sandboxes should get rebuilt after prod gets upgraded, int sandboxes get upgraded ahead of time)

6. Be on the lookout for any performance impacts once SRE notifies you that stage and prod are being upgraded.

   1. Note: RDS Aurora MySQL Databases will likely require downtime, but RDS MySQL databases can be upgraded without downtime.

   2. If there are downtime constraints for prod please let the SRE team know, we will be estimating the downtime and choosing which upgrade path makes the most sense and will be attempting to

 Significant Changes since 5.6

• As of right now we only know of improvements, however, some libraries like django-mysql <1.0.6 do not support MySQL 5.7 and may need to be updated (edx-platform is on 3.0.0). We also may use some features of MySQL 5.6 that are no longer available in django-mysql or mysqlclient.

Site Reliability Team Instructions

• The SRE Team is tracking each stage, prod and edge database upgrade under this Jira epic: https://openedx.atlassian.net/browse/PSRE-301

• As each of our services have different requirements (owners, data pipelines), each database upgrade may have specific steps required.

• Each of the services in the diagram below (except Forums, Prospectus & Marketing), has a MySQL database that will be upgraded to Aurora 5.7, in addition to the service, our data pipelines also connect to these databases so special care should be taken to ensure those pipelines and the downstream reports are not impacted by the upgrades.

• At least the LMS, Ecommerce, Discovery, License Manager, Enterprise Catalog, Demographics and Credentials services also have DBT generated Snowflake views described here, please be sure to sync with DE about requirements before doing each cutover.

• At least LMS and Ecommerce have Jenkins EMR and/or Swoop jobs, these jobs should be checked carefully before and after each respective cutover.

Open

(lucid chart link)

The current proposed order for updating our databases is here (please keep this in sync with https://openedx.atlassian.net/wiki/spaces/DE/pages/1961558140/Updating+Stitch+Integrations+for+MySQL+5.7+Upgrade#Tentative-Upgrade-Order ):

1. Notes (SRE) - Done on 10/23 (not on Aurora)

2. Discovery & Ecommerce (Engagement) (not on Aurora)

   1. Discovery - Done on 10/29

   2. Ecommerce - Done on 11/17 @ 10pm

3. Credentials and Demographics (Aperture)

   1. Credentials - Done on 11/17 @ 3pm

   2. Demographics - Done on 12/7 @ 10am

4. Registrar and Portal Designer (Masters)

   1. Registrar Target - Done on 12/2 @ 10am

   2. Designer Target - Done 12/9 @ 10am

5. Analytics API and Insights (DE)

   1. Prod Analytics API and Analytics Data - Done 12/17 @ 10am-12pm ET

   2. Edge Analytics - Done for 12/18 @ 10am-12:11pm

6. XQueue (T&L)

   1. Move Stage xqueue schema from edxapp db to shared db Done

   2. Prod Xqueue Target -Done on 1/5 @ 10am

7. License Manager, Enterprise Catalog, Blockstore, Video Encode Manager (Enterprise, T&L, Incident Management)

   1. Shared Cluster - Done

8. Platform (Arch + TNL):

   1. Stage edxapp - Done on 1/25

   2. Edge edxapp - Done on 1/27

   3. Prod csmhe & edxapp - Done on 2/2

Communications Plan

Note: These steps may be followed twice if we do a segmented upgrade to support TLS 1.2 first on 5.6.48 before going to 5.7 (e.g for notes)

Stage:

1. We will be sending out a message to #dev and @'ing @sre-team + the technical owners listed below for each stage database upgrade, if you would like to be on the cc list for a specific service please add your name to the column.

   1. At the service owner or SRE team members request we will cross post announcements to #warroom or other channels. (note, we may also pause pipelines)

2. Once maintenance is complete & any pipelines are unpaused we will post in the #dev announcement thread with “also send to channel” checked to let engineers know that their services should be back up should notify us if they see anything unusual.

3. At the service owners request we will communicate to a specified engineer or channel to ask them to manually run smoke tests or trigger e2e tests.

Prod & Edge:

1. We will be coordinating any required maintenance windows with the business and technical owner for each service which will be documented in the table below and the corresponding tickets.

   1. At the service owners request we can also include external contractors who are impacted in this coordination (e.g. OpenCraft/LabXchange).

2. At the service owners request we will post a status.edx.org maintenance window, which will usually be either 1pm-2pm or 1am-2am depending on which engineers need to be available, on status page, (e.g. https://status.edx.org/incidents/v1n8lpl6sz13 - we will not be posting to status page for edge notes)

3. We will post an announcement in #warroom and @'ing @sre-team + @status + the service owners at the beginning of the maintenance window.

   1. At the service owners request we will cross post #warroom announcements to other channels (e.g. #partner-support)

4. Once maintenance is complete we will perform an appropriate smoke test, update the status page.

5. We will update the announcement thread with “also send to channel” checked to let engineers know that their services should be back up should notify us if they see anything unusual.

Read Replicas:

1. Read Replicas (e.g. for Platform, Ecommerce & Discovery) will be handled on a case by case basis.

Timeline