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

Today, I will talk to you about the simplest way of Postgresql high availability and what is the kong gateway. Many people may not know much about it. In order to make you understand better, the editor summarized the following content for you. I hope you can get something from this article.

The cause of the matter is that a larger company wants to use the kong gateway, and my inaugural friend asked me what is the simplest high-availability way of postgresql, so the default of PostgreSQL replication in this article is asynchronous. If primary server crash has some transactions that have been commited in primary server but have not been transferred to standby server, then the master and slave will be inconsistent, and the data will be lost, so this is the mode of asynchronous replication.

However, Postgresql provides a synchronous mode to ensure that the data of the primary and standby libraries are consistent, so that all transaction changes must be transferred to the standby server wal_log after confirming the commit. This makes it possible that the only possibility of data loss is that the master and slave libraries do not work at the same time.

Of course, the disadvantages of this operation are also obvious.

1 performance must be greatly reduced, because clearly write operations on a server can continue, now to confirm between the two servers, the natural performance will be lost.

2 if the slave library cannot write data for some reason, or if there is a problem with the network, then the external service of the database will have a problem.

So such a high-availability building is basically rare in reality. But why mention him today.

The use of any architecture is related to the environment in which it is used and the logic of the application, and such high availability is acceptable in some cases.

For example, kong, a popular micro-service gateway, uses a database. In this case, there are two options for postgresql or cassandra. If you choose what to choose, traditional people will probably choose postgresql rather than cassandra (cassandra is actually very interesting). The reason is that if you know how cassandra works, you will understand.

The question now is whether we should build a highly available postgresql without professional guidance, patroni, repmgr, think about it.

So what are the characteristics of this example?

1 postgresql carries a small amount of data

2 will not often write to the database, the basic data will be written at once.

3 read more and write less

4 the database is not highly available, especially the gateway, and it is also micro-service, (how many modules are on it), lost data, or the main database fails, do you want the whole system to follow all down?

How to accomplish the task efficiently and simply, let non-DB people get it done quickly, so this synchronous mode, and the high availability in this way, is the best choice. So this issue is the simplest high availability, (I didn't say the best, and I didn't say it can be used anywhere, just the above example, it couldn't be better)

Then how to build this highly available way, here is the disk path. Postgresql.conf

1 installation will not be said here, please see the previous text

2 configuration file, the key here is the configuration file

1 synchronous_commit

2 synchronous_standby_name

These two are required to set the required options.

Synchronous_commit

Here are some of his options

On

Transaction commits always wait until the data is actually flushed to the transaction log (also known as WAL or XLOG) to ensure that the transaction is indeed persistent. In synchronous stream replication mode, the replica needs to do the same.

Off

Confirmation can be submitted to the user before the transaction flush wal_log. Of course, the price paid is that the data that is not submitted without flush to wal_log will be lost when the server crash.

Local

This option only ensures that your transaction commited will not lose data on the primary node, and standby does not guarantee that data will not be lost.

Remote_write

Compared with the on option, this is not without losing data, and standby just waits for confirmation of the disk to which the operating system returns the data to write.

Remote_apply

This is the option we need and provides a strong consistent option for replication. The master library will not commit before the returned data has been safely written to the standby without committing from the library. The significance of this option is that the master and slave data are always at any time, or go to dead together.

List a consistent protection of data from weak to strong

Off (async) > on (async) > remote_write (sync) > on | local (sync) > remote_apply (sync)

And

The difference between synchronous_standby_name and the above is that he is choosing which slave library you want to be consistent with you, because there may be a lot of slave libraries synchronizing data with you.

The most simple and rude thing is to use * to represent it. Of course, you can also write it as' ANY 2 (server 1, server 2, server 3)'in the way of mongodb. This is most of the concepts in MONGODB. POSTGRESQL here is also at least 2 standby consistent with me before I stop, otherwise I can't.

Or you can write the fixed pattern 'FIRST 2 (server 1, server 2, server 3)' at least the first two servers must be consistent with your primary data (see the setting of the above parameter)

To get primary commit or no.

Let's do an example.

Two machines, using pg_basebackup to do the most basic copy, for more information on how to copy, please see the previous text.

Let's do an experiment.

1 We start the transaction on the primary server

2 We will shut down the slave library before commit

Let's see what happens.

Main library

Slave library

It can be clearly seen that when the library is not online, there is no way to commit the main library.

We can take a look at the following. Obviously, after opening the slave library, the master library automatically commit the transaction.

You can also take a look at the logs of primary and standby

Primary

Standby

Once again, with keepalive to verify the postgresql service, and it contains the promote command, you can complete the simplest high-availability postgresql.

In fact, if the replication of MYSQL can achieve strong consistency, there may not be anything wrong with MHA. MYSQL + KEEPALIVE may also be a reliable choice.

Once again, I would like to reiterate that I am afraid that my classmates will misunderstand and think that I recommend such a high availability. Please review the title, the simplest, and also the sentence, depending on the demand. If you are doing it, not only do people want a simple demand for KONG, but also their companies do not have POSTGRESQL DBA and ask for their REPMGR PATRONI,PG database DBA It's too expensive and hard to find.

After reading the above, do you have any further understanding of what is the simplest way of Postgresql high availability and kong gateway? 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.