... | ... | @@ -783,9 +783,33 @@ INFO: move completed with status finished |
|
|
INFO: starting housekeeping task...
|
|
|
```
|
|
|
|
|
|
If it gets interrupted, you can run the parts as well, for example, to
|
|
|
wait for a migration then run housekeeping:
|
|
|
|
|
|
fab gitlab.wait-for-move 3758 && fab gitlab.housekeeping 3466
|
|
|
|
|
|
Note that those are two different integers: the first one is the
|
|
|
`move_id` returned by the move API call, and the second is the project
|
|
|
ID. Both are visible in the `move-repo` output.
|
|
|
|
|
|
See also the [underlying design of repository moves](https://docs.gitlab.com/development/repository_storage_moves/).
|
|
|
|
|
|
But you would likely prefer batch moves instead, see below.
|
|
|
### Moving groups of repositories
|
|
|
|
|
|
The `move-repo` command can be chained, in the sense that you can loop
|
|
|
over multiple repos to migrate a bunch of them.
|
|
|
|
|
|
This untested command might work to migrate a group, for example:
|
|
|
|
|
|
fab gitlab.list-projects --group=tpo/tpa | while read id project; do
|
|
|
fab gitlab.move-repo --dest-storage=default --project=$id
|
|
|
done
|
|
|
|
|
|
Note that projects groups only account for a tiny fraction of
|
|
|
repositories on the servers, most repositories are user forks.
|
|
|
|
|
|
Ideally, the `move-repos` task would be improved to look like the
|
|
|
`list-projects` command, but that hasn't been implemented yet.
|
|
|
|
|
|
### Moving all repositories with `rsync`
|
|
|
|
... | ... | @@ -1729,6 +1753,34 @@ Restoring the artifacts took another hour of copying. |
|
|
And that's it! Note that this procedure may vary if the subset of
|
|
|
files backed up by the GitLab backup job changes.
|
|
|
|
|
|
### Emergency Gitaly migrations
|
|
|
|
|
|
If for some weird reason, you need to move away from Gitaly, and back
|
|
|
to the main GitLab server, follow this procedure.
|
|
|
|
|
|
1. enable Gitaly in `profile::gitlab::app::gitaly_enabled`
|
|
|
|
|
|
This will deploy a TLS cert, configure Gitaly and setup
|
|
|
monitoring.
|
|
|
|
|
|
2. If it's not done already (but it should, unless it was
|
|
|
*un*configured), configure the secrets on the other Gitaly server
|
|
|
(see the [Gitaly installatino](#gitaly)
|
|
|
|
|
|
3. Proceed with the [Moving all repositories with `rsync`
|
|
|
procedure](#moving-all-repositories-with-rsync)
|
|
|
|
|
|
### Gitaly running out of disk space
|
|
|
|
|
|
If the Gitaly server is full, it can be resized. But it might be
|
|
|
better to make a new one and move some repositories over. This could
|
|
|
be done by migrating repositories in batch, see [Moving groups of
|
|
|
repositories](#moving-groups-of-repositories).
|
|
|
|
|
|
Note that most repositories are user repositories, so moving a group
|
|
|
might not be enough: it is probably better to match *patterns* (like
|
|
|
`tor-browser`) but be careful when moving those because of disk space.
|
|
|
|
|
|
# Reference
|
|
|
|
|
|
## Installation
|
... | ... | |