Primary key required in MySQL DB clusters #16802
Labels
type/enhancement
An improvement of existing functionality
Comments
|
Could you give more logs, if you can enable log level to info, some information like |
|
@lunny log level is set to info in conf and this is the output of a fresh installation: And this is log of migration from 1.14: |
|
Looks like the problem is related to |
|
Yes. So v1.15, we have a new table So |
|
It Is not really necessary, but it helps a lot while managing DB clusters.
https://docs.digitalocean.com/products/databases/mysql/how-to/create-primary-keys/#how-digitalocean-uses-primary-keys%3Chttps://www.digitalocean.com/docs/databases/mysql/how-to/create-primary-keys/%3E
And digitalocean requires them.
Dne út 24. 8. 2021 17:52 uživatel Lunny Xiao ***@***.***>
napsal:
… Yes. So v1.15, we have a new table issue_index struct name is
ResourceIndex which has no primary key. But for MySQL DB cluster, a
primary key is necessary? (I'm not familiar with MySQL DB cluster)
So MySQL DB cluster is never the design target but it works before v1.15.
Should we add a primary key for ResourceIndex and support MySQL DB cluster
officially?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#16802 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACVBQ3QLJO5C7AIDT4Q5UJTT6O54VANCNFSM5CW2REMA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
|
I'm not database expert but I don't think this is It sounds like DigitalOcean's hosted databases have made this choice for users. Rather than testing and supporting This writeup tries to cover the why and how of this. |
Setting these variables is sometimes not an option, because these variables are managed by the provider who uses them to manage clustering and another link |
|
The group_id may as well be a primary key - it has an unique index on it. |
Yes, I was suggesting that Gitea may want to set the variables when testing MySQL/MariaDB support rather than figuring out a Galera cluster and testing with that. Primary keys are important to clustered mysql to ensure that rows can be deleted and that you get consistent order of returned data, but flipping these flags on a single database server is probably sufficient for avoiding this incompatibility in the future. |
zeripath
added a commit
to zeripath/gitea
that referenced
this issue
Aug 24, 2021
Make the group_id a primary key in issue_index. This already has an unique index and therefore is a good candidate for becoming a primary key. This PR also changes all other uses of this table to add the group_id as the primary key. Fix go-gitea#16802 Signed-off-by: Andrew Thornton <[email protected]>
zeripath
added a commit
that referenced
this issue
Aug 25, 2021
Make the group_id a primary key in issue_index. This already has an unique index and therefore is a good candidate for becoming a primary key. This PR also changes all other uses of this table to add the group_id as the primary key. Fix #16802 Signed-off-by: Andrew Thornton <[email protected]>
zeripath
added a commit
to zeripath/gitea
that referenced
this issue
Aug 25, 2021
Backport go-gitea#16813 Make the group_id a primary key in issue_index. This already has an unique index and therefore is a good candidate for becoming a primary key. This PR also changes all other uses of this table to add the group_id as the primary key. The migration v192 from go-gitea#16813 has not been backported but Xorm will work fine with non-primary keyed tables. If a user on 1.15 wishes to have the correct schema sooner than 1.16 - they can use gitea doctor recreate-table issue_index and gitea will recreate the table with the primary key. Fix go-gitea#16802 Signed-off-by: Andrew Thornton [email protected]
techknowlogick
pushed a commit
that referenced
this issue
Aug 25, 2021
Backport #16813 Make the group_id a primary key in issue_index. This already has an unique index and therefore is a good candidate for becoming a primary key. This PR also changes all other uses of this table to add the group_id as the primary key. The migration v192 from #16813 has not been backported but Xorm will work fine with non-primary keyed tables. If a user on 1.15 wishes to have the correct schema sooner than 1.16 - they can use gitea doctor recreate-table issue_index and gitea will recreate the table with the primary key. Fix #16802 Signed-off-by: Andrew Thornton [email protected]
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
[x]):ORM engine initialization attempt #1/10 failed. Error: migrate: do migrate: Error 3750: Unable to create or change a table without a primary key, when the system variable 'sql_require_primary_key' is set. Add a primary key to the table or unset this variable to avoid this message. Note that tables without a primary key can cause performance problems in row-based replication, so please consult your DBA before changing this setting.Description
Certain DB clusters (for example DigitalOcean's MySQL cluster) require the use of primary keys which until now was fine. It seems like this support was dropped since 1.15. This issue occurs at fresh installation of 1.15 and also when upgrading from 1.14
The text was updated successfully, but these errors were encountered: