From 8faf41dd94b01aa0735a6ba8b9ead60b65065ac1 Mon Sep 17 00:00:00 2001 From: Ian Barwick Date: Thu, 18 Dec 2014 16:41:24 +0900 Subject: [PATCH] Fix markup --- QUICKSTART.md | 60 +++++++++++++++++++++++++-------------------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/QUICKSTART.md b/QUICKSTART.md index 89b85934..d0b492bb 100644 --- a/QUICKSTART.md +++ b/QUICKSTART.md @@ -1,7 +1,7 @@ repmgr: Quickstart guide ======================== -repmgr is an open-source tool suite for mananaging replication and failover +`repmgr` is an open-source tool suite for mananaging replication and failover among multiple PostgreSQL server nodes. It enhances PostgreSQL's built-in hot-standby capabilities with a set of administration tools for monitoring replication, setting up standby servers and performing failover/switchover @@ -14,14 +14,14 @@ covering setup on a variety of different systems, see the README.rst file. Conceptual Overview ------------------- -repmgr provides two binaries: +`repmgr` provides two binaries: - - `repmgr`: a command-line client to manage replication and repmgr configuration + - `repmgr`: a command-line client to manage replication and `repmgr` configuration - `repmgrd`: an optional daemon process which runs on standby nodes to monitor replication and node status -Each PostgreSQL node requires a repmgr configuration file; additionally -it must be "registered" using the repmgr command-line client. repmgr stores +Each PostgreSQL node requires a `repmgr` configuration file; additionally +it must be "registered" using the `repmgr` command-line client. `repmgr` stores information about managed nodes in a custom schema on the node's current master database. @@ -29,31 +29,31 @@ database. Requirements ------------ -repmgr works with PostgreSQL 9.0 and later. All server nodes must be running the +`repmgr` works with PostgreSQL 9.0 and later. All server nodes must be running the same PostgreSQL major version, and preferably should be running the same minor version. -repmgr will work on any Linux or UNIX-like environment capable of running +`repmgr` will work on any Linux or UNIX-like environment capable of running PostgreSQL. `rsync` must also be installed. Installation ------------ -repmgr must be installed on each PostgreSQL server node. +`repmgr` must be installed on each PostgreSQL server node. * Packages - RPM packages for RedHat-based distributions are available from PGDG - Debian/Ubuntu provide .deb packages. - It is also possible to build .deb packages directly from the repmgr source; + It is also possible to build .deb packages directly from the `repmgr` source; see README.rst for further details. * Source installation - - repmgr source code is hosted at github (https://github.com/2ndQuadrant/repmgr); - tar.gz files can be downloaded from https://github.com/2ndQuadrant/repmgr/releases . + - `repmgr` source code is hosted at github (https://github.com/2ndQuadrant/`repmgr`); + tar.gz files can be downloaded from https://github.com/2ndQuadrant/`repmgr`/releases . - repmgr can be built easily using PGXS: + `repmgr` can be built easily using PGXS: sudo make USE_PGXS=1 install @@ -64,7 +64,7 @@ Configuration ### Server configuration Password-less SSH logins must be enabled for the database system user (typically `postgres`) -between all server nodes to enable repmgr to copy required files. +between all server nodes to enable `repmgr` to copy required files. ### PostgreSQL configuration @@ -78,21 +78,21 @@ following settings: wal_keep_segments = 5000 # in logfile segments, 16MB each; 0 disables hot_standby = on # "on" allows queries during recovery -Note that repmgr expects a default of 5000 wal_keep_segments, although this +Note that `repmgr` expects a default of 5000 wal_keep_segments, although this value can be overridden when executing the `repmgr` client. -Additionally, repmgr requires a dedicated PostgreSQL superuser account -and a database in which to store monitoring and replication data. The repmgr +Additionally, `repmgr` requires a dedicated PostgreSQL superuser account +and a database in which to store monitoring and replication data. The `repmgr` user account will also be used for replication connections from the standby, so a seperate replication user with the `REPLICATION` privilege is not required. The database can in principle be any database, including the default `postgres` -one, however it's probably advisable to create a dedicated database for repmgr +one, however it's probably advisable to create a dedicated database for `repmgr` usage. ### repmgr configuration -Each PostgreSQL node requires a repmgr configuration file containing +Each PostgreSQL node requires a `repmgr` configuration file containing identification and database connection information: cluster=test @@ -113,9 +113,9 @@ identification and database connection information: Note that the configuration file should *not* be stored inside the PostgreSQL data directory. -Each node configuration needs to be registered with repmgr, either using the +Each node configuration needs to be registered with `repmgr`, either using the `repmgr` command line tool, or the `repmgrd` daemon; for details see below. Details -about each node are inserted into the repmgr database (for details see below). +about each node are inserted into the `repmgr` database (for details see below). Replication setup and monitoring @@ -141,9 +141,9 @@ Master setup CREATE DATABASE repmgr_db OWNER repmgr_usr; ``` - - configure postgresql.conf for replication (see above) + - configure `postgresql.conf` for replication (see above) - - update pg_hba.conf, e.g.: + - update `pg_hba.conf`, e.g.: ``` host repmgr_db repmgr_usr 192.168.1.0/24 trust @@ -151,7 +151,7 @@ Master setup ``` Restart the PostgreSQL server after making these changes. -2. Create the repmgr configuration file: +2. Create the `repmgr` configuration file: $ cat $HOME/repmgr/repmgr.conf cluster=test @@ -160,7 +160,7 @@ Master setup conninfo='host=repmgr_node1 user=repmgr_usr dbname=repmgr_db' pg_bindir=/path/to/postgres/bin -3. Register the master node with repmgr: +3. Register the master node with `repmgr`: $ repmgr -f $HOME/repmgr/repmgr.conf --verbose master register [2014-07-04 10:43:42] [INFO] repmgr mgr connecting to master database @@ -172,7 +172,7 @@ Master setup Slave/standby setup ------------------- -1. Use repmgr to clone the master: +1. Use `repmgr` to clone the master: $ repmgr -D $PGDATA -d repmgr_db -U repmgr_usr -R postgres --verbose standby clone 192.168.1.2 Opening configuration file: ./repmgr.conf @@ -200,7 +200,7 @@ Slave/standby setup 2. Start the PostgreSQL server -3. Create the repmgr configuration file: +3. Create the `repmgr` configuration file: $ cat $HOME/repmgr/repmgr.conf cluster=test @@ -209,7 +209,7 @@ Slave/standby setup conninfo='host=repmgr_node2 user=repmgr_usr dbname=repmgr_db' pg_bindir=/path/to/postgres/bin -4. Register the master node with repmgr: +4. Register the master node with `repmgr`: $ repmgr -f $HOME/repmgr/repmgr.conf --verbose standby register Opening configuration file: /path/to/repmgr/repmgr.conf @@ -258,8 +258,8 @@ To promote a standby to master, on the standby execute e.g.: repmgr -f $HOME/repmgr/repmgr.conf --verbose standby promote -repmgr will attempt to connect to the current master to verify that it -is not available (if it is, repmgr will not promote the standby). +`repmgr` will attempt to connect to the current master to verify that it +is not available (if it is, `repmgr` will not promote the standby). Other standby servers need to be told to follow the new master with: @@ -272,7 +272,7 @@ automated failover. repmgr database schema ---------------------- -repmgr creates a small schema for its own use in the database specified in +`repmgr` creates a small schema for its own use in the database specified in each node's conninfo configuration parameter. This database can in principle be any database. The schema name is the global `cluster` name prefixed with `repmgr_`, so for the example setup above the schema name is