mirror of
https://github.com/EnterpriseDB/repmgr.git
synced 2026-03-23 07:06:30 +00:00
491309f4ba
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)
93 lines
3.4 KiB
Markdown
93 lines
3.4 KiB
Markdown
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. |