Repository location change

How to Use GitLab
1

Hi I currently have a test gitlab server on the latest build which is

 Ruby:         ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux]
 GitLab:       13.8.2 (643958d42f2) FOSS
 GitLab Shell: 13.15.0
 PostgreSQL:   12.5

I have a live server on a old version of gitlab but its repositories are newer as its been used.
gitlab 9.0.1ce

Can I just repoint the new server to the live server repository. I know i have to change the path in gitlab.rb for git_data_dirs.

For setting up different data storing directory

###! Docs: Configuration options | GitLab
###! If you want to use a single non-default directory to store git data use a
###! path that doesn’t contain symlinks.
git_data_dirs({ “default” => { “path” => “/data/gitlab/git-data” } })

What is the order in changing the location in the gitlab.rb file and then restarting a service for changes to take affect?

After this change I would shutdown the old server and begin using the new server. Would this be possible to do as this would then save hours of downtime?

In the current location in the new server I would create a softlink ln -s to the current live repository.

Or can I just copy over the current live repo to the new server and just restart a service for changes to take affect?

2

GitLab also saves some data about repositories in it’s database. That wouldn’t be accessible if you just symlinked or copied the data directories, so those plans won’t work.

3

So how would you move a repository to a new location?

4

According to this doc I can move repositories. But I was not sure on the process involved once I moved it over. Do I need to edit the gitlab.rb with the new location and then run a reconfigure?

https://docs.gitlab.com/ee/administration/operations/moving_repositories.html

5

What are you trying to do? And what do you hope to accomplish by it?

As far as I can see that moving stuff (but I haven’t tried it) is for moving data within one instance. As I understood it originally you wanted to move from one instance (an old one) to another (the test one, and a newer version). Moving data around within one of them won’t bring you any nearer (or farther) from your goal.

6

Sorry let me explain.

My current live setup is gitlab 9.0.1ce on a physical server with a extra disk. The extra disk is where the repository resides.

My test server hopefully will become the live server is a vm and the repository as of yesterday is now located centrally. This is on a clustered storage not directly connected to the vm stack but only via ip which is mounted on the gitlab vm via autofs automounts. I changed this from local to central shared storage yesterday.

I used the command below to do this
sudo -u git sh -c 'tar -C /data/gitlab/git-data/repositories -cf - -- . | tar -C /Volumes/software/gitlab/git-data/repositories -xvf -'

Then I edited the gitlab.rb with the new repo location and then

  1. Run gitlab-ctl reconfigure
  2. gitlab-ctl restart

This changed the repo location.

Now my live gitlab server has some scripts that are newer in the repository than my new vm. This is due to when I did the backup and when I restored it.

My aim would be to copy the old legacy repo to the new location and then convert the legacy repo to a hashed based repo by running the below command

sudo gitlab-rake gitlab:storage:migrate_to_hashed

Then run again

  1. Run gitlab-ctl reconfigure
  2. gitlab-ctl restart

I am hoping this would reduce my down time and the new vm would have all the current scripts so that I can make that live.

I have done it this way so that people can carry on using the old server while I upgrade the version on this vm which is now 13.8.2 and also to not break our current live gitlab server just incase I would have encountered an error in the upgrade process as I have never done this before.

The other way would be to upgrade the current live repo to the latest version take a backup and then restore this to the new vm.

7

That won’t work! As I’ve said GitLab also stores data about the repositories in it’s database, so just making the repos available to the new server, won’t do it.
And while I don’t remember which versions of PostgreSQL were supported in 9.0.1 (back then MySQL might also have been supported, ours used PostgreSQL when I took over around GitLab 10.3), I’m pretty sure there’s no overlap with the versions supported in 13.8 (PostgreSQL 11 and 12, and support for 11 will go away in GitLab 14), so even if you also moved that it probably wouldn’t work.

You have to go what you call “the other way”. And being as far behind as 9.0.1 is, you will have user-visible downtime when doing all those upgrades (I had user-visible downtime a couple of times doing small upgrades (from one minor release to the next) in that range even when following the zero-downtime procedure.

1 Like