[Switch] stream from the PostgreSQL master copy deployment

Source: https: //www.jianshu.com/p/2d07339774c0

192.168.20.93 on the primary server deployment, deployed from the server 192.168.20.94.

1 Introduction

After 9.0 postgres introduced from the main flow of the replication mechanism, a so-called stream reproduction, the corresponding data is synchronized from the master server from the server via tcp stream. So that when the primary server data from the server when the backup is still missing.

Compared with file-based log shipping, replication flow is allowed to remain updated from the server. Connection from the master server, which records the generated stream to WAL from the server, without waiting for the primary file server WAL finished.

PostgreSQL streaming replication is asynchronous by default. Filed on the primary server transaction and there is a small delay between changes seen from the server, this delay is much less than a log-based file transfer, typically 1 second to complete. If the primary server crashes suddenly, there may be a small amount of data loss.

Synchronous replication master server and must wait before committing a transaction from the server written WAL. So to some extent, will increase the response time of the transaction.

Replication configuration requires only one additional configuration steps: synchronous_standby_names must be set to a non-null value. synchronous_commit must also be set on.

Here is the deployment of asynchronous replication stream.

Note:
the master node is preferably the same from the host server system, environment, and so on. PostgreSQL version is the best, or it may be a problem.

2. Install deployment

First in 192.168.20.93 and 192.168.20.94 are installed PostgreSQL.

See specific installation deployment steps: the PostgreSQL installation configuration

2.1 master server

A primary server 192.168.20.93

Create a new directory:

mkdir /opt/pgsql/pg_archive

1. First you need to create a database user master-slave synchronization. Create a user replica, and give login and copy rights.

postgres# CREATE ROLE replica login replication encrypted password 'replica'

2. Modify pg_hba.conf, allows the user to synchronize the replica.

Add two lines in pg_hba.conf:

host     all             all          192.168.20.94/32          trust   #允许94连接到主服务器
host   replication      replica       192.168.20.94/32          md5   #允许94使用replica用户来复制

Thus, the user can set the replica copy request from the streaming 192.168.20.93.

Note:
The second field must be filled replication

4. Modify postgresql.conf

listen_addresses = '*'   # 监听所有IP
archive_mode = on  # 允许归档
archive_command = 'cp %p /opt/pgsql/pg_archive/%f'  # 用该命令来归档logfile segment wal_level = hot_standby max_wal_senders = 32 # 这个设置了可以最多有几个流复制连接,差不多有几个从,就设置几个wal_keep_segments = 256 # 设置流复制保留的最多的xlog数目 wal_sender_timeout = 60s # 设置流复制主机发送数据的超时时间 max_connections = 100 # 这个设置要注意下,从库的max_connections必须要大于主库的 

After two configuration file to restart the server.

pg_ctl stop -D /opt/pgsql/data
pg_ctl start -D /opt/pgsql/data

3. Test 93 database 94 can connect. 94 run the following command:

psql -h 192.168.20.93 -U postgres 

See if you can access to the database. If so, then normal.

2.2 from the server

1. copy data from the master node to the slave node

su - postgres
rm -rf /opt/pgsql/data/*   #先将data目录下的数据都清空(建议先备份一下)
pg_basebackup -h 192.168.20.93 -U replica -D /opt/pgsql/data -X stream -P  # 从93拷贝数据到94(基础备份)
mkdir /opt/pgsql/pg_archive

2. Configure recovery.conf

Copy /usr/pgsql-9.4/share/recovery.conf.sample to /opt/pgsql/data/recovery.conf

cp /usr/pgsql-9.4/share/recovery.conf.sample /opt/pgsql/data/recovery.conf

Modify recovery.conf

standby_mode = on    # 说明该节点是从服务器
primary_conninfo = 'host=192.168.20.93 port=5432 user=replica password=replica'  # 主服务器的信息以及连接的用户
recovery_target_timeline = 'latest'

3. Configure postgresql.conf

wal_level = hot_standby
max_connections = 1000 # 一般查多于写的应用从库的最大连接数要比较大
hot_standby = on # 说明这台机器不仅仅是用于数据归档,也用于数据查询
max_standby_streaming_delay = 30s # 数据流备份的最大延迟时间
wal_receiver_status_interval = 10s # 多久向主报告一次从的状态,当然从每次数据复制都会向主报告状态,这里只是设置最长的间隔时间
hot_standby_feedback = on # 如果有错误的数据复制,是否向主进行反馈

After configuration, reboot from the server

pg_ctl stop -D /opt/pgsql/data
pg_ctl start -D /opt/pgsql/data

3. Verify successful deployment

Performed on the primary node:

select client_addr,sync_state from pg_stat_replication;

The results are as follows:

postgres=# select client_addr,sync_state from pg_stat_replication;
  client_addr  | sync_state
---------------+------------
 192.168.20.94 | async (1 行记录) 

Description 94 from the server, upon receiving the stream, and the stream is asynchronous replication.

You can also separately in the main, run from the node ps aux | grep postgres to see the process:

The main server (93) on:

postgres 262270  0.0  0.0 337844  2832 ?        Ss   10:14   0:00 postgres: wal sender process replica 192.168.20.94(13059) streaming 0/A002A88

We can see there is a wal sender process.

From the server (94):

postgres 569868  0.0  0.0 384604  2960 ?        Ss   10:14   0:02 postgres: wal receiver process   streaming 0/A002B60

Wal receiver can see there is a process.

So far, PostgreSQL installation is deployed from the main stream replication.

Inserting data on the primary server, or delete data on the server can be seen from the corresponding changes. Only query from the server, can not be inserted or deleted.

Guess you like

Origin www.cnblogs.com/wincai/p/10944809.html