github/repmgr
1
0
Fork 0
mirror of https://github.com/EnterpriseDB/repmgr.git synced 2026-03-23 15:16:29 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity
Files
fb8296644dbdee5fb001aca893476d263704b35a
repmgr/FAQ.md
Ian Barwick 491309f4ba Write events of note to a log table 
This makes keeping track of events such as failovers
much easier. Note that this is for convenience and is
not a foolproof auditing log.

Sample output:

repmgr_db=# SELECT * from repmgr_test.repl_events ;
 node_id |          event           | successful |        event_timestamp        |                         details
---------+--------------------------+------------+-------------------------------+----------------------------------------------------------
       1 | master_register          | t          | 2015-03-06 14:14:08.196636+09 |
       2 | standby_clone            | t          | 2015-03-06 14:14:17.660768+09 | Backup method: pg_basebackup; --force: N
       2 | standby_register         | t          | 2015-03-06 14:14:18.762222+09 |
       4 | witness_create           | t          | 2015-03-06 14:14:22.072815+09 |
       3 | standby_clone            | t          | 2015-03-06 14:14:23.524673+09 | Backup method: pg_basebackup; --force: N
       3 | standby_register         | t          | 2015-03-06 14:14:24.620161+09 |
       2 | repmgrd_start            | t          | 2015-03-06 14:14:29.639096+09 |
       3 | repmgrd_start            | t          | 2015-03-06 14:14:29.641489+09 |
       4 | repmgrd_start            | t          | 2015-03-06 14:14:29.648002+09 |
       2 | standby_promote          | t          | 2015-03-06 14:15:01.956737+09 | Node 2 was successfully be promoted to master
       2 | repmgrd_failover_promote | t          | 2015-03-06 14:15:01.964771+09 | Node 2 promoted to master; old master 1 marked as failed
       3 | repmgrd_failover_follow  | t          | 2015-03-06 14:15:07.228493+09 | Node 3 now following new upstream node 2
(12 rows)
2015-03-06 14:35:41 +09:00

3.4 KiB
Raw Blame History

FAQ - Frequently Asked Questions about repmgr

This FAQ applies to repmgr 3.0 and later.

General

  • What's the difference between the repmgr versions?

    repmgr v3 builds on the improved replication facilities added in PostgreSQL 9.3, as well as improved automated failover support via repmgrd, and is not compatible with PostgreSQL 9.2 and earlier.

    repmgr v2 supports PostgreSQL 9.0 onwards. While it is compatible with PostgreSQL 9.3 and later, we recommend repmgr v3.

  • What's the advantage of using replication slots?

    Replication slots, introduced in PostgreSQL 9.4, ensure that the master server will retain WAL files until they have been consumed by all standby servers. This makes WAL file management much easier, and if used repmgr will no longer insist on a fixed number (default: 5000) of WAL files being preserved.

    (However this does mean that if a standby is no longer connected to the master, the master will retain WAL files indefinitely).

  • What's the difference between the repl_status view and repl_events table?

    The repl_status view shows the latest node status as reported by repmgrd and is useful for monitoring current lag. repl_events is a record of significant events which have taken place, such as a node being registered or a failover event.

repmgr

  • When should I use the --rsync-only option?

    By default, repmgr uses pg_basebackup to clone a standby from a master. However, pg_basebackup copies the entire data directory, which can take some time depending on installation size. If you have an existing but "stale" standby, repmgr can use rsync instead, which means only changed or added files need to be copied.

  • Can I register an existing master/standby?

    Yes, this is no problem.

  • How can a failed master be re-added as a standby?

  • Is there an easy way to check my master server is correctly configured for use with repmgr?

    Yes - execute repmgr with the --check-upstream-config option, and it will let you know which items in postgresql.conf need to be modified.

  • Even though I specified custom rsync options, rempgr appends the --checksum - why?

    When syncing a stale data directory from an active server, it's essential that rsync compares the content of files rather than just timestamp and size, to ensure that all changed files are copied and prevent corruption.

  • How can I prevent rempgr from copying postgresql.conf and pg_hba.conf from the PostgreSQL configuration directory in /etc?

    Include the option ignore_external_config_files=1 in repmgr.conf

  • How can I prevent rempgr from copying local configuration files in the data directory?

    If you're updating an existing but stale data directory which contains e.g. configuration files you don't want to be overwritten with the same file from the master, specify the files in the rsync_options configuration option, e.g.

    rsync_options=--exclude=postgresql.local.conf

    This option is only available when using the --rsync-only option.

repmgrd

  • Do I need a witness server?

    Not necessarily. However if you have an uneven number of nodes spread over more than one network segment, a witness server will enable better handling of a 'split brain' situation by providing a "casting vote" on the preferred network segment.

Reference in New Issue View Git Blame Copy Permalink