Rename instance_statistics_measurements_table
What does this MR do?
This MR renames the analytics_instance_statistics_measurements
table following our rename table guidelines: https://docs.gitlab.com/ee/development/database/rename_database_tables.html#release-nm1-rename-the-database-table
Rollout and verification
The rename table process was tested locally and we don't expect problems on production. This is the first time these database migration helpers are used, so I'm adding extra verification and emergency rollback steps here.
-
Tested on staging, the page should load: https://staging.gitlab.com/admin/usage_trends -
Tested on staging rails console: Analytics::UsageTrends::Measurement.last
-
Tested on canary, the page should load: https://gitlab.com/admin/usage_trends -
Tested on production, the page should load: https://gitlab.com/admin/usage_trends -
Tested on production rails console: Analytics::UsageTrends::Measurement.last
Rollback and troubleshooting
Note: The database table (analytics_instance_statistics_measurements
) is only used on the admin interface. In case of problems, the user-facing features of GitLab should not be affected.
When monitoring for errors, look for the analytics_instance_statistics_measurements
or analytics_usage_trends_measurements
strings.
CNY uses the new version of the app, PRD uses the old version of the app
When table related errors happen in this step, the following mitigation steps can be followed:
- The CNY application version needs to be rolled back to the previous version to fix the error immediately.
- Stop deploying new code.
- Create a revert MR for
FinalizeRenameInstanceStatisticsMeasurements
andRenameInstanceStatisticsMeasurements
where thedown
andup
methods are reversed.
Migration
UP:
== 20210531053916 RenameInstanceStatisticsMeasurements: migrating =============
-- rename_table(:analytics_instance_statistics_measurements, :analytics_usage_trends_measurements)
-> 0.0045s
-- execute("CREATE VIEW analytics_instance_statistics_measurements AS SELECT * FROM analytics_usage_trends_measurements")
-> 0.0009s
== 20210531053916 RenameInstanceStatisticsMeasurements: migrated (0.0101s) ====
== 20210531054108 FinalizeRenameInstanceStatisticsMeasurements: migrating =====
-- execute("DROP VIEW IF EXISTS analytics_instance_statistics_measurements")
-> 0.0009s
== 20210531054108 FinalizeRenameInstanceStatisticsMeasurements: migrated (0.0062s)
DOWN:
== 20210531054108 FinalizeRenameInstanceStatisticsMeasurements: reverting =====
-- execute("CREATE VIEW analytics_instance_statistics_measurements AS SELECT * FROM analytics_usage_trends_measurements")
-> 0.0012s
== 20210531054108 FinalizeRenameInstanceStatisticsMeasurements: reverted (0.0051s)
== 20210531053916 RenameInstanceStatisticsMeasurements: reverting =============
-- execute("DROP VIEW IF EXISTS analytics_instance_statistics_measurements")
-> 0.0015s
-- rename_table(:analytics_usage_trends_measurements, :analytics_instance_statistics_measurements)
-> 0.0052s
== 20210531053916 RenameInstanceStatisticsMeasurements: reverted (0.0337s) ====
Local testing
I tested the migration process in Virtualbox (ubuntu) using the GitLab 13.12.1-ee
package. These steps will test the critical part of the migration when the table is renamed, while the old version of the application is running.
Steps:
- Create a virtual machine.
- Install ubuntu.
- Install GitLab: https://about.gitlab.com/install/#ubuntu
- Make sure GitLab is up and running.
- Start rails console and execute:
Analytics::UsageTrends::CountJobTriggerWorker.new.perform
- Go to the Admin interface and navigate:
Monitoring -> Background Jobs
- Go to the scheduled tab and add all jobs to the queue
- Go to
Analytics -> Usage Trends
and verify that some figures show up (mostly 0s and 1s) - Copy the
RenameInstanceStatisticsMeasurements
database migration and move it to themigrate
folder somewhere in/opt/gitlab/...
- Execute the database migration:
gitlab-rake db:migrate
- Verify that the usage trends page is still working. At this point, the table is renamed.
- Restart GitLab and verify that the page is still working:
gitlab-ctl restart
Does this MR meet the acceptance criteria?
Conformity
-
I have included a changelog entry, or it's not needed. (Does this MR need a changelog?) -
I have added/updated documentation, or it's not needed. (Is documentation required?) -
I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?) -
I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?) -
I have self-reviewed this MR per code review guidelines. -
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides.
Availability and Testing
-
I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.) -
I have tested this MR in all supported browsers, or it's not needed. -
I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.
Security
Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team