Page MenuHomePhabricator
Files F14047007

D15704.diff
No OneTemporary
Actions

D15704.diff
View Options

diff --git a/src/docs/user/cluster/cluster.diviner b/src/docs/user/cluster/cluster.diviner
--- a/src/docs/user/cluster/cluster.diviner
+++ b/src/docs/user/cluster/cluster.diviner
@@ -10,7 +10,7 @@
WARNING: This feature is a very early prototype; the features this document
describes are mostly speculative fantasy.
-Phabricator can be configured to run on mulitple hosts with redundant services
+Phabricator can be configured to run on multiple hosts with redundant services
to improve its availability and scalability, and make disaster recovery much
easier.
@@ -36,7 +36,7 @@
To begin deploying Phabricator in cluster mode, set up `cluster.addresses`
in your configuration.
-This option should contain a list of network addess blocks which are considered
+This option should contain a list of network address blocks which are considered
to be part of the cluster. Hosts in this list are allowed to bend (or even
break) some of the security and policy rules when they make requests to other
hosts in the cluster, so this list should be as small as possible. See "Cluster
@@ -94,7 +94,7 @@
These mechanisms are still authenticated (and use asymmetric keys, like SSH
does), so access to a host in the cluster address block does not mean that an
-attacker can immediately compromise the cluster. However, an overbroad cluster
+attacker can immediately compromise the cluster. However, an over-broad cluster
address whitelist may give an attacker who gains some access additional tools
to escalate access.
@@ -181,10 +181,6 @@
other services use. It's also simpler to separate than other services, and
tends to benefit the most from dedicated hardware.
-**Just Databases**: Separating MySQL onto dedicated nodes
-
-Database nodes tend to benefit the most from
-
**Repositories and Daemons**: Run repositories and daemons on the same host.
Repository hosts //must// run daemons, and it normally makes sense to
completely overlay repositories and daemons. These services tend to use
@@ -192,8 +188,8 @@
daemons are heavier on CPU/RAM and lighter on I/O).
Repositories and daemons are also both less latency sensitive than other
-service types, so there's a wider margin of error for underprovisioning them
-before performance is noticably affected.
+service types, so there's a wider margin of error for under provisioning them
+before performance is noticeably affected.
These nodes tend to use system resources in a balanced way. Individual nodes
in this class do not need to be particularly powerful.
diff --git a/src/docs/user/cluster/cluster_daemons.diviner b/src/docs/user/cluster/cluster_daemons.diviner
--- a/src/docs/user/cluster/cluster_daemons.diviner
+++ b/src/docs/user/cluster/cluster_daemons.diviner
@@ -29,7 +29,7 @@
@{article:Cluster: Repositories}. These daemons are necessary: repositories
will not fetch, update, or synchronize properly without them.
-If your repository clustering is redundant (you have at least two repsoitory
+If your repository clustering is redundant (you have at least two repository
hosts), these daemons are also likely to be sufficient in most cases. If you
want to launch additional hosts anyway (for example, to increase queue capacity
for unusual workloads), see "Dedicated Daemon Hosts" below.
diff --git a/src/docs/user/cluster/cluster_databases.diviner b/src/docs/user/cluster/cluster_databases.diviner
--- a/src/docs/user/cluster/cluster_databases.diviner
+++ b/src/docs/user/cluster/cluster_databases.diviner
@@ -141,7 +141,7 @@
If things have been set up properly, Phabricator should degrade to a temporary
read-only mode immediately. After a brief period of unresponsiveness, it will
degrade further into a longer-term read-only mode. For details on how this
-works interanlly, see "Unreachable Masters" below.
+works internally, see "Unreachable Masters" below.
Once satisfied, turn the master back on. After a brief delay, Phabricator
should recognize that the master is healthy again and recover fully.
@@ -266,7 +266,7 @@
This mode only attempts to connect to the unhealthy database once every few
seconds to see if it is recovering, so performance will be better on average
(users rarely need to wait for bad connections to fail or time out) and the
-datbase will receive less load.
+database will receive less load.
Once all of the recent checks succeed, Phabricator will mark the database as
healthy again and continue sending traffic to it.
@@ -293,7 +293,7 @@
Although you should still have a backup process, your backup process can
safely pull dumps from a replica instead of the master. This operation can
-be slow, so offloading it to a replica can make the perforance of the master
+be slow, so offloading it to a replica can make the performance of the master
more consistent.
To dump from a replica, wait for this TODO to be resolved and then do whatever
diff --git a/src/docs/user/cluster/cluster_repositories.diviner b/src/docs/user/cluster/cluster_repositories.diviner
--- a/src/docs/user/cluster/cluster_repositories.diviner
+++ b/src/docs/user/cluster/cluster_repositories.diviner
@@ -34,7 +34,7 @@
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
+by examining a repository working copy, the webserver receiving the request
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.

File Metadata

Mime Type
text/plain
Expires
Fri, Nov 15, 1:18 AM (4 d, 11 h ago)
Storage Engine
blob
Storage Format
Encrypted (AES-256-CBC)
Storage Handle
6713104
Default Alt Text
D15704.diff (5 KB)

Event Timeline

Phabricator · Built by Phacility