Shulou(Shulou.com)06/02 Report--

Today, I will talk to you about PostgreSQL highly available Repmgr commands and configuration files, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

This should be the third piece of highly available text about PostgreSQL. Some common commands and configuration files in use of Repmgr need to be clear today.

Let's start with the configuration file. If you don't know how to write your configuration file, or if you don't know what's in the configuration file, please start with

Obtained from the https://repmgr.org/docs/4.4/repmgr-administration-manual.html website.

Some of the profile contents:

Node_id=1 node_id is the sequence number of the node that identifies the database. When using other commands, you need to specify the relevant sequence number, and the related sequence number can not be repeated in a cluster.

Node_name = 'XXX' node name is the name that identifies the machine in the cluster. It should be noted that the name cannot exceed 63 characters and, preferably in lowercase, clearly identify the machine.

Conninfo='host=192.168.198.112 user=repmgr dbname=repmgr connect_timeout=2' this is the information that identifies the connection to the PG in each cluster. Connect_timeout is configured to ignore some length of waiting time that may lead to misswitching due to network delays or failures when you use repmgrd.

Data_directory='/pgdata/data' this is the data directory that specifies the PG of the current machine, because the data directory of each machine in some cluster may be inconsistent for some reason, so here will tell repmgr where the specific data directory is.

Config_directory='' this is the configuration ID. The location of the configuration file of PG can not be configured generally. If your configuration file is not placed with the data directory, you need to configure it.

Replication_user='repmgr' configures the replicated account in PG. Here repmgr is used as the replicated account. Of course, you can use another account to replicate the configuration, but you don't have to use repmgr as the replicated account.

Replication_type=physical here needs to tell REPMGR PG how to copy, which is generally recommended for physical if there are no special requirements.

Location=default is configured to serve multiple data centers. If there are multiple data centers, it is generally assumed that if the network is unstable, whether to switch or not to do anything, location is to identify the location of your machine.

Witness_sync_interval this is the time when the third party's witness server gets the information to the witness server.

Log_level = INFO here specifies that the level of log has eight related levels

Log_file='' redirects the write location of the LOG file otherwise it can only be written to the system's STDERR

Pg_bindir= specifies the directory of PG's execution files

Repmgr_bindir = specifies the directory of the repmgr execution files for PG

Failover=manual specifies whether the node is handled automatically or manually when the primary node failover occurs

Priority = 100When you have multiple PG slave nodes, how can you artificially determine which one is more suitable for the next master node?

Reconnect_attempts = the number of times to reenter the connection when the primary node cannot be connected

Of course, the above introduction is relatively basic information, and some items with deeper meanings and settings are not included. For example, in MYSQL MHA, if the master node switches, MHA will let the user fill in the external script that will be executed in the next step. There are also relevant settings in REPMGR.

After roughly talking about the relevant configuration files, here is an introduction to some basic REPMGR basic commands

1 manually switch between master and slave nodes

Generally speaking, if you want to upgrade the server of the main library, or the operation will need to shut down the main library, and such behavior is prepared and planned.

Let's switch the master library to the slave library through manual commands.

Please execute the following command from the library server, and the following will start to simulate the switching process or tell you some information or error messages. If you remove-dry-run, it will actually be executed. Students who have used pt-osc will have a profound impact on-- dry-run.

Repmgr-f / etc/repmgr.conf standby switchover-- dry-run

After switching, after viewing the current cluster information, changes will be made accordingly.

This is a more useful feature.

2 promote from the library to the main library

When you choose FAILOVER to manually upgrade from the library to the main library, you need to manually upgrade the main library.

Repmgr-f / etc/repmgr.conf standby promote

3 View the status of the current node

Repmgr-f / etc/repmgr.conf node status

4 after the failure of the master node, it is not appropriate for other slave nodes to connect to the failed master node or the lost connection, and relevant commands are needed to reconnect these misconnected nodes to the new master node. In the wrong connection to the primary node

Repmgr-f / etc/repmgr.conf standby follow

5 View the connection between the current node and other nodes

Repmgr-f / etc/repmgr.conf cluster matrix

Summary: in fact, in the use of repmgr, you can feel that repmgr is a good tool for quickly establishing streams to replicate the state between slave libraries and check nodes, even if you don't need automatic failover.

After reading the above, do you have any further understanding of the PostgreSQL highly available Repmgr commands and configuration files? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.