Roll back problematic mysql db migrations (issue #813)

[peterhaochen47]

This PR, as a whole, rolls back all the DB migrations that caused* #813 but let the postgres migrations (which do not have problems) stay so as to not create unnecessary divergence in users's postgres DB states.

*root cause analysis:

• Credhub version 2.12.69 removes some problematic migrations (mysql migration v57, v58). However, some consumers have already installed prior credhub versions (e.g. credhub 2.12.68) that do contain those migrations, so their flyway history table recorded such.
• Then feat: improve DB query performance #803 and Further improve DB query performance #804, forgetting / not having taken that context into account, added new migrations also numbered with v57, v58; despite having different migration file names, flyway is still not happy with those repeats of migration numbers for those consumers who have installed credhub 2.12.68 for example, causing issue Database migration in credhub-release 2.12.94 fails. #813.
• Hence, remove those problematic mysql migrations for now as a temporary measure, as the removal of the mysql v57, v58 migration numbers is likely a necessity no matter what the eventual solution for re-applying feat: improve DB query performance #803 and Further improve DB query performance #804 is.

[hsinn0]

forgetting / not having taken that context into account

I see. So for the change in 2.12.69, which I think that we deleted the migration sql files, it would have been better if we just changed the content of the sql file instead, i.e. to no-op. Then we could see the last-used migration script verison number in the source.

[hsinn0]

It seems that this deleting migration sql files is going to work. However, can you actually test the upgrade scenario if you have not done so?

[peterhaochen47]

Upgrade scenario testing results:

• 10c7295 (contains mysql/V57_2__delete_related_encrypted_value_when_credential_is_deleted.sql) => 0f61935 (aka right before this PR) => this PR
  • result: this actually is fine and does not actually reproduce Database migration in credhub-release 2.12.94 fails. #813, as this path would only run migration v57_2, and the later added migration v57 is not actually in conflict with v57_2
• b0dd9ef (contains mysql/V58__remove_triggers.sql) => 0f61935 (aka right before this PR) => this PR
  • result: this reproduces Database migration in credhub-release 2.12.94 fails. #813 at step 2, resulting in none of the new migrations being applied because conflict with v58, the flyway history looks like below:
  • and step 3 resolves the issue, the flyway history still looks like below too:

|             72 | 56      | change expiry date in certificate credential                                  | SQL  | V56__change_expiry_date_in_certificate_credential.sql                                  |  -969791477 | root         | 2024-11-12 02:25:49 |             96 |       1 |
|             73 | 58      | index lowercase credential name                                               | SQL  | V58__remove_triggers.sql                                                               |  1764759980 | root         | 2024-11-12 02:25:49 |             29 |       1 |
+----------------+---------+-------------------------------------------------------------------------------+------+----------------------------------------------------------------------------------------+-------------+--------------+---------------------+----------------+---------+

notes

from the mysql migrations directory history, we can see that there was never a v57, only v57_2, which flyway recognizes as different.

If we add back v57, it is still fine after this path: b0dd9ef (contains mysql/V58__remove_triggers.sql) => 0f61935 (aka right before this PR) => this PR, with final flyway history:

             72 | 56      | change expiry date in certificate credential                                  | SQL    | V56__change_expiry_date_in_certificate_credential.sql                                  |  -969791477 | root         | 2024-11-12 02:53:57 |             63 |       1 |
|             73 | 58      | remove triggers                                                               | SQL    | V58__remove_triggers.sql                                                               | -1214956128 | root         | 2024-11-12 02:53:57 |             13 |       1 |
|             74 | 58      | remove triggers                                                               | DELETE | V58__remove_triggers.sql                                                               | -1214956128 | root         | 2024-11-12 02:57:38 |              0 |       1 |
|             75 | 57      | add lowercase credential name column                                          | SQL    | V57__add_lowercase_credential_name_column.sql                                          | -1606535744 | root         | 2024-11-12 02:57:38 |             74 |       1 |
+----------------+---------+-------------------------------------------------------------------------------+--------+----------------------------------------------------------------------------------------+-------------+--------------+---------------------+----------------+---------+

So I think I would opt to add back v57, so one less problem to solve in the future.

[peterhaochen47]

Likely closing this in favor of #815

[peterhaochen47]

closing this in favor of #815