@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.) hq.recaptime.dev/wiki/Phorge
phorge phabricator
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

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

+10 -14
+5 -9
src/docs/user/cluster/cluster.diviner
··· 10 10 WARNING: This feature is a very early prototype; the features this document 11 11 describes are mostly speculative fantasy. 12 12 13 - Phabricator can be configured to run on mulitple hosts with redundant services 13 + Phabricator can be configured to run on multiple hosts with redundant services 14 14 to improve its availability and scalability, and make disaster recovery much 15 15 easier. 16 16 ··· 36 36 To begin deploying Phabricator in cluster mode, set up `cluster.addresses` 37 37 in your configuration. 38 38 39 - This option should contain a list of network addess blocks which are considered 39 + This option should contain a list of network address blocks which are considered 40 40 to be part of the cluster. Hosts in this list are allowed to bend (or even 41 41 break) some of the security and policy rules when they make requests to other 42 42 hosts in the cluster, so this list should be as small as possible. See "Cluster ··· 94 94 95 95 These mechanisms are still authenticated (and use asymmetric keys, like SSH 96 96 does), so access to a host in the cluster address block does not mean that an 97 - attacker can immediately compromise the cluster. However, an overbroad cluster 97 + attacker can immediately compromise the cluster. However, an over-broad cluster 98 98 address whitelist may give an attacker who gains some access additional tools 99 99 to escalate access. 100 100 ··· 181 181 other services use. It's also simpler to separate than other services, and 182 182 tends to benefit the most from dedicated hardware. 183 183 184 - **Just Databases**: Separating MySQL onto dedicated nodes 185 - 186 - Database nodes tend to benefit the most from 187 - 188 184 **Repositories and Daemons**: Run repositories and daemons on the same host. 189 185 Repository hosts //must// run daemons, and it normally makes sense to 190 186 completely overlay repositories and daemons. These services tend to use ··· 192 188 daemons are heavier on CPU/RAM and lighter on I/O). 193 189 194 190 Repositories and daemons are also both less latency sensitive than other 195 - service types, so there's a wider margin of error for underprovisioning them 196 - before performance is noticably affected. 191 + service types, so there's a wider margin of error for under provisioning them 192 + before performance is noticeably affected. 197 193 198 194 These nodes tend to use system resources in a balanced way. Individual nodes 199 195 in this class do not need to be particularly powerful.
+1 -1
src/docs/user/cluster/cluster_daemons.diviner
··· 29 29 @{article:Cluster: Repositories}. These daemons are necessary: repositories 30 30 will not fetch, update, or synchronize properly without them. 31 31 32 - If your repository clustering is redundant (you have at least two repsoitory 32 + If your repository clustering is redundant (you have at least two repository 33 33 hosts), these daemons are also likely to be sufficient in most cases. If you 34 34 want to launch additional hosts anyway (for example, to increase queue capacity 35 35 for unusual workloads), see "Dedicated Daemon Hosts" below.
+3 -3
src/docs/user/cluster/cluster_databases.diviner
··· 141 141 If things have been set up properly, Phabricator should degrade to a temporary 142 142 read-only mode immediately. After a brief period of unresponsiveness, it will 143 143 degrade further into a longer-term read-only mode. For details on how this 144 - works interanlly, see "Unreachable Masters" below. 144 + works internally, see "Unreachable Masters" below. 145 145 146 146 Once satisfied, turn the master back on. After a brief delay, Phabricator 147 147 should recognize that the master is healthy again and recover fully. ··· 266 266 This mode only attempts to connect to the unhealthy database once every few 267 267 seconds to see if it is recovering, so performance will be better on average 268 268 (users rarely need to wait for bad connections to fail or time out) and the 269 - datbase will receive less load. 269 + database will receive less load. 270 270 271 271 Once all of the recent checks succeed, Phabricator will mark the database as 272 272 healthy again and continue sending traffic to it. ··· 293 293 294 294 Although you should still have a backup process, your backup process can 295 295 safely pull dumps from a replica instead of the master. This operation can 296 - be slow, so offloading it to a replica can make the perforance of the master 296 + be slow, so offloading it to a replica can make the performance of the master 297 297 more consistent. 298 298 299 299 To dump from a replica, wait for this TODO to be resolved and then do whatever
+1 -1
src/docs/user/cluster/cluster_repositories.diviner
··· 34 34 repository services on the same hosts. 35 35 36 36 When a user requests information about a repository that can only be satisfied 37 - by examining a repository working copy, the webserver receiving the reqeust 37 + by examining a repository working copy, the webserver receiving the request 38 38 will make an HTTP service call to a repository server which hosts the 39 39 repository to retrieve the data it needs. It will use the result of this query 40 40 to respond to the user.