High availability method and system for PostgreSQL database

Abstract

The invention discloses a high availability method for a PostgreSQL database. The high availability method comprises the steps that a basic database environment of the PostgreSQL database is set up; configuring a master-slave environment of the master node and the slave node; sSH mutual trust of all nodes is configured; a repmgr open source tool suite is installed on each node, and corresponding configuration is carried out; configuration of a floating virtual IP is carried out, and automatic migration of a main library fault is realized; configuring multiple data sources on an application side to realize read-write separation; and a load balancing strategy is configured, and the final high-availability method for the PostgreSQL database is completed. The invention further discloses a system for realizing the high availability method for the PostgreSQL database. According to the method, a high-availability scheme for the PostgreSQL database is realized, the reliability is higher, and the safety is better.

Description

Technical Field

[0001] The present invention belongs to the technical field of databases, and in particular relates to a high availability method and system for a PostgreSQL database. Background Art

[0002] With the development of economy and technology and the advent of the intelligent era, database systems, as special systems that carry data storage and computing functions, have become the most mainstream data processing tools and an important carrier of enterprise data workflows.

[0003] At present, various activities of enterprises are increasingly dependent on their key business information systems. These business systems play a vital role in the normal operation and development of the entire enterprise. If some key application systems fail, it will cause huge losses to the enterprise. Therefore, a mature application system needs to have high availability. As the data base of the application system, the high availability solution of the database system has attracted much attention.

[0004] At present, relational databases, including Oracle and PostgreSQL databases, have been widely used in various industries. Among them, Oracle database, as a commercial closed-source database, has provided a variety of high-availability solutions such as RAC (Real Application Clusters); however, the high-availability solutions of PostgreSQL database mostly rely on middleware such as pgpool and citus, which have great performance problems and functional limitations, thus greatly restricting the application and development of PostgreSQL database. Summary of the invention

[0005] One of the purposes of the present invention is to provide a high availability method for a PostgreSQL database with high reliability and good security.

[0006] A second object of the present invention is to provide a system for implementing the high availability method for a PostgreSQL database.

[0007] The high availability method for the PostgreSQL database provided by the present invention comprises the following steps:

[0008] S1. Build the basic database environment of PostgreSQL database;

[0009] S2. Configure the master-slave environment of the master node and the slave node;

[0010] S3. Configure SSH mutual trust for all nodes;

[0011] S4. Install the repmgr open source tool suite on each node and perform corresponding configurations;

[0012] S5. Based on the repmgr open source tool suite in step S4, configure the floating virtual IP and implement automatic migration of the main library failure;

[0013] S6. Configure multiple data sources on the application side to achieve read-write separation;

[0014] S7. Configure the load balancing strategy to complete the final high availability method for the PostgreSQL database.

[0015] The basic database environment for building a PostgreSQL database described in step S1 specifically includes the following steps:

[0016] The basic database environment of the PostgreSQL database is built, including a master node, several slave nodes, an authentication node and a floating virtual IP address;

[0017] The software environment includes: the database operating system is CentOS Linux release 7.5.1804 (Core); the database operating system character set is en_US.UTF-8; the PostgreSQL database version is Postgres12.11; the PostgreSQL database character set is UTF-8;

[0018] Install the same version of PostgreSQL database and corresponding dependent software packages on the master node, slave node, and authentication node, create the database home directory and postgres user, set the database environment variables, initialize the database of each node and start verification.

[0019] The master-slave environment of configuring the master node and the slave node in step S2 specifically includes the following steps:

[0020] Configure the master node: create a replication user repmgr and a database repmgr; the owner of the repmgr database is the user repmgr; configure the PostgreSQL database authentication file pg_hba.conf on the master node, configure the md5 authentication channel for the replication users of the master node, slave node, and authentication node; configure the main configuration file postgresql.conf and enable archiving; after the configuration is complete, restart the master node library and verify from other nodes to ensure that the postgres user can log in to the master node normally;

[0021] Configure the slave node: Stop the PostgreSQL database and clear all contents of the database data file directory; use the pg_basebackup tool that comes with the PostgreSQL database software and the replication user repmgr to transfer the database of the master node to the slave node to establish a master-slave relationship and perform verification.

[0022] Step S3 of configuring SSH mutual trust of all nodes specifically includes the following steps:

[0023] Use the mutual trust test script to configure mutual trust for SSH login between the postgres users of the master node, slave node, and authentication node.

[0024] After the configuration is complete, verify it.

[0025] Step S4 includes installing the repmgr open source tool suite on each node and performing corresponding configuration, which specifically includes the following steps:

[0026] Install the repmgr open source tool suite on the master node and slave node; perform basic configuration and initialization of repmgr; the initialization includes configuring the host name, configuring the port number, and setting the user name and password;

[0027] Configure the PostgreSQL database authentication file pg_hba.conf for the master node, slave node, and authentication node; for each node, configure the permissions for other nodes to access this node; the configuration content includes "TYPE", "DATABASE", "USER", "ADDRESS", and "METHOD"; during configuration, the first configuration is: "TYPE" is "host", "DATABASE" is "replication", "USER" is "repmgr", "ADDRESS" is the source address IP, and "METHOD" is "trust"; the second configuration is: "TYPE" is "host", "DATABASE" is "repmgr database", "USER" is "repmgr", "ADDRESS" is the source address IP, and "METHOD" is "trust"; the first configuration is applicable to data synchronization from the master node to the slave node in the replication process, and the second configuration is applicable to access control of the standby database and monitoring operations; after the configuration is completed, perform the pg_ctlrepload operation to make the configuration effective;

[0028] Configure the master node repmgr: configure the master database repmgr, enable automatic failover, and configure the failover script repmgr_promote_command.sh after the master database crashes; configure "follow_command" to configure the program or script defined in the failover to be executed when repmgrd determines that the current node will follow the new master node; use the repmgr command to register the master node and verify it;

[0029] Configure the slave node repmgr: Configure the slave database repmgr, enable automatic failover, and configure the failover script repmgr_promote_command.sh after the master database crashes; configure "follow_command" to configure the program or script defined in the configuration to be executed in the failover situation when repmgrd determines that the current node will follow the new master node; register the slave node using the repmgr command and verify it; between the master and slave databases, configure the repmgrd daemon process to the shared_preload_libraries in the Postgresql.conf library file. The shared_preload_libraries is used to specify the parameters of the shared library list loaded into memory during the database server startup process;

[0030] Configure the attestation node repmgr: configure the attestation database repmgr, enable automatic failover, and configure the failover script repmgr_promote_command.sh after the main database crashes; configure "follow_command" to configure the program or script defined in the failover to be executed when repmgrd determines that the current node will follow the new primary node; use the repmgr command to register the attestation node and verify it;

[0031] Restart the PostgreSQL database for both the master and slave nodes, and then restart the repmgrd daemon after success.

[0032] The repmgr open source tool kit described in step S5 is based on step S4 to configure the floating virtual IP and realize automatic migration of the main database failure, which specifically includes the following steps:

[0033] Install and configure Keepalived, and use it as a tool to provide floating virtual IP: Install the keepalived installation package and related dependency packages on the master node and the slave node; Configure the configuration file keepalived.conf on the master node and the slave node respectively, and ensure that the parameter "priority" of the master node is higher than that of the slave node; Configure the three scripts checkpg.sh, master.sh, and slave.sh according to the actual situation of each node; Authorize and start keepalived as root to verify that the floating virtual IP is mounted successfully;

[0034] Configure floating virtual IP in repmgr: Configure the failover script repmgr_promote_command.sh. The configuration idea is to monitor the repmgrd daemon after a failover event occurs → trigger the promote_command command → delete the floating virtual IP operation → test whether the floating virtual IP has been successfully uninstalled → promote the slave node to the master node → mount the floating virtual IP on the new master node → clear the ARP cache; restart repmgrd on the master node and the slave node respectively;

[0035] Add the floating virtual IP to the network card in the master node, and then verify that you can log in to the master database from other nodes using the floating virtual IP address.

[0036] The configuration of multiple data sources on the application side in step S6 to achieve read-write separation specifically includes the following steps:

[0037] In the nacos configuration files of several services in the application system, configure dual database source information to identify whether the service interface's operation on the database is a read request or a write request, and adapt to different database sources based on the identification results.

[0038] The configuration of the load balancing strategy described in step S7 specifically includes the following steps:

[0039] Use the least number of connections method as the load balancing strategy.

[0040] The present invention also discloses a system for realizing the high availability method for PostgreSQL database, comprising an environment building module, an environment configuration module, a mutual trust configuration module, a tool configuration module, an automatic migration module, a source configuration module and a load configuration module; the environment building module, the environment configuration module, the mutual trust configuration module, the tool configuration module, the automatic migration module, the source configuration module and the load configuration module are connected in series in sequence; the environment building module is used to build a basic database environment of PostgreSQL database, and upload data information to the environment configuration module; the environment configuration module is used to configure the master-slave environment of the master node and the slave node according to the received data information, and upload the data information to the mutual trust configuration module; the mutual trust configuration module is used to configure the SS of all nodes according to the received data information H mutual trust, and upload the data information to the tool configuration module; the tool configuration module is used to install the repmgr open source tool suite on each node according to the received data information, and perform corresponding configuration, and upload the data information to the automatic migration module; the automatic migration module is used to configure the floating virtual IP based on the repmgr open source tool suite according to the received data information, and realize automatic migration of the main database failure, and upload the data information to the source configuration module; the source configuration module is used to configure multiple data sources on the application side according to the received data information to realize read-write separation, and upload the data information to the load configuration module; the load configuration module is used to configure the load balancing strategy according to the received data information, and complete the final high availability solution for the PostgreSQL database.

[0041] The high availability method and system for PostgreSQL database provided by the present invention not only realizes a high availability solution for PostgreSQL database, but also has higher reliability and better security through a one-master-multiple-slave solution designed for PostgreSQL database, as well as a corresponding multi-data source configuration solution and load balancing strategy. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 The figure is a schematic diagram of the method flow of the present invention.

[0043] Figure 2 Schematic diagram of the functional modules of the system of the present invention. DETAILED DESCRIPTION

[0044] like Figure 1 The method flow diagram of the method of the present invention is shown as follows: The high availability method for PostgreSQL database disclosed in the present invention comprises the following steps:

[0045] S1. Build the basic database environment of PostgreSQL database; specifically include the following steps:

[0046] The basic database environment of the PostgreSQL database is built, including a master node, several slave nodes, an authentication node and a floating virtual IP address;

[0047] The software environment includes: the database operating system is CentOS Linux release 7.5.1804 (Core); the database operating system character set is en_US.UTF-8; the PostgreSQL database version is Postgres12.11; the PostgreSQL database character set is UTF-8;

[0048] Install the same version of PostgreSQL database and corresponding dependent software packages on the master node, slave node, and authentication node, create the database home directory and postgres user, set the database environment variables, initialize the database of each node, and start verification;

[0049] S2. Configure the master-slave environment of the master node and the slave node; specifically includes the following steps:

[0050] Configure the master node: create a replication user repmgr and a database repmgr; the owner of the repmgr database is the user repmgr; configure the PostgreSQL database authentication file pg_hba.conf on the master node, configure the replication user of the master node, slave node and authentication node with the md5 authentication channel; configure the main configuration file postgresql.conf, set the maximum number of connections (max_connections), log path (log_directory, log_filename) to appropriate values ​​and enable archiving (archive_mode=on); after the configuration is complete, restart the master node library and verify from other nodes to ensure that the postgres user can log in to the master node normally;

[0051] Configure the slave node: stop the PostgreSQL database and clear all the contents of the database data file directory; use the pg_basebackup tool that comes with the PostgreSQL database software and the replication user repmgr to transfer the database of the master node to the slave node to establish a master-slave relationship and perform verification;

[0052] S3. Configure SSH mutual trust for all nodes; specifically, the following steps are included:

[0053] Use the mutual trust test script (preferably the sshUserSetup.sh script that comes with the Oracle database) to configure mutual trust for SSH logins between postgres users of the master node, slave node, and authentication node. This involves the creation and storage of RSA keys.

[0054] After the configuration is complete, verify it;

[0055] S4. Install the repmgr open source tool suite on each node and perform corresponding configurations; specifically, the steps are as follows:

[0056] Install the repmgr open source tool suite on the master node and the slave node (preferably install the specified repmgr tool suite version using the yum package manager); perform basic configuration and initialization on repmgr; the initialization includes configuring the host name, configuring the port number, and setting the user name and password;

[0057] Configure the PostgreSQL database authentication file pg_hba.conf for the master node, slave node, and authentication node; for each node, configure the permissions for other nodes to access this node; the configuration content includes "TYPE", "DATABASE", "USER", "ADDRESS", and "METHOD"; during configuration, the first configuration is: "TYPE" is "host", "DATABASE" is "replication", "USER" is "repmgr", "ADDRESS" is the source address IP, and "METHOD" is "trust" (i.e., not encrypted); the second configuration is: "TYPE" is "host", "DATABASE" is "repmgr database", "USER" is "repmgr", "ADDRESS" is the source address IP, and "METHOD" is "trust" (i.e., not encrypted); the first configuration is applicable to data synchronization from the master node to the slave node in the replication process, and the second configuration is applicable to access control of the standby database and monitoring operations; after the configuration is completed, perform the pg_ctlrepload operation to make the configuration effective;

[0058] Configure the master node repmgr to achieve basic self-healing: configure the master database repmgr, enable automatic failover (i.e. configure "failover = automatic"), configure the failover script repmgr_promote_command.sh after the master database crashes, and configure it in the "promote_command" parameter (when repmgrd determines that the current node will become the new master node, the program or script defined in will be executed in the failover situation); configure "follow_command", and configure the program or script defined in will be executed in the failover situation when repmgrd determines that the current node will follow the new master node; use the repmgr command to register the master node and verify it;

[0059] Configure the slave node repmgr to achieve basic self-healing: configure the slave database repmgr, enable automatic failover, and configure the failover script repmgr_promote_command.sh after the master database crashes; configure "follow_command" to configure the program or script defined in the configuration to be executed in the failover situation when repmgrd determines that the current node will follow the new master node; use the repmgr command to register the slave node and verify it; it should be noted that the error message "ERROR: local node not attached to primary node 224" may be fed back here to prompt that the execution failed; in this case, you need to add "-F" to force execution, as follows:

[0060] repmgr-f / etc / repmgr / 12 / repmgr.conf standby register-F

[0061] repmgr-f / etc / repmgr / 12 / repmgr.conf standby follow-F

[0062] Between the master and slave libraries, configure the repmgrd daemon to the shared_preload_libraries in the Postgresql.conf library file. The shared_preload_libraries parameter specifies the list of shared libraries that are loaded into memory during database server startup.

[0063] Configure the attestation node repmgr: configure the attestation database repmgr, enable automatic failover, and configure the failover script repmgr_promote_command.sh after the main database crashes; configure "follow_command" to configure the program or script defined in the failover to be executed when repmgrd determines that the current node will follow the new primary node; use the repmgr command to register the attestation node and verify it;

[0064] Restart the PostgreSQL database for the master node and the slave node, and then restart the repmgrd daemon after success;

[0065] S5. Based on the repmgr open source tool suite in step S4, configure the floating virtual IP and implement automatic migration of the main database failure; specifically, the following steps are included:

[0066] Install and configure Keepalived, and use it as a tool to provide floating virtual IP: Install the keepalived installation package and related dependency packages on the master node and the slave node; Configure the configuration file keepalived.conf on the master node and the slave node respectively, and ensure that the parameter "priority" of the master node is higher than that of the slave node; Configure the three scripts checkpg.sh, master.sh, and slave.sh according to the actual situation of each node; Authorize and start keepalived as root to verify that the floating virtual IP is mounted successfully;

[0067] Configure floating virtual IP in repmgr: Configure the failover script repmgr_promote_command.sh. The configuration idea is to monitor the repmgrd daemon after a failover event occurs → trigger the promote_command command → delete the floating virtual IP operation → test whether the floating virtual IP has been successfully uninstalled → promote the slave node to the master node → mount the floating virtual IP on the new master node → clear the ARP cache; restart repmgrd on the master node and the slave node respectively;

[0068] Add the floating virtual IP to the network card in the master node, and then verify that other nodes can log in to the master database using the floating virtual IP address;

[0069] S6. Configure multiple data sources on the application side to achieve read-write separation; specifically, the steps include:

[0070] In information systems, the frequency of read operation requests is generally much greater than the frequency of write operation requests. To alleviate the load pressure on the master database, it is necessary to consider loading the client-level read operation requests and write operation requests to the slave node and the master node respectively. In this way, under the premise of ensuring the consistency of master and slave data, high-concurrency read requests can be loaded to multiple slave nodes, while write requests are directly loaded to the master node, and then the master node synchronizes the data to each slave node through stream replication.

[0071] Therefore, in the nacos configuration files of several services in the application system, configure the dual database source information to identify whether the service interface's operation on the database is a read request or a write request, and adapt to different database sources based on the identification results;

[0072] S7. Configure the load balancing strategy to complete the final high availability method for the PostgreSQL database;

[0073] When there are high-concurrency read operation requests, multiple slave libraries need to share the traffic pressure; therefore, it is also necessary to configure a load balancing strategy on the application side; commonly used load balancing strategies include polling, weighted polling, fastest response, minimum number of connections, etc.; because of the resource limitations of the information system (memory, CPU, etc.), the minimum number of connections is considered as the load balancing strategy during specific implementation, which can also avoid memory pressure and performance pressure caused by too many single-machine connections.

[0074] The method of the present invention replaces the traditional one-master-one-slave system with one-master-multiple-slave system. When the master node goes down due to a fault, the one-master-multiple-slave (one-master-one-slave) architecture can be maintained to maintain high availability. Then, the method of the present invention configures read-write separation and load balancing to the application service layer, thereby replacing the use of middleware similar to pgpool-II and improving the load performance of the database. Finally, the load balancing strategy of the present invention can be configured at the application end according to the application situation of the upper system, so its strategy selection can be more targeted and flexible.

[0075] The method of the present invention solves the hidden danger of database unavailability caused by single-node downtime, and configures read-write separation and load balancing to the application end without affecting performance, and is suitable for configuring a high-availability PostgreSQL cluster under an information system cloud.

[0076] like Figure 2The figure shows a schematic diagram of the functional modules of the system of the present invention: the system disclosed in the present invention for realizing the high availability method for PostgreSQL database comprises an environment building module, an environment configuration module, a mutual trust configuration module, a tool configuration module, an automatic migration module, a source configuration module and a load configuration module; the environment building module, the environment configuration module, the mutual trust configuration module, the tool configuration module, the automatic migration module, the source configuration module and the load configuration module are connected in series in sequence; the environment building module is used to build the basic database environment of PostgreSQL database and upload the data information to the environment configuration module; the environment configuration module is used to configure the master-slave environment of the master node and the slave node according to the received data information, and upload the data information to the mutual trust configuration module; the mutual trust configuration module is used to configure the master-slave environment of the master node and the slave node according to the received data information Set up SSH mutual trust for all nodes and upload data information to the tool configuration module; the tool configuration module is used to install the repmgr open source tool suite on each node according to the received data information, perform corresponding configuration, and upload the data information to the automatic migration module; the automatic migration module is used to configure the floating virtual IP based on the repmgr open source tool suite according to the received data information, and realize automatic migration of the main database failure, and upload the data information to the source configuration module; the source configuration module is used to configure multiple data sources on the application side according to the received data information to realize read-write separation, and upload the data information to the load configuration module; the load configuration module is used to configure the load balancing strategy according to the received data information, and complete the final high availability solution for the PostgreSQL database.

Claims

1. A high availability method for a PostgreSQL database, comprising the following steps: S1. Build the basic database environment of PostgreSQL database; S2. Configure the master-slave environment of the master node and the slave node; S3. Configure SSH mutual trust for all nodes; S4. Install the repmgr open source tool suite on each node and perform corresponding configurations; S5. Based on the repmgr open source tool suite in step S4, configure the floating virtual IP and implement automatic migration of the main library failure; S6. Configure multiple data sources on the application side to achieve read-write separation; S7. Configure the load balancing strategy to complete the final high availability method for the PostgreSQL database.

2. The high availability method for a PostgreSQL database according to claim 1, characterized in that The basic database environment for building a PostgreSQL database described in step S1 specifically includes the following steps: The basic database environment of the PostgreSQL database is built, including a master node, several slave nodes, an authentication node and a floating virtual IP address; The software environment includes: the database operating system is CentOS Linux release 7.5.1804 (Core); the database operating system character set is en_US.UTF-8; the PostgreSQL database version is Postgres12.11; the PostgreSQL database character set is UTF-8; Install the same version of PostgreSQL database and corresponding dependent software packages on the master node, slave node, and authentication node, create the database home directory and postgres user, set the database environment variables, initialize the database of each node and start verification.

3. The high availability method for PostgreSQL database according to claim 2, characterized in that The master-slave environment of configuring the master node and the slave node in step S2 specifically includes the following steps: Configure the master node: create a replication user repmgr and a database repmgr; the owner of the repmgr database is the user repmgr; configure the PostgreSQL database authentication file pg_hba.conf on the master node, configure the md5 authentication channel for the replication users of the master node, slave node, and authentication node; configure the main configuration file postgresql.conf and enable archiving; after the configuration is complete, restart the master node library and verify from other nodes to ensure that the postgres user can log in to the master node normally; Configure the slave node: Stop the PostgreSQL database and clear all contents of the database data file directory; use the pg_basebackup tool that comes with the PostgreSQL database software and the replication user repmgr to transfer the database of the master node to the slave node to establish a master-slave relationship and perform verification.

4. The high availability method for a PostgreSQL database according to claim 3, characterized in that Step S3 of configuring SSH mutual trust of all nodes specifically includes the following steps: Use the mutual trust test script to configure mutual trust for SSH login between the postgres users of the master node, slave node, and authentication node. After the configuration is complete, verify it.

5. The high availability method for PostgreSQL database according to claim 4, characterized in that Step S4 includes installing the repmgr open source tool suite on each node and performing corresponding configuration, which specifically includes the following steps: Install the repmgr open source tool suite on the master node and slave node; perform basic configuration and initialization of repmgr; the initialization includes configuring the host name, configuring the port number, and setting the user name and password; Configure the PostgreSQL database authentication file pg_hba.conf for the master node, slave node, and authentication node; for each node, configure the permissions for other nodes to access this node; the configuration content includes "TYPE", "DATABASE", "USER", "ADDRESS", and "METHOD"; during configuration, the first configuration is: "TYPE" is "host", "DATABASE" is "replication", "USER" is "repmgr", "ADDRESS" is the source address IP, and "METHOD" is "trust"; the second configuration is: "TYPE" is "host", "DATABASE" is "repmgr database", "USER" is "repmgr", "ADDRESS" is the source address IP, and "METHOD" is "trust"; the first configuration is applicable to data synchronization from the master node to the slave node in the replication process, and the second configuration is applicable to access control of the standby database and monitoring operations; after the configuration is completed, perform the pg_ctlrepload operation to make the configuration effective; Configure the master node repmgr: configure the master database repmgr, enable automatic failover, and configure the failover script repmgr_promote_command.sh after the master database crashes; configure "follow_command" to configure the program or script defined in the failover to be executed when repmgrd determines that the current node will follow the new master node; use the repmgr command to register the master node and verify it; Configure the slave node repmgr: Configure the slave database repmgr, enable automatic failover, and configure the failover script repmgr_promote_command.sh after the master database crashes; configure "follow_command" to configure the program or script defined in the configuration to be executed in the failover situation when repmgrd determines that the current node will follow the new master node; register the slave node using the repmgr command and verify it; between the master and slave databases, configure the repmgrd daemon process to the shared_preload_libraries in the Postgresql.conf library file. The shared_preload_libraries is used to specify the parameters of the shared library list loaded into memory during the database server startup process; Configure the attestation node repmgr: configure the attestation database repmgr, enable automatic failover, and configure the failover script repmgr_promote_command.sh after the main database crashes; configure "follow_command" to configure the program or script defined in the failover to be executed when repmgrd determines that the current node will follow the new primary node; use the repmgr command to register the attestation node and verify it; Restart the PostgreSQL database for both the master and slave nodes, and then restart the repmgrd daemon after success.

6. The high availability method for PostgreSQL database according to claim 5, characterized in that The repmgr open source tool kit described in step S5 is based on step S4 to configure the floating virtual IP and realize automatic migration of the main database failure, which specifically includes the following steps: Install and configure Keepalived, and use it as a tool to provide floating virtual IP: Install the keepalived installation package and related dependency packages on the master node and the slave node; Configure the configuration file keepalived.conf on the master node and the slave node respectively, and ensure that the parameter "priority" of the master node is higher than that of the slave node; Configure the three scripts checkpg.sh, master.sh, and slave.sh according to the actual situation of each node; Authorize and start keepalived as root to verify that the floating virtual IP is mounted successfully; Configure floating virtual IP in repmgr: Configure the failover script repmgr_promote_command.sh. The configuration idea is to monitor the repmgrd daemon after a failover event occurs → trigger the promote_command command → delete the floating virtual IP operation → test whether the floating virtual IP has been successfully uninstalled → promote the slave node to the master node → mount the floating virtual IP on the new master node → clear the ARP cache; restart repmgrd on the master node and the slave node respectively; Add the floating virtual IP to the network card in the master node, and then verify that you can log in to the master database from other nodes using the floating virtual IP address.

7. The high availability method for PostgreSQL database according to claim 6, characterized in that The configuration of multiple data sources on the application side in step S6 to achieve read-write separation specifically includes the following steps: In the nacos configuration files of several services in the application system, configure dual database source information to identify whether the service interface's operation on the database is a read request or a write request, and adapt to different database sources based on the identification results.

8. The high availability method for PostgreSQL database according to claim 7, characterized in that The configuration of the load balancing strategy described in step S7 specifically includes the following steps: Use the least number of connections method as the load balancing strategy.

9. A system for implementing the high availability method for a PostgreSQL database according to any one of claims 1 to 8, characterized in that It includes an environment building module, an environment configuration module, a mutual trust configuration module, a tool configuration module, an automatic migration module, a source configuration module and a load configuration module; the environment building module, the environment configuration module, the mutual trust configuration module, the tool configuration module, the automatic migration module, the source configuration module and the load configuration module are connected in series in sequence; the environment building module is used to build the basic database environment of the PostgreSQL database and upload the data information to the environment configuration module; the environment configuration module is used to configure the master-slave environment of the master node and the slave node according to the received data information, and upload the data information to the mutual trust configuration module; the mutual trust configuration module is used to configure the SSH mutual trust of all nodes according to the received data information, and upload the data information to the tool configuration module; The tool configuration module is used to install the repmgr open source tool suite on each node according to the received data information, perform corresponding configuration, and upload the data information to the automatic migration module; the automatic migration module is used to configure the floating virtual IP based on the repmgr open source tool suite according to the received data information, and realize automatic migration of the main database failure, and upload the data information to the source configuration module; the source configuration module is used to configure multiple data sources on the application side according to the received data information to realize read-write separation, and upload the data information to the load configuration module; The load configuration module is used to configure the load balancing strategy according to the received data information to complete the final high availability solution for the PostgreSQL database.

Images