Migration on update from 0.2.7 to 9.3.4 or 9.3.5 failing


#1

Hi!
we tried to update gitlab 9.2.7 CE to 9.3.5 ( installed using apt ) today. While running database migrations the migration TurnNestedGroupsIntoRegularGroupsForMysql failed.

The error is:

Validation failed: Name has already been taken/opt/gitlab/embedded/service/gitlab-rails/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.8/lib/active_record/validations.rb:79:in `raise_record_invalid'

Can anyone help?

Kind regards,
Sascha


#2

Hi,

I had the exact same problem today when I wanted to update from 9.2.7 to 9.3.5.

After some googling I found the Release-Notes of 9.3 where you can find the info that subgroups are dropped for MySQL due to performance issues. See https://about.gitlab.com/2017/06/22/gitlab-9-3-released/#dropping-support-for-subgroups-in-mysql.

In my case the migration failed because I had (luckily just) one subgroup that was exactly named like a user account. I renamed this subgroup in the table “namespaces” to a unique name und changed the path in the same table reflecting the name change. Additionally I renamed the repository path within the filesystem accordingly. I’m not sure if the path changes are necessary but it worked in my case.

Now I have my GitLab-9.3.5 up and running and considering a move to Postgres. I found some info here https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/update/mysql_to_postgresql.md but I haven’t tried so far.

I hope this helps a bit.

Kind regards,
Christian


#3

I should mention that the “/” in “group/subgroup” turned into a “-”, so the repository path will change to “group-subgroup” after the database migration.


#4

@mantiz Thanks for your answer. Probably we will first migrate the db and update then.


#5

Hi,

seems like my issue here when I tried to upgrade from 9.1.1 to 9.3 (in order to finally reach at least 10.4).

Is it correct to say that two names (or pathes) ‘Foo/Bar-Baz’ and ‘Foo-Bar/Baz’ will be flattened to ‘Foo-Bar-Baz’ thus causing a name clash?

Is the namespace id I found in the migration output just before the traceback of any relevance as to find which namespace has caused the abort? Probably then I can change some names without running through the whole database.

Kind Regards
Herbert