| Shawn O. Pearce | 4016a93 | 2009-05-28 15:12:40 -0700 | [diff] [blame] | 1 | gerrit replicate |
| 2 | ================ |
| 3 | |
| 4 | NAME |
| 5 | ---- |
| 6 | gerrit replicate - Manually trigger replication, to recover a node |
| 7 | |
| 8 | SYNOPSIS |
| 9 | -------- |
| 10 | [verse] |
| 11 | 'ssh' -p <port> <host> 'gerrit replicate' \ |
| 12 | [\--url <PATTERN>] \ |
| 13 | \{\--all | <PROJECT> ...} |
| 14 | |
| 15 | DESCRIPTION |
| 16 | ----------- |
| 17 | Schedules replication of the specified projects to all configured |
| 18 | replication destinations, or only those whose URLs match the pattern |
| 19 | given on the command line. |
| 20 | |
| 21 | Normally Gerrit automatically schedules replication whenever it |
| 22 | makes a change to a managed Git repository. However, there are |
| 23 | other reasons why an administrator may wish to trigger replication: |
| 24 | |
| 25 | * Destination disappears, then later comes back online. |
| 26 | + |
| 27 | If a destination went offline for a period of time, when it comes |
| 28 | back, it may be missing commits that it should have. Triggering a |
| 29 | replication run for all projects against that URL will update it. |
| 30 | |
| 31 | * After repacking locally, and using `rsync` to distribute the new |
| 32 | pack files to the destinations. |
| 33 | + |
| 34 | If the local server is repacked, and then the resulting pack files |
| 35 | are sent to remote peers using `rsync -a \--delete-after`, there |
| 36 | is a chance that the rsync missed a change that was added during |
| 37 | the rsync data transfer, and the rsync will remove that changes's |
| 38 | data from the remote, even though the automatic replication pushed |
| 39 | it there in parallel to the rsync. |
| 40 | + |
| 41 | Its a good idea to run replicate with `\--all` to ensure all |
| 42 | projects are consistent after the rsync is complete. |
| 43 | |
| 44 | * After deleting a ref by hand. |
| 45 | + |
| 46 | If a ref must be removed (e.g. to purge a change or patch set |
| 47 | that shouldn't have been created, and that must be eradicated) |
| 48 | that delete must be done by direct git access on the local, |
| 49 | managed repository. Gerrit won't know about the delete, and is |
| 50 | unable to replicate it automatically. Triggering replication on |
| 51 | just the affected project can update the mirrors. |
| 52 | |
| 53 | ACCESS |
| 54 | ------ |
| 55 | Caller must be a member of the privileged 'Administrators' group. |
| 56 | |
| 57 | SCRIPTING |
| 58 | --------- |
| 59 | This command is intended to be used in scripts. |
| 60 | |
| 61 | OPTIONS |
| 62 | ------- |
| 63 | \--all:: |
| 64 | Schedule replicating for all projects. |
| 65 | |
| 66 | \--url=<PATTERN>:: |
| 67 | Replicate only to replication destinations whose URL |
| 68 | contains the substring <PATTERN>. This can be useful to |
| 69 | replicate only to a previously down node, which has been |
| 70 | brought back online. |
| 71 | |
| 72 | EXAMPLES |
| 73 | -------- |
| 74 | Replicate every project, to every configured remote: |
| 75 | |
| 76 | ==== |
| 77 | $ ssh -p 29418 review.example.com gerrit replicate --all |
| 78 | ==== |
| 79 | |
| 80 | Replicate only to `srv2` now that it is back online: |
| 81 | |
| 82 | ==== |
| 83 | $ ssh -p 29418 review.example.com gerrit replicate --url=srv2 --all |
| 84 | ==== |
| 85 | |
| 86 | Replicate only the `tools/gerrit` project, after deleting a ref |
| 87 | locally by hand: |
| 88 | |
| 89 | ==== |
| 90 | $ git --git-dir=/home/git/tools/gerrit.git update-ref -d refs/changes/00/100/1 |
| 91 | $ ssh -p 29418 review.example.com gerrit replicate tools/gerrit |
| 92 | ==== |
| 93 | |
| 94 | SEE ALSO |
| 95 | -------- |
| 96 | |
| 97 | * link:config-replication.html[Git Replication/Mirroring] |
| Shawn O. Pearce | 5500e69 | 2009-05-28 15:55:01 -0700 | [diff] [blame] | 98 | |
| 99 | GERRIT |
| 100 | ------ |
| 101 | Part of link:index.html[Gerrit Code Review] |
