Changeset View
Changeset View
Standalone View
Standalone View
src/docs/user/cluster/cluster_repositories.diviner
- This file was added.
@title Cluster: Repositories | |||||
@group intro | |||||
Configuring Phabricator to use multiple repository hosts. | |||||
Overview | |||||
======== | |||||
WARNING: This feature is a very early prototype; the features this document | |||||
describes are mostly speculative fantasy. | |||||
If you use Git or Mercurial, you can deploy Phabricator with multiple | |||||
repository hosts, configured so that each host is readable and writable. The | |||||
advantages of doing this are: | |||||
- you can completely survive the loss of repository hosts; | |||||
- reads and writes can scale across multiple machines; and | |||||
- read and write performance across multiple geographic regions may improve. | |||||
This configuration is complex, and many installs do not need to pursue it. | |||||
This configuration is not currently supported with Subversion. | |||||
Repository Hosts | |||||
================ | |||||
Repository hosts must run a complete, fully configured copy of Phabricator, | |||||
including a webserver. If you make repositories available over SSH, they must | |||||
also run a properly configured `sshd`. | |||||
Generally, these hosts will run the same set of services and configuration that | |||||
web hosts run. If you prefer, you can overlay these services and put web and | |||||
repository services on the same hosts. | |||||
When a user requests information about a repository that can only be satisfied | |||||
by examining a repository working copy, the webserver receiving the reqeust | |||||
will make an HTTP service call to a repository server which hosts the | |||||
repository to retrieve the data it needs. It will use the result of this query | |||||
to respond to the user. | |||||
How Reads and Writes Work | |||||
========================= | |||||
Phabricator repository replicas are multi-master: every node is readable and | |||||
writable, and a cluster of nodes can (almost always) survive the loss of any | |||||
arbitrary subset of nodes so long as at least one node is still alive. | |||||
Phabricator maintains an internal version for each repository, and increments | |||||
it when the repository is mutated. | |||||
Before responding to a read, replicas make sure their version of the repository | |||||
is up to date (no node in the cluster has a newer version of the repository). | |||||
If it isn't, they block the read until they can complete a fetch. | |||||
Before responding to a write, replicas obtain a global lock, perform the same | |||||
version check and fetch if necessary, then allow the write to continue. | |||||
Backups | |||||
====== | |||||
Even if you configure clustering, you should still consider retaining separate | |||||
backup snapshots. Replicas protect you from data loss if you lose a host, but | |||||
they do not let you rewind time to recover from data mutation mistakes. | |||||
If something issues a `--force` push that destroys branch heads, the mutation | |||||
will propagate to the replicas. | |||||
You may be able to manually restore the branches by using tools like the | |||||
Phabricator push log or the Git reflog so it is less important to retain | |||||
repository snapshots than database snapshots, but it is still possible for | |||||
data to be lost permanently, especially if you don't notice the problem for | |||||
some time. | |||||
Retaining separate backup snapshots will improve your ability to recover more | |||||
data more easily in a wider range of disaster situations. | |||||
Next Steps | |||||
========== | |||||
Continue by: | |||||
- returning to @{article:Clustering Introduction}. |