github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-26 08:41:08 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Migration from 1.13.7 to 1.14.1 failed with migrate: do migrate: Error 1071: Specified key was too long; max key length is 1000 bytes #7317

New Issue
Closed
opened 2025-11-02 07:22:46 -06:00 by GiteaMirror · 14 comments
GiteaMirror commented 2025-11-02 07:22:46 -06:00
Owner
Copy Link

Originally created by @tanrui8765 on GitHub (May 10, 2021).

  • Gitea version (or commit ref): 1.13.7 -> 1.14.0/1.14.2
  • Git version: 2.23.0.windows.1
  • Operating system: Windows Server 2008 R2 Enterprise SP1 64bit
  • Gitea is downloaded as "gitea-1.13.7-windows-4.0-amd64.exe", "gitea-1.14.2-windows-4.0-amd64.exe", run as windows service.
  • Database (use [x]):
    • PostgreSQL
    • MySQL 5.7.26
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
  • Log gist:

Description

I tried to upgrade from 1.13.7 to 1.14.0/1.14.2 directly, but failed. The info when I execute “doctor —all —fix” is the same with the GitHub issue #15505. The upgrade steps are as follows:

  1. Stop the gitea windows service.
  2. Copy and replace the gitea.exe with newer version.
  3. Restart the gitea windows service. （Failed! 1.13.7 -> 1.14.0/1.14.2, Error 1067: The process terminated unexpectedly）
  4. Get the doctor information. (./gitea.exe doctor --all --fix)

Screenshots

image

Originally created by @tanrui8765 on GitHub (May 10, 2021). - Gitea version (or commit ref): 1.13.7 -> 1.14.0/1.14.2 - Git version: 2.23.0.windows.1 - Operating system: Windows Server 2008 R2 Enterprise SP1 64bit - Gitea is downloaded as "gitea-1.13.7-windows-4.0-amd64.exe", "gitea-1.14.2-windows-4.0-amd64.exe", run as windows service. - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL 5.7.26 - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - Log gist: <!-- It really is important to provide pertinent logs --> <!-- Please read https://docs.gitea.io/en-us/logging-configuration/#debugging-problems --> <!-- In addition, if your problem relates to git commands set `RUN_MODE=dev` at the top of app.ini --> ## Description I tried to upgrade from 1.13.7 to 1.14.0/1.14.2 directly, but failed. The info when I execute “doctor —all —fix” is the same with the GitHub issue #15505. The upgrade steps are as follows: > 1. Stop the gitea windows service. > 2. Copy and replace the gitea.exe with newer version. > 3. Restart the gitea windows service. （Failed! 1.13.7 -> 1.14.0/1.14.2, Error 1067: The process terminated unexpectedly） > 4. Get the doctor information. (./gitea.exe doctor --all --fix) ## Screenshots ![image](https://user-images.githubusercontent.com/3466957/117597045-5332e100-b177-11eb-8923-8e4a2e3acc10.png)
GiteaMirror commented 2025-11-02 07:22:47 -06:00
Author
Owner
Copy Link

@tanrui8765 commented on GitHub (May 10, 2021):

Hello @zeripath @6543 @lunny , the #15505 issue probably still exists.

@tanrui8765 commented on GitHub (May 10, 2021): Hello @zeripath @6543 @lunny , the #15505 issue probably still exists.
GiteaMirror commented 2025-11-02 07:22:47 -06:00
Author
Owner
Copy Link

@jolheiser commented on GitHub (May 10, 2021):

Unfortunately the error is missing in the doctor log. (#15813)

Can you give us your gitea logs as well for startup?

@jolheiser commented on GitHub (May 10, 2021): Unfortunately the error is missing in the doctor log. (#15813) Can you give us your gitea logs as well for startup?
GiteaMirror commented 2025-11-02 07:22:47 -06:00
Author
Owner
Copy Link

@tanrui8765 commented on GitHub (May 10, 2021):

Sure, but would you please tell me where to find this log? or all logs in Gitea/log/ folder? @jolheiser

image

@tanrui8765 commented on GitHub (May 10, 2021): Sure, but would you please tell me where to find this log? or all logs in `Gitea/log/` folder? @jolheiser ![image](https://user-images.githubusercontent.com/3466957/117604749-c3962e00-b188-11eb-8bfc-0c04e825d4c7.png)
GiteaMirror commented 2025-11-02 07:22:48 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (May 10, 2021):

We need to the results and output messages that are returned from gitea migrate (or the first few messages that come out when you try to start gitea.)

It's likely that the log files will not contain this data as it is run before logs are set up.

So can you please just give us that output.

However I'm going to go out on a limb and guess that your error is coming from MySQL and it is reporting "error 1071".

In your mysql db console whilst connected to the gitea db run:

SET GLOBAL innodb_file_format=Barracuda;
SET GLOBAL innodb_file_per_table=1;
SET GLOBAL innodb_large_prefix=1;
@zeripath commented on GitHub (May 10, 2021): We need to the results and output messages that are returned from gitea migrate (or the first few messages that come out when you try to start gitea.) It's likely that the log files will not contain this data as it is run before logs are set up. So can you please just give us that output. --- However I'm going to go out on a limb and guess that your error is coming from MySQL and it is reporting "error 1071". In your mysql db console whilst connected to the gitea db run: ```sql SET GLOBAL innodb_file_format=Barracuda; SET GLOBAL innodb_file_per_table=1; SET GLOBAL innodb_large_prefix=1; ```
GiteaMirror commented 2025-11-02 07:22:48 -06:00
Author
Owner
Copy Link

@tanrui8765 commented on GitHub (May 11, 2021):

Hello @zeripath, I restored the Gitea version and data to V1.13.7 for team development yesterday. I'll try to get the MySQL information you suggested later in a few days.

I had some findings when restoring the Gitea to 1.13.7 on "error 1071". I followed instruction in Restore Doc. The restoring MySQL steps:

  1. Delete all the Gitea database's tables in phpMyAdmin
  2. Import gitea-db.sql to Gitea database in phpMyAdmin
  3. Error 1071 pops out about table "deleted_branch"
  4. Locate the error, it comes from a line of SQL code: CREATE UNIQUE INDEX UQE_deleted_branch_s ON deleted_branch (repo_id,name,commit);
  5. Compare this Gitea database's tables to another Gitea server with 1.13.7. I found the restored tables' type are all 'MyISAM', whereas table "deleted_branch" should be 'InnoDB'.
  6. Change "deleted_branch" table from MyISAM to InnoDB with code: alter table deleted_branch engine=innodb;
  7. Execute code in step 4, and there are no error anymore: CREATE UNIQUE INDEX UQE_deleted_branch_s ON deleted_branch (repo_id,name,commit);
  8. Change some other table types from MyISAM to InnoDB.
  9. Run .\gitea.exe doctor --all [2] & [3] are reported OK.

image
image

@tanrui8765 commented on GitHub (May 11, 2021): Hello @zeripath, I restored the Gitea version and data to V1.13.7 for team development yesterday. I'll try to get the MySQL information you suggested later in a few days. I had some findings when restoring the Gitea to 1.13.7 on "error 1071". I followed instruction in [Restore Doc](https://docs.gitea.io/en-us/backup-and-restore/). The restoring MySQL steps: 1. Delete all the Gitea database's tables in phpMyAdmin 2. Import `gitea-db.sql` to Gitea database in phpMyAdmin 3. Error 1071 pops out about table "deleted_branch" 4. Locate the error, it comes from a line of SQL code: **CREATE UNIQUE INDEX `UQE_deleted_branch_s` ON `deleted_branch` (`repo_id`,`name`,`commit`);** 5. Compare this Gitea database's tables to another Gitea server with 1.13.7. I found the restored tables' type are all 'MyISAM', whereas table "deleted_branch" should be 'InnoDB'. 6. Change "deleted_branch" table from MyISAM to InnoDB with code: **`alter table deleted_branch engine=innodb;`** 7. Execute code in step 4, and there are no error anymore: **CREATE UNIQUE INDEX `UQE_deleted_branch_s` ON `deleted_branch` (`repo_id`,`name`,`commit`);** 8. Change some other table types from MyISAM to InnoDB. 9. Run **.`\gitea.exe doctor --all`** [2] & [3] are reported OK. ![image](https://user-images.githubusercontent.com/3466957/117743011-85584780-b238-11eb-9214-6fb0dcecca5e.png) ![image](https://user-images.githubusercontent.com/3466957/117743942-5ba02000-b23a-11eb-9c9f-fbb23c58b418.png)
GiteaMirror commented 2025-11-02 07:22:48 -06:00
Author
Owner
Copy Link

@tanrui8765 commented on GitHub (May 11, 2021):

Ah, I just see this error 1071 topic in Upgrade errors with MySQL

@tanrui8765 commented on GitHub (May 11, 2021): Ah, I just see this error 1071 topic in [Upgrade errors with MySQL](https://docs.gitea.io/en-us/faq/#upgrade-errors-with-mysql)
GiteaMirror commented 2025-11-02 07:22:48 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (May 11, 2021):

I apologize if I wasn't clear.

Let me try again.

I need to see the error that happens when you try to upgrade. That is, when you try to run gitea web or gitea migrate using 1.14.2.

You still have not told us what the exact error is and without that error we cannot help.

Therefore, please could you give me the result of running with 1.14.2:

gitea migrate
@zeripath commented on GitHub (May 11, 2021): I apologize if I wasn't clear. Let me try again. I need to see the error that happens when you try to upgrade. That is, when you try to run `gitea web` or `gitea migrate` using 1.14.2. You still have not told us what the exact error is and without that error we cannot help. Therefore, please could you give me the result of running with 1.14.2: ``` gitea migrate ```
GiteaMirror commented 2025-11-02 07:22:48 -06:00
Author
Owner
Copy Link

@tanrui8765 commented on GitHub (May 11, 2021):

Sure, I see, I will try it in a few days.

@tanrui8765 commented on GitHub (May 11, 2021): Sure, I see, I will try it in a few days.
GiteaMirror commented 2025-11-02 07:22:49 -06:00
Author
Owner
Copy Link

@tanrui8765 commented on GitHub (May 16, 2021):

Hello @zeripath , here is what I got while upgrading 1.13.7 to 1.14.2, executing 1.14.2 gitea migrate & gitea web before start the windows service.

GiteaUpgradeFail_1_13_7_to_1_14_2_web_feedback_20210516a.txt
GiteaUpgradeFail_1_13_7_to_1_14_2_migrate_feedback_20210516a.txt

@tanrui8765 commented on GitHub (May 16, 2021): Hello @zeripath , here is what I got while upgrading 1.13.7 to 1.14.2, executing 1.14.2 `gitea migrate` & `gitea web` before start the windows service. [GiteaUpgradeFail_1_13_7_to_1_14_2_web_feedback_20210516a.txt](https://github.com/go-gitea/gitea/files/6488823/GiteaUpgradeFail_1_13_7_to_1_14_2_web_feedback_20210516a.txt) [GiteaUpgradeFail_1_13_7_to_1_14_2_migrate_feedback_20210516a.txt](https://github.com/go-gitea/gitea/files/6488824/GiteaUpgradeFail_1_13_7_to_1_14_2_migrate_feedback_20210516a.txt)
GiteaMirror commented 2025-11-02 07:22:49 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (May 16, 2021):

The important error is here :

2021/05/16 15:14:13 cmd/migrate.go:38:runMigrate() [F] Failed to initialize ORM engine: migrate: do migrate: Error 1071: Specified key was too long; max key length is 1000 bytes

and is found right at the end of the migrate feedback.

As I suspected this is a MySQL error 1071, but worse it indicates that you are running your db with ISAM tables.

MyISAM tables are not supported by Gitea and have never been supported. You need to use InnoDB as ISAM does not have transaction support.

As it states in our FAQ https://docs.gitea.io/en-us/faq/#upgrade-errors-with-mysql you must run:

ALTER TABLE table_name ENGINE=InnoDB;

for each table in the database.

Then you will likely need to run:

SET GLOBAL innodb_file_format=Barracuda;
SET GLOBAL innodb_file_per_table=1;
SET GLOBAL innodb_large_prefix=1;
@zeripath commented on GitHub (May 16, 2021): The important error is here : `2021/05/16 15:14:13 cmd/migrate.go:38:runMigrate() [F] Failed to initialize ORM engine: migrate: do migrate: Error 1071: Specified key was too long; max key length is 1000 bytes` and is found right at the end of the migrate feedback. As I suspected this is a MySQL error 1071, but worse it indicates that you are running your db with ISAM tables. MyISAM tables are not supported by Gitea and have never been supported. You need to use InnoDB as ISAM does not have transaction support. As it states in our FAQ https://docs.gitea.io/en-us/faq/#upgrade-errors-with-mysql you must run: ``` ALTER TABLE table_name ENGINE=InnoDB; ``` for each table in the database. Then you will likely need to run: ``` SET GLOBAL innodb_file_format=Barracuda; SET GLOBAL innodb_file_per_table=1; SET GLOBAL innodb_large_prefix=1; ```
GiteaMirror commented 2025-11-02 07:22:49 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (May 16, 2021):

@tanrui8765 try gitea convert bevore migration

@6543 commented on GitHub (May 16, 2021): @tanrui8765 try `gitea convert` bevore migration
GiteaMirror commented 2025-11-02 07:22:49 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (May 16, 2021):

unfortunately gitea convert doesn't do the InnoDB conversion as it was assumed that no-one would be running with ISAM.

@zeripath commented on GitHub (May 16, 2021): unfortunately `gitea convert` doesn't do the InnoDB conversion as it was assumed that no-one would be running with ISAM.
GiteaMirror commented 2025-11-02 07:22:50 -06:00
Author
Owner
Copy Link

@vitalif commented on GitHub (May 16, 2021):

I get the same with InnoDB.

2021/05/16 14:38:51 ...ations/migrations.go:394:Migrate() [I] Migration[159]: update reactions constraint
2021/05/16 14:38:51 models/models.go:220:NewEngine() [I] [SQL] BEGIN TRANSACTION [] - 131.62µs
2021/05/16 14:38:51 ...s/migrations/v159.go:33:updateReactionConstraint() [I] [SQL] CREATE TABLE IF NOT EXISTS `tmp_recreate__reaction` (`id` BIGINT(20) PRIMARY KEY AUTO_INCREMENT NOT NULL, `type` VARCHAR(255) NOT NULL, `issue_id` BIGINT(20) NOT NULL, `comment_id` BIGINT(20) NULL, `user_id` BIGINT(20) NOT NULL, `original_author_id` BIGINT(20) DEFAULT 0 NOT NULL, `original_author` VARCHAR(255) NULL, `created_unix` BIGINT(20) NULL) DEFAULT CHARSET utf8mb4 ROW_FORMAT=DYNAMIC [] - 260.682µs
2021/05/16 14:38:51 ...s/migrations/v159.go:33:updateReactionConstraint() [I] [SQL] CREATE UNIQUE INDEX `UQE_tmp_recreate__reaction_s` ON `tmp_recreate__reaction` (`type`,`issue_id`,`comment_id`,`user_id`,`original_author_id`,`original_author`) [] - 213.659µs
2021/05/16 14:38:51 ...ations/migrations.go:447:recreateTable() [E] Unable to create uniques for table tmp_recreate__reaction. Error: Error 1071: Specified key was too long; max key length is 767 bytes
2021/05/16 14:38:51 ...ations/migrations.go:397:Migrate() [I] [SQL] ROLLBACK [] - 94.23µs
2021/05/16 14:38:51 routers/init.go:157:GlobalInit() [F] ORM engine initialization failed: migrate: do migrate: Error 1071: Specified key was too long; max key length is 767 bytes
@vitalif commented on GitHub (May 16, 2021): I get the same with InnoDB. ``` 2021/05/16 14:38:51 ...ations/migrations.go:394:Migrate() [I] Migration[159]: update reactions constraint 2021/05/16 14:38:51 models/models.go:220:NewEngine() [I] [SQL] BEGIN TRANSACTION [] - 131.62µs 2021/05/16 14:38:51 ...s/migrations/v159.go:33:updateReactionConstraint() [I] [SQL] CREATE TABLE IF NOT EXISTS `tmp_recreate__reaction` (`id` BIGINT(20) PRIMARY KEY AUTO_INCREMENT NOT NULL, `type` VARCHAR(255) NOT NULL, `issue_id` BIGINT(20) NOT NULL, `comment_id` BIGINT(20) NULL, `user_id` BIGINT(20) NOT NULL, `original_author_id` BIGINT(20) DEFAULT 0 NOT NULL, `original_author` VARCHAR(255) NULL, `created_unix` BIGINT(20) NULL) DEFAULT CHARSET utf8mb4 ROW_FORMAT=DYNAMIC [] - 260.682µs 2021/05/16 14:38:51 ...s/migrations/v159.go:33:updateReactionConstraint() [I] [SQL] CREATE UNIQUE INDEX `UQE_tmp_recreate__reaction_s` ON `tmp_recreate__reaction` (`type`,`issue_id`,`comment_id`,`user_id`,`original_author_id`,`original_author`) [] - 213.659µs 2021/05/16 14:38:51 ...ations/migrations.go:447:recreateTable() [E] Unable to create uniques for table tmp_recreate__reaction. Error: Error 1071: Specified key was too long; max key length is 767 bytes 2021/05/16 14:38:51 ...ations/migrations.go:397:Migrate() [I] [SQL] ROLLBACK [] - 94.23µs 2021/05/16 14:38:51 routers/init.go:157:GlobalInit() [F] ORM engine initialization failed: migrate: do migrate: Error 1071: Specified key was too long; max key length is 767 bytes ```
GiteaMirror commented 2025-11-02 07:22:50 -06:00
Author
Owner
Copy Link

@vitalif commented on GitHub (May 16, 2021):

Ok, issue solved, I had innodb_large_prefix off. Sorry

@vitalif commented on GitHub (May 16, 2021): Ok, issue solved, I had innodb_large_prefix off. Sorry
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#7317
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?