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.