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

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.

  • How to update a git clone --mirror?
  • Options for Copying Git Repo
  • How can I keep a CVS and a git repository in sync? What script will help me manage this?
  • Mirroring from Gitlab to Github
  • Safe master-master setup with git? (writable git mirror)
  • How can I keep a git mirror in sync (including deleting branches)?
  • Git deploy on MediaTemple DV
  • how to sync a repo mirror to a new upstream repo
  • One Solution collect form web for “Best way to setup mirror for Gerrit and all of its Git repos”

    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

    Git Baby is a git and github fan, let's start git clone.