Hello Community
Again I have to kill my private Gitlab instance completely. Upgrading from 15.4.2 to 15.4.6 was possible. But when I want to follow the upgrade path to the most recent 15.11.0 my docker container crashes with a db error message.
gitlab ALTER TABLE dast_site_profiles ADD CONSTRAINT check_8d2aa0f66d CHECK ( char_length(scan_file_path) <= 1024 ) NOT VALID;
This error is undocumented and I have no clue, what I can do. The only possibility I see currently is: Checkout all projects. Reinstall Gitlab with the newest version and push the projects back to the new Gitlab instance. This is a big task consuming a lot of time, because I have to figure out all the settings, I have done on my current gitlab instance.
Most time consuming is the time the container needs to warm up, before I can use it.
Sadly I cannot export or import any settings or projects, when I want to change the Gitlab version, because this is not recommended.
I guess I am fucked again by the upgrade procedure. While I this time followed strictly the Upgrade-Path.
When I read here some of the topics, it looks like more people have problems with the upgrade topic. Any recommendations?
Best Regards
I would suggest instead of the huge jump from 15.4.6 to 15.11, to break it up a little, say:
15.4.6 → 15.5.0 → 15.6.0 → 15.7.0 → 15.8.0 → 15.9.0 → 15.10.0 → 15.11.0
I’ve done upgrades with some of my clients, and gone from 14.x versions following the upgrade guide and they worked OK. That said, they were upgrade to 15.7.x or 15.8.x as they were done a while ago. Although they are Omnibus versions. I see a lot of posts about upgrade problems when Gitlab is used in docker. Far less problems with a VM/VPS/server and a Gitlab Omnibus install. So not sure if Gitlab + Docker is more problematic, or just sheer bad luck.
Anyway, try the path above and see if that helps a bit better. Do some backups if you can after each upgrade, ensure all background migrations have finished before starting the next upgrade. At least with the backups if it does fail, your not reverting all the way back to 15.4.6.
I will try to go this path. 15.5.0 is done already. And it looks pretty good.
The problem with docker is, Gitlab does not follow the docker idea. Gitlab provides all services in one image/container instead of using one container for one service.
I guess there is running a Mattermost inside my container consuming RAM and CPU, which I will never use.
The benefit of Gitlabs way is configuration between all the services can be done hidden inside one service and the user does not need to take care about all of that.
But on the other hand you have only one container consuming more power than you really need with a huge log output. I do not know, when a migration is really done. It’s for sure not the point of time when the webinterface is available.
The command docker logs gitlab | grep migration will flood your console. You will never know, when the current migration is really done. So the container needs to run at least one hour (Safety first). The less migration steps you have, the faster you are up to date. Therefore I try for sure avoid too much steps.
I am sadly not familar with Omnibus. I do not know what it is. Maybe there are migration steps needed also for this service, which need minor steps on upgrading. You see only the docker tags of gitlab-ce. This means you do not know what version of Omnibus is inside the image. So I have to trust the documentation of Gitlabs upgrade path. Maybe it’s needed to add some docker related information.
After upgrading I will post a reply. But sadly this will take some time with all those backup steps and so on.
The background migrations you can check in the web UI under Admin → Monitoring → Background Migrations.
Omnibus is the packaged version that you install, so a deb package for Debian/Ubuntu, or an rpm package for RHEL, etc.
Hello iwalker
You were right. In many time consuming upgrade steps the upgrade was successfully.
I still do not understand this behavior, but it seems it’s working that way.
Thank you for your advice.
1 Like
Hello, I upgraded to 15.10.6 according to the official 12.2.4, but something went wrong. The backup was normal. I took the backup file to the test server for recovery test, but the data was only half of the original one, may I ask where the upgrade went wrong?
Impossible to tell, you would need to explain more about the exact procedures you followed, the exact upgrade path, whether you waited for background migrations to finish before starting the next upgrade. If you were on 12.2.4, then there was a migration from normal storage to Gitaly storage in some later Gitlab versions, so it’s most likely here the problem came because the migration hadn’t finished before the next upgrade was started.
Thank you for your reply, I am in according to the official upgrade path 12.2.4-13.0, 14-13.1.11-13.8.8-13.12.15-14.0.12-14.3.6-14.9.5-14.10.5-15.0.5 - minus 15-15.10.7, like this The upgrade path is upgraded, and after each upgrade, I will confirm that the background migration is complete, and the display is 0; After the upgrade to 13.8.8, a backup is made. Duplicate data is displayed in the backup log, that is, one item is displayed in two logs. The other one is correct data, and the other one is empty, which is skipped. This problem has been followed until version 15.10.7, but gitlab is working properly, backup is normal, recovery display is complete, but some items in gitlab have no data.
Double data is displayed after 13.8.8, as shown in the following screenshot
