Merge branch 'docs/fix-bullet-list-ha' into 'master'

Fix markdown for HA topic

See merge request gitlab-org/gitlab-ce!29244

doc/administration/high_availability/database.md

@@ -106,13 +106,14 @@ deploy the bundled PostgreSQL.
 ### High Availability with GitLab Omnibus **[PREMIUM ONLY]**
 
 > Important notes:
+>
 > - This document will focus only on configuration supported with [GitLab Premium](https://about.gitlab.com/pricing/), using the Omnibus GitLab package.
 > - If you are a Community Edition or Starter user, consider using a cloud hosted solution.
 > - This document will not cover installations from source.
 >
 > - If HA setup is not what you were looking for, see the [database configuration document](http://docs.gitlab.com/omnibus/settings/database.html)
 >   for the Omnibus GitLab packages.
-
+>
 > Please read this document fully before attempting to configure PostgreSQL HA
 > for GitLab.
 >
@@ -171,13 +172,10 @@ Similarly, PostgreSQL access is controlled based on the network source.
 
 This is why you will need:
 
-> IP address of each nodes network interface
-> - This can be set to `0.0.0.0` to listen on all interfaces. It cannot
->   be set to the loopack address `127.0.0.1`
->
-> Network Address
-> - This can be in subnet (i.e. `192.168.0.0/255.255.255.0`) or CIDR (i.e.
->   `192.168.0.0/24`) form.
+- IP address of each nodes network interface. This can be set to `0.0.0.0` to
+  listen on all interfaces. It cannot be set to the loopack address `127.0.0.1`.
+- Network Address. This can be in subnet (i.e. `192.168.0.0/255.255.255.0`)
+  or CIDR (i.e. `192.168.0.0/24`) form.
 
 ##### User information
 
@@ -220,8 +218,7 @@ the number of database nodes in the cluster.
 This is used to prevent replication from using up all of the
 available database connections.
 
-> Note:
-> - In this document we are assuming 3 database nodes, which makes this configuration:
+In this document we are assuming 3 database nodes, which makes this configuration:
 
 ```
 postgresql['max_wal_senders'] = 4
@@ -327,7 +324,7 @@ On each Consul node perform the following:
 Before moving on, make sure Consul is configured correctly. Run the following
 command to verify all server nodes are communicating:
 
-```
+```sh
 /opt/gitlab/embedded/bin/consul members
 ```
 
@@ -401,14 +398,15 @@ check the [Troubleshooting section](#troubleshooting) before proceeding.
    repmgr['master_on_initialization'] = false
    ```
 
-1. [Reconfigure GitLab] for te changes to take effect.
+1. [Reconfigure GitLab] for the changes to take effect.
 
 > Please note:
+>
 > - If you want your database to listen on a specific interface, change the config:
->   `postgresql['listen_address'] = '0.0.0.0'`
+>   `postgresql['listen_address'] = '0.0.0.0'`.
 > - If your Pgbouncer service runs under a different user account,
 >   you also need to specify: `postgresql['pgbouncer_user'] = PGBOUNCER_USERNAME` in
->   your configuration
+>   your configuration.
 
 ##### Database nodes post-configuration
 
@@ -449,7 +447,6 @@ Select one node as a primary node.
    is not an IP address, it will need to be a resolvable name (via DNS or
    `/etc/hosts`)
 
-
 ###### Secondary nodes
 
 1. Set up the repmgr standby:
@@ -500,7 +497,7 @@ Before moving on, make sure the databases are configured correctly. Run the
 following command on the **primary** node to verify that replication is working
 properly:
 
-```
+```sh
 gitlab-ctl repmgr cluster show
 ```
 
@@ -518,7 +515,7 @@ If the 'Role' column for any node says "FAILED", check the
 
 Also, check that the check master command works successfully on each node:
 
-```
+```sh
 su - gitlab-consul
 gitlab-ctl repmgr-check-master || echo 'This node is a standby repmgr node'
 ```
@@ -665,13 +662,13 @@ can connect to each freely other on those addresses.
 
 Here is a list and description of each machine and the assigned IP:
 
-* `10.6.0.11`: Consul 1
-* `10.6.0.12`: Consul 2
-* `10.6.0.13`: Consul 3
-* `10.6.0.21`: PostgreSQL master
-* `10.6.0.22`: PostgreSQL secondary
-* `10.6.0.23`: PostgreSQL secondary
-* `10.6.0.31`: GitLab application
+- `10.6.0.11`: Consul 1
+- `10.6.0.12`: Consul 2
+- `10.6.0.13`: Consul 3
+- `10.6.0.21`: PostgreSQL master
+- `10.6.0.22`: PostgreSQL secondary
+- `10.6.0.23`: PostgreSQL secondary
+- `10.6.0.31`: GitLab application
 
 All passwords are set to `toomanysecrets`, please do not use this password or derived hashes.
 
@@ -735,7 +732,7 @@ consul['configuration'] = {
 
 On secondary nodes, edit `/etc/gitlab/gitlab.rb` and add all the configuration
 added to primary node, noted above. In addition, append the following
-configuration
+configuration:
 
 ```
 # HA setting to specify if a node should attempt to be master on initialization
@@ -839,10 +836,10 @@ In this example we start with all servers on the same 10.6.0.0/16 private networ
 
 Here is a list and description of each machine and the assigned IP:
 
-* `10.6.0.21`: PostgreSQL master
-* `10.6.0.22`: PostgreSQL secondary
-* `10.6.0.23`: PostgreSQL secondary
-* `10.6.0.31`: GitLab application
+- `10.6.0.21`: PostgreSQL master
+- `10.6.0.22`: PostgreSQL secondary
+- `10.6.0.23`: PostgreSQL secondary
+- `10.6.0.31`: GitLab application
 
 All passwords are set to `toomanysecrets`, please do not use this password or derived hashes.
 
@@ -853,6 +850,7 @@ Please note that after the initial configuration, if a failover occurs, the Post
 ##### Example minimal configuration for database servers
 
 ##### Primary node
+
 On primary database node edit `/etc/gitlab/gitlab.rb`:
 
 ```ruby
@@ -1047,7 +1045,6 @@ For example:
 repmgr['trust_auth_cidr_addresses'] = %w(192.168.1.44/32 db2.example.com)
 ```
 
-
 ##### MD5 Authentication
 
 If you are running on an untrusted network, repmgr can use md5 authentication
@@ -1157,8 +1154,6 @@ If you're running into an issue with a component not outlined here, be sure to c
 **Note**: We recommend that you follow the instructions here for a full [PostgreSQL cluster](#high-availability-with-gitlab-omnibus-premium-only).
 If you are reading this section due to an old bookmark, you can find that old documentation [in the repository](https://gitlab.com/gitlab-org/gitlab-ce/blob/v10.1.4/doc/administration/high_availability/database.md#configure-using-omnibus).
 
----
-
 Read more on high-availability configuration:
 
 1. [Configure Redis](redis.md)