Differential D17167 Diff 41288 src/docs/user/cluster/cluster_repositories.diviner

Changeset View

Standalone View

src/docs/user/cluster/cluster_repositories.diviner

Show All 31 Lines
Before responding to a read, replicas make sure their version of the repository		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).		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.		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		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.		version check and fetch if necessary, then allow the write to continue.

Additionally, repositories passively check other nodes for updates and		Additionally, repositories passively check other nodes for updates and
replicate changes in the background. After you push a change to a repositroy,		replicate changes in the background. After you push a change to a repository,
it will usually spread passively to all other repository nodes within a few		it will usually spread passively to all other repository nodes within a few
minutes.		minutes.

Even if passive replication is slow, the active replication makes acknowledged		Even if passive replication is slow, the active replication makes acknowledged
changes sequential to all observers: after a write is acknowledged, all		changes sequential to all observers: after a write is acknowledged, all
subsequent reads are guaranteed to see it. The system does not permit stale		subsequent reads are guaranteed to see it. The system does not permit stale
reads, and you do not need to wait for a replication delay to see a consistent		reads, and you do not need to wait for a replication delay to see a consistent
view of the repository no matter which node you ask.		view of the repository no matter which node you ask.
▲ Show 20 Lines • Show All 327 Lines • ▼ Show 20 Lines	this:

- There is a cluster setup with two devices, X and Y.		- There is a cluster setup with two devices, X and Y.
- A new change is pushed to server X.		- A new change is pushed to server X.
- Before the change can propagate to server Y, lightning strikes server X		- Before the change can propagate to server Y, lightning strikes server X
and destroys it.		and destroys it.

Here, all of the "leader" devices with the most up-to-date copy of the		Here, all of the "leader" devices with the most up-to-date copy of the
repository have been lost. Phabricator will freeze the repository refuse to		repository have been lost. Phabricator will freeze the repository refuse to
serve requests because it can not serve it consistently, and can not accept new		serve requests because it can not serve reads consistently and can not accept
writes without data loss.		new writes without data loss.

The most straightforward way to resolve this issue is to restore any leader to		The most straightforward way to resolve this issue is to restore any leader to
service. The change will be able to replicate to other devices once a leader		service. The change will be able to replicate to other devices once a leader
comes back online.		comes back online.

If you are unable to restore a leader or unsure that you can restore one		If you are unable to restore a leader or unsure that you can restore one
quickly, you can use the monitoring console to review which changes are		quickly, you can use the monitoring console to review which changes are
present on the leaders but not present on the followers by examining the		present on the leaders but not present on the followers by examining the
▲ Show 20 Lines • Show All 94 Lines • Show Last 20 Lines