Database migration in credhub-release 2.12.94 fails. #813
Comments
cf-foundation-community-automation
bot
moved this to Inbox
in Foundational Infrastructure Working Group
peterhaochen47
added a commit
that referenced
this issue
Nov 11, 2024
- due to issue #813 (with mysql) we have rolled back all DB related changes: 030302a 873bc6d 34afece which we previously released. - since theere is no issue with postgres, it safer to NOT remove the already-released DB migrations so that various consumers's postgres DB states do not diverge. So this commit brings back all those already-release postgres DB migration.
peterhaochen47
added a commit
that referenced
this issue
Nov 12, 2024
- mysql migration v58 failed flyway validation because there was a prior migration also numbered v58 (082fd5e) which had since been removed but nevertheless was recorded in flyway history for those users who have installed credhub versions containing the old v58, hence creating a conflict with the new v58. Hence, this commit removes the new v58 for now to fix the issue for those users. - leaving v57 alone because there was never a v57 before, only v57_2, which flyway treats as distinct from v57. See code history here: https://github.com/cloudfoundry/credhub/commits/main/applications/credhub-api/src/main/resources/db/migration/mysql - we will try to add back the index (in this removed v58) later in a safe way. - also: leaving postgres & H2 migrations intact because there is not a problem there.
peterhaochen47
added a commit
that referenced
this issue
Nov 12, 2024
- mysql migration v58 failed flyway validation because there was a prior migration also numbered v58 (082fd5e) which had since been removed but nevertheless was recorded in flyway history for those users who have installed credhub versions containing the old v58, hence creating a conflict with the new v58. Hence, this commit removes the new v58 for now to fix the issue for those users. - leaving v57 alone because there was never a v57 before, only v57_2, which flyway treats as distinct from v57. See code history here: https://github.com/cloudfoundry/credhub/commits/main/applications/credhub-api/src/main/resources/db/migration/mysql - we will try to add back the index (in this removed v58) later in a safe way. - also: leaving postgres & H2 migrations intact because there is not a problem there.
|
Fixed by #815 |
github-project-automation
bot
moved this from Inbox
to Done
in Foundational Infrastructure Working Group
peterhaochen47
added a commit
that referenced
this issue
Nov 12, 2024
- context: the performance improvement brought by indexing (#803) was reverted (#815) due to migration error (issue #813) for some users. This commit brings back that index, but doing so safely to avoid issues like #813 (#813 happened to some users due to migration file numbering conflict, this commit uses a fresh migration number (v59) to avoid that). - Unfortunately, for the users who happened to have installed credhub v2.12.94 successfully (aka did not encounter #813), their mysql DB would already have an index called "credential_name_lowercase". So in order for the migration in this commit to work for both those who have installed credhub v2.12.94 and those who have not, this commit's migration instead creates the index under a different name: "credential_name_lowercase_index" (mysql does not support the "CREATE INDEX...IF NOT EXIST" syntax). This would create some DB inefficiency (due to the presence of two functionally identical indexes) for those who have installed credhub v2.12.94 (which we think is a smaller subset of users), but the system would still work and likely a net improvement compared to before due to the presence of indexing. And we would instruct these users to manually drop the old, duplicate index ("credential_name_lowercase").
peterhaochen47
added a commit
that referenced
this issue
Nov 13, 2024
- context: the performance improvement brought by indexing (#803) was reverted (#815) due to migration error (issue #813) for some users. This commit brings back that index, but doing so safely to avoid issues like #813 (#813 happened to some users due to migration file numbering conflict, this commit uses a fresh migration number (v59) to avoid that). - Unfortunately, for the users who happened to have installed credhub v2.12.94 successfully (aka did not encounter #813), their mysql DB would already have an index called "credential_name_lowercase". So in order for the migration in this commit to work for both those who have installed credhub v2.12.94 and those who have not, this commit's migration instead creates the index under a different name: "credential_name_lowercase_index" (mysql does not support the "CREATE INDEX...IF NOT EXIST" syntax). This would create some DB inefficiency (due to the presence of two functionally identical indexes) for those who have installed credhub v2.12.94 (which we think is a smaller subset of users), but the system would still work and likely a net improvement compared to before due to the presence of indexing. And we would instruct these users to manually drop the old, duplicate index ("credential_name_lowercase").
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of the credhub server you are using?
We are trying to upgrade to credhub-release 2.12.94 with MySQL as database.
What version of the credhub cli you are using?
Not relevant, server-side problem.
If you were attempting to accomplish a task, what was it you were attempting to do?
Upgrade cf-deployment from v44.6.0 to v44.7.0. The credhub-release version is upgraded from 2.12.93 to 2.12.94.
What did you expect to happen?
Upgrade of credhub server succeeds.
What was the actual behavior?
Upgrade failed because of a flyway migration error. Output from credhub.log is:
Last entries in
flyway_schema_historytable:The problem is introduced with PR #803. It adds a new migration file
V57__add_lowercase_credential_name_column.sql. However, a previous migration with versionV57.2was executed some time ago. Could this issue be fixed by assigning a higher version number to theadd_lowercase_credential_name_columnmigration file?Please confirm where necessary:
If you are a PCF customer with an Operation Manager (PCF Ops Manager) please direct your questions to support (https://support.pivotal.io/)
The text was updated successfully, but these errors were encountered: