Fix some typos in the new cluster docs

Summary:
While reading the new cluster docs, I noticed a few minor typos, and one
section that seemed to be incomplete and redundant, so I just removed it.

Test Plan: none.

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: chad, Korvin, jshirley

Differential Revision: https://secure.phabricator.com/D15704

src/docs/user/cluster/cluster.diviner

@@ -10,7 +10,7 @@ Overview
 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 @@ Preparing for Clustering
 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 @@ the user within the cluster.
 
 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 @@ host, and MySQL on a different host. MySQL uses many of the same resources that
 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 @@ different resources (repositories are heavier on I/O and lighter on CPU/RAM;
 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.

src/docs/user/cluster/cluster_daemons.diviner

@@ -29,7 +29,7 @@ repository host according to the documentation in
 @{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.

src/docs/user/cluster/cluster_databases.diviner

@@ -141,7 +141,7 @@ run the `mysqld stop` command.
 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 @@ until it recovers.
 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 @@ backup snapshots.
 
 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

src/docs/user/cluster/cluster_repositories.diviner

@@ -34,7 +34,7 @@ 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
+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.