昔我往矣

gitab出现500错误的可能原因

2016年04月27日

HTTP服务器返回码为500表示服务器出错,我遇到过好几次GitLab出现500错误,主要是在用户merge request和提交issue的时候。我们的GitLab服务器版本为GitLab 7.9.1社区版。

gitlab-500.png

最后终于抽出时间来查这个问题,把gitlab的日志翻出来,在production.log里面翻到了如下的日志:

Mysql2::Error: MySQL server has gone away: INSERT INTO issues (assignee_id, author_id, created_at, description, iid, project_id, state, title, updated_at) VALUES (x, y, 'x', ......., w, i, j, m, k)
Started POST "//api/v3/internal/allowed" for 127.0.0.1 at 2016-04-15 14:03:21 +0800

Mysql2::Error: closed MySQL connection: ROLLBACK
Completed 500 Internal Server Error in 112ms

ActiveRecord::StatementInvalid (Mysql2::Error: closed MySQL connection: ROLLBACK):

app/services/issues/create_service.rb:8:in `execute'
app/controllers/projects/issues_controller.rb:58:in `create'

上面的省略号里是一大长串的SQL语句,于是过滤了一下这一行日志的长度,大约2800000左右个字符,也就是说在往数据库里插一条长度为二百多万行的记录时出现了500。可以看到,除了description字段,其它字段都很短,也就是说description长度有二百多万行。我记得MySQL的text最大长度为65535个字符,莫非是description字段类型导致的。

于是连上数据库,查看字段类型。

mysql> desc issues;
+--------------+--------------+------+-----+---------+----------------+
| Field        | Type         | Null | Key | Default | Extra          |
+--------------+--------------+------+-----+---------+----------------+
| id           | int(11)      | NO   | PRI | NULL    | auto_increment |
| title        | varchar(255) | YES  | MUL | NULL    |                |
| assignee_id  | int(11)      | YES  | MUL | NULL    |                |
| author_id    | int(11)      | YES  | MUL | NULL    |                |
| project_id   | int(11)      | YES  | MUL | NULL    |                |
| created_at   | datetime     | YES  | MUL | NULL    |                |
| updated_at   | datetime     | YES  |     | NULL    |                |
| position     | int(11)      | YES  |     | 0       |                |
| branch_name  | varchar(255) | YES  |     | NULL    |                |
| description  | text         | YES  |     | NULL    |                |
| milestone_id | int(11)      | YES  | MUL | NULL    |                |
| state        | varchar(255) | YES  |     | NULL    |                |
| iid          | int(11)      | YES  |     | NULL    |                |
+--------------+--------------+------+-----+---------+----------------+
13 rows in set (0.01 sec)

看到description果然是text类型,要不修改这个字段的类型试试, MEDIUMTEXT最大长度为16777215,应该可以满足需求了。

mysql> alter table issues modify column `description` MediumText  COLLATE utf8_unicode_ci;

果然,这回提交issue成功了。
因为多次收到反馈说提交merge request失败,所以,再看看merge request的字段类型,果然merge_requests表的description也是text类型,同样修改成MediumText。

上面只是一次排错历程,不代表所有的GitLab 500报错都是由于Text类型长度不够导致的。还是需要具体原因具体分析才好,日志永远是排查问题的好帮手!

当前暂无评论 »

添加新评论 »