PG主备架构（二）同步复制

PG主备架构（二）同步复制

昨天我们说了异步复制，今天我们讲讲同步复制，同步复制的概念我们在上章说过，当WAL日志传到了standby的时候，standby只有在确认收到WAL日志并且应用了之后才会反馈给primary，在此之前，primary一直是hang在那里的。为了防止standby停止后业务跟着停止，通过增加一个节点保证业务不停。废话不多说直接上步骤！！！

这里一定要注意，我这边实验的环境是UXDB，我们公司自己的产品，大家如果环境是PG，请直接将内部的视图和命令由ux_换成pg_

服务器信息：

同步复制：

我们在之前做了异步复制，同步复制的搭建也和异步复制的前面是相同的，只是受一个参数控制：

primary：

配置 etc/hosts文件

将这个文件传到其他的节点

scp /etc/hosts master:/etc/hosts

scp /etc/hosts slave:/etc/host

配置ux_hba.conf文件（这个文件的细节我在上篇文章已经说过，这里不多赘述，在PG里面叫pg_hba.conf）

这里一定要将两个节点的信息都放进来，这样才能保证连接到primary

之后配置primary的参数文件uxsinodb.conf配置文件

listen_address='*'

max_wal_senders=5

wal_level=replicat      (UXDB这里是replicat，在PG里面是hot_standby)

synchronous_standby_names='baby1,baby2'   (这个名字想起什么起什么，没有规则要求，但是一定要和standby的recovery.conf文件里面的application_name一样，这里的顺序决定了数据库的优先级)

slave1：

和异步复制一样standby数据库的构建需要文件通过ux_basebackup进行复制创建（在PG里面叫做pg_basebackup）

ux_basebackup -D /home/uxdb/uxclu -Fp -Xs -P -R -h master -p 5432

ux_basebackup我在上篇异步搭建的时候也说过，我也不再重复。

之后我们依旧是对recovery.conf文件进行修改

我们在这里多添加一个application_name参数，这个名字可以随便起，但是一定要和primary的参数文件中的synchronous_standby_names对应。

此时我们启动slave1，在primary查看ux_stat_replication，我们可以看到slave1的信息，这里显示已经同步。

我们在primary insert 一条数据，看看能不能传过来

\

我们看到可以从primary传到standby(slave1)这里，我们试试如果此时在两个节点的情况下，standby 宕机了，primary就会出现hang住的现象。

primary插入数据

此时我们看到，这条事务会一直hang在这里，这样的话就会导致业务受影响，所以这里我们添加另外一个节点防止有这种故障。

slave2：

现在我们再添加一个节点，同样数据库创建使用ux_basebackup（在PG当中，叫做pg_basebackup）

ux_basebackup -D /home/uxdb/uxclu -Fp -Xs -P -R -h master -p 5432

依旧改recovery.conf文件，将application_name修改成和primary参数文件的synchronous_standby_names对应。

这个时候就搭建成了。

此时我们进行测试，在master插入一条数据。

查看standby

查看primary端的ux_stat_replication（PG里叫pg_stat_replication)

我们发现这里记录的slave2的同步状态是postental，这个优先级的决定是在于primary的参数文件当中的synchronous_standby_names='baby1,baby2' 的先后决定的。如果此时突然断掉一个节点，我们发现这个primary是不会hang在那里的。

没有受到影响！！！

总结：整体来说，这个架构的搭建是很简单的，也没啥潜在的问题，所以希望我的这些文章能够帮到大家！！！

THAT'S ALL

BY CUI PEACE