Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Best way to setup mirror for Gerrit and all of its Git repos

Tags:

git

gerrit

mirror

I have a Gerrit server (named A), and I want to setup a mirror to a new server (named B). I want to pull from B instead of using the processing power from A because A serves as the main Gerrit server and I don't want to put more workload on it when I can mirror it using SSH from B.

I'm using H2 database and I want to mirror the whole Gerrit + all of its Git repos, not just simply Git repos because I want to keep the permissions/history from the Gerrit database too.

I had managed to narrow down 2 possible ways to do it:

  1. Using 'gerrit replicate' http://gerrit.googlecode.com/svn/documentation/2.1.6/cmd-replicate.html Not sure what it meant by "[--url < PATTERN >]". Where should I put run this command? Is it on server A or B?

  2. Use 'rsync' which is OK, but then I cannot sync review_site/etc/gerrit.config because it contains the IP of server A and don't want to have that on server B.

like image 371
xbeta Avatar asked Jan 12 '12 01:01

xbeta


People also ask

What does mirroring a repository mean?

Repository Mirroring is a way to mirror repositories from external sources. It can be used to mirror all branches, tags, and commits that you have in your repository. Your mirror at GitLab will be updated automatically. You can also manually trigger an update at most once every 5 minutes.

What is git clone mirror?

A clone copies the refs from the remote and stuffs them into a subdirectory named 'these are the refs that the remote has'. A mirror copies the refs from the remote and puts them into its own top level - it replaces its own refs with those of the remote.


1 Answers

A few comments on the different issues here:

  1. There is no good way to perform a hot backup of the database and the repositories, especially if you are using H2. The only option to shut down Gerrit and use a file transfer tool like rsync. If you use a more robust database, like postgres, there are other backup option. However, you still have potential race conditions - if you back up the repositories before a change gets submitted and back up the database after, you might have problems. This is why long-term we are working to get rid of the database and store everything in the repositories.

  2. Push vs Pull is not much different as far as CPU load on the server (as far as I know). Just use the replication features built in to Gerrit, they are designed for this sort of thing.

  3. If Server B is just meant as a backup in case Server A goes down, I'd just write a script which stops Gerrit on Server A in the middle of the night, rsyncs to Server B, and starts Gerrit back up. That is about the best you can do right now, especially with H2.

  4. If Server B is meant to be a slave of your master (so some users can hit it rather than everybody hitting Server A), use Gerrit replication and slave mode - http://gerrit.googlecode.com/svn/documentation/2.1.6/config-gerrit.html#container. Note that this doesn't backup your database or changes in review.

  5. Gerrit 2.1.6 is really old. Use at least 2.1.8, 2.2.2 will be released soon and is your best bet

  6. The 'gerrit replicate' command is just meant to kick off replication in case the server was down the last time Gerrit tried to replicate. The instructions for setting up replication with 2.1.6 are at http://gerrit.googlecode.com/svn/documentation/2.1.6/config-replication.html

like image 197
Brad Avatar answered Sep 29 '22 01:09

Brad