Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

When using AWS Aurora, a nullable column can be added to existing large (100k rows+?) tables without causing downtime. However, the migration may still timeout in GoCD - so please coordinate the release with DevOps.

  1. Make a new field addition in model with null=True.
  2. Generate the model-change migrations locally.
  3. Create a pull request containing the model change and newly-generated migrations.
  4. Merge the migration pull request.
  5. The release process will run the migration and add the nullable column to table.

...

On AWS Aurora, indexes can be build on large tables without causing downtime, but this requires devops coordination as the migration may timeout in GoCD.

  1. Add the new index on model fields.
  2. Generate the model-change migrations locally.
  3. Make pull request containing the model change and newly-generated migrations.
  4. Merge the migration pull request.
  5. Release will run the migration and add the index to table.

...

  •  Will the migration cause data loss?
  •  Will this have a performance impact? NB: We do not take maintenance windows for migrations. We vastly prefer to re-engineer the migration than to schedule a maintenance window and virtually all migrations should be able to be engineered to avoid downtime by being additive-only
    •  Is the migration against a large table (see section below) ?
    •  Is the migration against a busy/highly contentious table (many writes/deletes/etc - see section below)?
      •  For the community, if we anticipate a potentially significant migration, make a note on the Open edX Release page for the next release
    •  How long do you expect the migration to take to run? Options include naive local testing, using 158766629 or some other synthetic method that might give you a reasonable framework to guess / extrapolate from
    •  Do you expect the migration to block queries, particularly frequent / user facing ones? This is
      •  For example, adding/modifying indexes on non-Aurora databases
  •  Is the migration backward compatible? Does it remove or edit a schema that the previous version of the code expects to be there?

...