你好赵伟

这个屌丝很懒，什么也没留下！

热门标签

Centos7部署PostgreSQL 12集群（主备）_如何搭建postgresql集群

作者：你好赵伟 | 2024-04-19 04:12:53

踩

如何搭建postgresql集群

Centos7部署PostgreSQL 12集群（主备）

关于备份模式

常规的备份模式有三种：热备、冷备和双活。

热备：仅主节点承担用户的业务、提供数据库服务，在不关闭数据库服务（不停服）的情况下对主节点进行备份。

为了保证数据库服务的正常不间断运行，一般用两台机器作为数据库服务机器。其中一台用于实际数据库操作应用、提供数据库服务，而另外一台则实时从前者中获取数据以保持数据的一致性。
如果当前的主节点故障宕机，当前的备节点机器立马（人为手动触发或由配置自动触发）取代当前的主节点机器继续提供数据库服务。

数据库热备是采用archive log mode的方式进行数据实时备份。

热备的缺点：操作复杂，比较容易出错，难于维护，维护成本比较高，所以要特别仔细小心，绝对不允许“以失败而告终”；不能出错，否则后果严重；要大量的档案空间；若热备份不成功，所得结果不可用于时间点的恢复。

热备的优点：采用archivelog mode方式备份数据的方法，可以再数据库运行的情况下进行，不用停止服务；实时备份、数据恢复时丢失的数据少，事务级别。故障恢复比较快速。

冷备：也是只有主节点承担用户的业务、提供数据库服务，在主节点关闭数据库服务（停服）的情况下对主节点进行关键性的物理文件进行拷贝备份。冷备适用于所有模式的数据库。冷备不要求主节点开启archive log mode，数据库性能相对要比热备模式高。

冷备的优点：操作简单、只需要进行简单的文件拷贝来完成备份，维护成本比较低；安全性高；容易恢复到某个时间点上（只需将文件再拷贝回去）。

冷备的缺点：只能提供到“某一时间点上”的恢复。备份过程中，数据库必须停服备份，当数据库处于打开状态时，执行数据库文件系统备份是无效的。故障恢复时间比较长。

双活：数据库备份的双活模式，一般用于数据中心的容灾备份的场景。一般会建两个（或多个）数据中心，一个是主数据中心用于承担用户的业务，一个是备份数据中心用于备份主数据中心的数据、配置、业务等。备节点不仅仅只是作为数据备份的用途、也同时承担用户的业务，即让主、备两个节点都同时承担用户的业务、提供数据库服务。这里不做详细介绍。

PostgreSQL集群部署模式

我使用1主+N备（N=1）PostgreSQL集群部署模式，只允许1个主（master/primary）节点进行读写操作，备节点不支持写操作、仅支持读操作。
只允许1个主节点支持写、备节点仅支持读操作，这是比较推荐的一个常规方案，因为该方案降低了复杂度、比较安全，避免了多主同时写而发生冲突的处理，易于维护。
考虑到业务系统的写的性能问题，我采用异步模式（async），放弃同步（sync）模式。缺点是有可能在进行主备切换时存在事务级别的数据丢失。相关的官方说明：
In contrast, asynchronous solutions allow some delay between the time of a commit and
its propagation to the other servers, opening the possibility that some transactions might be lost
in the switch to a backup server, and that load balanced servers might return slightly stale results.
Asynchronous communication is used when synchronous would be too slow.

> 环境规划
Server01：PostgreSQL(primary/master)
Server02：PostgreSQL(standby/slave)

node hostname ip
Server01 pgmaster 192.168.100.93
Server02 pgslave 192.168.100.94

Centos7.8, 4Core8G100g，PostgreSQL 12

> hostname设置
为了防止以后IP变化修改起来方便，数据库配置过程中全程使用hostname
主节点：
hostnamectl set-hostname pgmaster
hostnamectl status

echo '
192.168.100.93 pgmaster
192.168.100.94 pgslave
' >> /etc/hosts

备节点：
hostnamectl set-hostname pgslave
hostnamectl status

echo '
192.168.100.93 pgmaster
192.168.100.94 pgslave
' >> /etc/hosts

测试：
ping pgmaster
ping pgslave

> 检查时区和时间（所有节点）
timedatectl
timedatectl list-timezones
timedatectl set-timezone Asia/Shanghai
date -s "20211021 13:17:00"
hwclock -w
hwclock

有条件的话，建议设置所有节点NTP时钟同步，方法可以参考：《Centos7 NTP时钟同步配置》：

Centos7 NTP时钟同步配置_sunny05296的博客-CSDN博客_centos7时间同步配置

我这里跳过NTP配置。

关闭防火墙（所有节点）
# 关闭防火墙
systemctl stop firewalld
systemctl disable firewalld

关闭SELINUX（所有节点）
sed -i "s/SELINUX=enforcing/SELINUX=disabled/g" /etc/selinux/config
cat /etc/selinux/config | grep SELINUX=disabled

立即生效
setenforce 0

> 安装系统依赖包（所有节点）
yum install -y libicu systemd-sysv vim wget readline readline-devel zlib zlib-devel openssl openssl-devel pam-devel libxml2-devel libxslt-devel python-devel tcl-devel gcc gcc-c++ rsync
yum list libicu systemd-sysv vim wget readline readline-devel zlib zlib-devel openssl openssl-devel pam-devel libxml2-devel libxslt-devel python-devel tcl-devel gcc gcc-c++ rsync

如果不能访问外网yum源，则需要配置本地yum源，本文不做介绍，可以参考：《redhat7配置yum repos软件仓库&远程yum》：

https://blog.csdn.net/sunny05296/article/details/107321824

> 内核优化（所有节点）
vi /etc/sysctl.conf

#for PostgreSQL
net.core.wmem_default=262144
fs.file-max=76724600
vm.mmap_min_addr=65536
net.core.somaxconn=4096
net.core.wmem_max=4194304
net.core.netdev_max_backlog=10000
# 信号量，ipcs -l 或或 -u 查看，每 16 个进程一组，每组信号量需要 17 个信号量。
# 不重新修改该值。四个参数： SEMMSL SEMMNS SEMOPM SEMMNI。SEMMSL * SEMMNI = SEMMNS (参数1 * 参数4 = 参数2)，SEMMSL = SEMOPM (参数1 = 参数3)。
# 参数1(SEMMSL): max semaphores per array, 信号量，表示每个信号集中的最大信号量数目，信号量是多线程环境下使用的一种设施,它负责协调各个线程, 以保证它们能够正确、合理的使用公共资源。信号量设置时，最小250，对于processes参数设置较大的系统建议设置为processes+10。
# 参数2(SEMMNS): max semaphores system wide, 所有信号的最大数量、即系统范围内的最大信号量总数目，SEMMSL * SEMMNI。
# 参数3(SEMOPM): max ops per semop call, 代表调用单个信号集中最大信号数量，即每个信号发生时的最大系统操作数目，大于17，一般设置至少100，或者等于SEMMSL。
# 参数4(SEMMNI): max number of arrays, 代表是组（信号集的最大值），即系统范围内的最大信号集总数目。最少128。
# kernel.sem = 4096 2147483647 2147483646 512000 官方是给的这个设置。如果不设置，系统默认值（ipcs -sl 命令可查看）为：250 3200 32 128。我没有使用官方的设置，也没有使用默认值，我调整了一下
kernel.sem = 4096 83886080 4096 20480
net.core.rmem_max=4194304
vm.overcommit_ratio=90
net.ipv4.tcp_tw_reuse=1
net.core.rmem_default=262144
net.ipv4.ip_local_port_range=40000 65535
#net.netfilter.nf_conntrack_max=1200000
net.ipv4.tcp_rmem=8192 87380 16777216
net.ipv4.tcp_max_syn_backlog=4096
fs.nr_open=20480000
net.ipv4.tcp_wmem=8192 87380 16777216
vm.dirty_writeback_centisecs=100
vm.dirty_ratio=95
# 所有共享内存段相加大小限制( 建议内存的 80% ，单位 page ，查看 page 大小 getconf PAGE_SIZE)
# 设置时根据自己的实际内存大小进行计算和设置，例如：page 大小 4096，8G 内存的 80% 设置为：8*1024*1024*1024/4096*80%=1677721
kernel.shmall = 1677721 #Mem*80%
# 最大单个共享内存段大小(建议为大于shared_buffer值，单位bytes。需要计算。一般建议设置为内存的50%。例如：8G内存，则参数设置为：8*1024*1024*1024*50%=4294967296。如果因为该参数导致启动失败时，可以尝试调整为75%
# kernel.shmmax = 4294967296 # 50%
kernel.shmmax = 6442450944 #Mem*75%
# 系统范围内共享内存段的最大数量（一共能生成多少共享内存段），每个PG数据库集群至少2个共享内存段，不重新修改该值
# kernel.shmmni = 819200 官方设置819200，我设置该值会报错 Invalid argument，我调整为默认值4096
kernel.shmmni = 4096 #default 4096
vm.swappiness=0
net.ipv4.tcp_mem=8388608 12582912 16777216
vm.dirty_background_bytes=409600000
#net.nf_conntrack_max=1200000
net.ipv4.tcp_max_tw_buckets=262144
fs.aio-max-nr = 1048576

生效内核参数优化配置：
sysctl -p

注意：net.nf_conntrack_max & net.netfilter.nf_conntrack_max 这两个参数的优化如果开启的话，我会遇到报错：
sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_max: No such file or directory
sysctl: cannot stat /proc/sys/net/nf_conntrack_max: No such file or directory
可能是 conntrack没有加载，lsmod |grep conntrack ，如果返回为空，表示没有加载
执行命令加载： modprobe ip_conntrack
重新执行 sysctl -p 即可。也可以忽略该错误、或者注释掉 net.nf_conntrack_max & net.netfilter.nf_conntrack_max 这两个参数的优化。

关于ip_conntrack：
ip_conntract就是linux NAT的一个跟踪连接条目的模块，用来跟踪和记录连接状态，是netfilter的一部份。ip_conntrack模块会使用一个哈希表记录 tcp 通讯协议的 established connection 记录。当这个哈希表满了的时候，便会导致 nf_conntrack: table full, dropping packet 错误。

我直接注释掉了 net.nf_conntrack_max & net.netfilter.nf_conntrack_max 的优化。

> OS limits配置（根据自己实际环境进行合理配置）
echo '
#for PostgreSQL
postgres soft core unlimited
postgres hard nproc unlimited
postgres soft nproc unlimited
postgres hard memlock unlimited
postgres hard nofile 1024000
postgres soft memlock unlimited
postgres soft nofile 1024000
' >> /etc/security/limits.conf

PosgreSQL数据库安装

> PostgreSQL安装

主节点、备节点上分别安装PostgreSQL数据库软件。备节点也参考主节点的方式完成数据库的安装。主、备节点的 PostgreSQL 数据库安装完毕以后，可以独立启动和独立使用，在没有进行主、备集群的相关配置修改之前，还是两个独立的数据库。

PostgreSQL数据库安装参考：《Centos7安装PostgreSQL 12.4 + postgis安装》：
Centos7安装PostgreSQL 12.4 + postgis安装_sunny05296的博客-CSDN博客

完成数据库安装后，PostgreSQL 安装后会默认创建一个 postgres 用户，默认创建的用户/home目录下没有用户目录，默认的用户根目录为 /var/lib/pgsql

> 启动数据库（root用户启动）
# systemctl start postgresql-12
# systemctl enable postgresql-12
# systemctl status postgresql-12

Postgresql默认的安装目录是/usr/pgsql-12，而默认的数据目录（PGDATA）是/var/lib/pgsql/12/data/，如果默认数据目录空间不够的话可以修改指定数据目录。
注意：如果初始化数据库的时候使用了自定义数据目录，那么在注册服务（service）前需要修改服务脚本中的默认的PGDATA路径
vim /usr/lib/systemd/system/postgresql-12.service
Environment=PGDATA=/var/lib/pgsql/12/data/
将默认路径改为你自定义数据目录，然后再注册数据库服务并启动：
systemctl daemon-reload //重新加载服务的unit配置文件（服务配置文件修改生效配置）
systemctl enable postgresql-12 //服务自动启动开启
systemctl start postgresql-12 //启动服务
systemctl stop postgresql-12 //停止服务
systemctl disable postgresql-12 //服务自动启动关闭

> 配置环境变量
环境变量的配置，不是必须的，也可以不配置。如果不配置环境变量，不影响使用，但是如果要执行 /usr/pgsql-12/bin 目录下的相关命令时，需要加绝对路径的方式才能执行，为了方便使用 pg 的相关工具命令，最好还是配置一下环境变量。

postgres用户环境变量配置：
# su - postgres
$ cd ~

echo '
export PG_HOME=/usr/pgsql-12
#export PGDATA=$PG_HOME/data
export PGDATA=/var/lib/pgsql/12/data
export PATH=$PG_HOME/bin:$PATH
export LD_LIBRARY_PATH=$PG_HOME/lib
export MANPATH=$PG_HOME/share/man:$MANPATH
' >> .bash_profile

立即生效环境变量 & 检查是否生效
$ source .bash_profile
$ echo $PG_HOME && echo $PGDATA

> 修改数据库配置（主、备）
# vim /var/lib/pgsql/12/data/postgresql.conf

listen_addresses = '*' #数据库服务监听IP地址，默认只监听localhost，外部无法访问。修改为 *，允许外部访问数据库服务
port = 5432 #数据库服务监听端口
max_connections = 5000 #默认100，连接数限制根据实际业务需求修改

# vim /var/lib/pgsql/12/data/pg_hba.conf
末尾添加下面类容，不限制任何主机并允许远程登录：
host all all 0.0.0.0/0 md5

修改后重启数据库
# systemctl restart postgresql-12

查看日志
# tail -100f /var/log/messages

查看服务监听状态
# netstat -an |grep 5432

查看相关进程
# ps aux |grep postgres

执行 pg_config 查看配置信息（BINDIR，LIBDIR 等路径配置）
# pg_config
注意：如果没有配置环境变量的话，执行命令时需要完整路径执行（/usr/pgsql-12/bin/pg_config）

设置postgres用户密码
安装数据库时默认添加的 postgres 用户没有设置密码，本地连接登录数据库后进行密码设置：
# su - postgres
$ su - postgres
$ psql -U postgres
postgres=# ALTER USER postgres with encrypted password '1q2w3e';
postgres=# \du
postgres=# \l
postgres=# \dn

数据库安装完毕以后，接下来进行集群模式的配置。

PostgreSQL集群（主备模式）配置

> 主、备节点上设置节点ssh免密互信关系
主要为了使pgpool-II所在主机能登录PostgreSQL所在主机、创建trigger文件，需要进行主机之间的免密互信配置。给root & postgres用户设置互信

1，设置postgres系统用户的密码（主、备）
由于yum方式安装、自动生成的postgres用户没有设置密码，需要用root用户设置postgres系统用户的密码，否则免密无法成功
# passwd postgres

2，对root用户设置节点互信关系（主、备）
# cd ~
# ssh-keygen
# ssh-copy-id -i ~/.ssh/id_rsa.pub root@pgmaster
# ssh-copy-id -i ~/.ssh/id_rsa.pub root@pgslave

3，对postgres用户设置节点互信关系（主、备）
# su - postgres
$ cd ~
$ ssh-keygen # 这里一路默认回车就行了，在本地机器上使用ssh-keygen产生公钥私钥对
$ ssh-copy-id -i ~/.ssh/id_rsa.pub postgres@pgmaster #将本机的公钥复制到远程机器的authorized_keys文件中(~/.ssh/authorized_key)，会提示输入用户密码
$ ssh-copy-id -i ~/.ssh/id_rsa.pub postgres@pgslave

4，测试节点互信：
主、备节点设置完毕以后，测试免密是否OK。首次可能会提示输入yes，直接输入yes即可完成登录，不需要密码，后续就不会提示了。
主、备节点上都执行测试语句：
# ssh pgmaster date
# ssh pgslave date
# su - postgres
$ ssh pgmaster date
$ ssh pgslave date

> PostgreSQL流复制（stream replication）配置

流复制配置的总体流程：
1.配置主节点&重启 -> 2.备节点从主节点拷贝数据目录 -> 3.配置备节点&重启 -> 4.配置recovery.conf & .pgpass文件 -> 5.重启数据库（主、备） -> 6.测试主备同步 -> 7.测试主备切换

1.配置主节点&重启

1.1）主节点上为流复制创建独立的数据库用户
建议为流复制创建专门的流复制用户 replica，流复制用户需要有 REPLICATION 权限和 LOGIN 权限：
# su - postgres
$ psql -U postgres
postgres=# CREATE USER replica WITH REPLICATION LOGIN CONNECTION LIMIT 10 ENCRYPTED PASSWORD 'replica@1q2w3e';
postgres=# \du
postgres=# \q

1.2）主节点上创建归档目录：
在主节点的数据目录（$PGDATA）的路径下创建归档目录 pg_archive & 归档控制标识文件 archive_active：
# su - postgres
$ cd $PGDATA
$ mkdir pg_archive
$ touch pg_archive/archive_active

注意：如果没有配置环境变量，有多种方法可以确定数据目录：
方法1）如果配置了环境变量的话，可以通过环境变量查看
# echo $PGDATA
# su - postgres
$ echo $PGDATA
方法2）也可以通过 systemctl status postgresql-12 查看
# systemctl status postgresql-12 |grep "\-D"
├─ 944 /usr/pgsql-12/bin/postmaster -D /var/lib/pgsql/12/data/

方法3）还可以通过数据库命令 SHOW data_directory 查看
# su - postgres
$ psql -U postgres
postgres=# SHOW data_directory;
data_directory
------------------------
/var/lib/pgsql/12/data

1.3）主节点修改 pg_hba.conf 设置流复制用户 replica 的访问权限

修改前，介绍一下PostgreSQL数据库中的登录身份验证模式
pg_hba.conf中配置登录身份验证模式，有 ident、trust、md5、peer、password、cert 等多种模式：
ident: 系统会将请求发起者的操作系统用户映射为PostgreSQL数据库内部用户，并以该内部用户的权限登录，且无需提供密码。windows不支持。
trust: 用户无需提供密码就可以连接到数据库。只要源端IP地址、连接用户名、要访问的database名正确，用户就可以连接上。
md5: 该模式很常用，要求连接发起者携带用md5算法加密的密码。
peer: 该模式下系统会直接从操作系统内核获取当前发起者的操作系统用户名，如果与其请求连接的PostgreSQL用户名一致，即可连接成功。
password: 该模式要求连接发起者携带明文密码进行身份验证。
cert: 该模式要求客户端必须使用SSL方式进行连接。

注意：pg_hba.conf中的登录验证规则记录是有顺序的，每一次连接尝试都会顺序地检查pg_hba.conf记录，所以这些记录的顺序是非常关键的。
通常，靠前的记录有比较严的连接匹配参数和比较弱的认证方法，而靠后的记录有比较松的匹配参数和比较强的认证方法。

$ vi $PGDATA/pg_hba.conf

主节点修改后的 pg_hba.conf 配置如下（注释掉了靠前的默认的连接匹配宽松的记录，末尾添加我的配置记录）：
## "local" is for Unix domain socket connections only
#local all all peer
## IPv4 local connections:
#host all all 127.0.0.1/32 ident
## IPv6 local connections:
#host all all ::1/128 ident
## Allow replication connections from localhost, by a user with the
## replication privilege.
#local replication all peer
#host replication all 127.0.0.1/32 ident
#host replication all ::1/128 ident

# myconfigs
local all all trust
host all all 0.0.0.0/0 md5
host replication replica pgslave trust

关于 replica 用户的授权配置，请注意：
1）replica 用户的网络配置（IP/network/hostname），要配置对端的（即访问者）、不是配置自己。主节点配置备的、备节点配置主的
2）replica 用户的网络配置，虽然也支持网段 192.168.100.0/24 的配置方式，但是为了安全起见，最小原则，建议缩小到主机（32位掩码，例如：192.168.100.94/32）或hostname（例如：pgslave），如果有多个备节点，则添加多条；
3）replica 用户的认证方式，建议md5方式，不要用trust，虽然配置成trust功能上也没有问题，但安全最小原则，还是建议进行密码验证
4）replica 用户的认证方式，如果配置的是trust，则 /var/lib/pgsql/.pgpass 用不上，可以不用配置.pgpass。如果配置的是md5，则后面还需要配置.pgpass

1.4）主节点修改 postgresql.conf 开启归档
$ vi $PGDATA/postgresql.con #即 vi /var/lib/pgsql/12/data/postgresql.conf

# - Archive -
archive_mode = on # 归档日志，默认为off，需要开启
archive_command = 'test ! -f /var/lib/pgsql/12/data/pg_archive/archive_active || cp %p /var/lib/pgsql/12/data/pg_archive/%f'
# 归档命令默认为空。开启归档时需要配置，
# %p 表示WAL日志文件的路径，%f 表示WAL日志文件名称
# 增加归档标识文件archive_active检测，可以通过标识文件是否存在来控制是否执行后面的归档命令，如果不想归档时、可以删除标识文件archive_active，要归档时自己手动touch archive_active

# - Archive Recovery -
#restore_command = '' # 归档恢复命令。command to use to restore an archived logfile segment。获取wal文件（已归档的segments）的本地shell命令。
# 归档恢复必须指定该参数，但对于流复制是可选的。
#archive_cleanup_command = '' # 指定将在每个重新启动点执行的shell命令，提供了一种可用于清理备用服务器不再需要的旧存档WAL文件的机制。
# 任何 %r 都将替换为包含最后一个有效重新启动点的文件的名称，这是必须保留的最早文件，以保障能恢复可重新启动，因此删除早于 %r 的所有文件是安全的。
#recovery_end_command = '' # 指定仅在恢复结束时执行一次的shell命令。此参数是可选的。提供了一种复制或恢复后清理的机制。任何 %r 都将替换为文件名包含最后一个有效的重启点。

如果只是开启归档，修改上面几个参数就可以做到了。如果要继续优化，可以参考其他参数的修改：
vi /var/lib/pgsql/12/data/postgresql.conf

# - Connection Settings -
listen_addresses = '*'
port = 5432
max_connections = 5000
superuser_reserved_connections = 10 # 为超级用户保留的连接槽，实际并发用户为 max_connections 减去 superuser_reserved_connections

# WAL - Setting -
wal_level = replica # 不同的PG版本有区别。高版本支持：minimal, replica(默认), or logical。低版本支持：minimal(默认), archive, hot_standby or logical。如果低版设置为hot_standby。控制WAL归档日志记录的不同信息
wal_log_hints = on # 默认为off。also do full page writes of non-critical updates。该参数使能够记录特定提示位（hint-bit）的变化。该参数只能在服务器启动的时候被设置。有些工具要求设置才能正常运行，所以最好开启

# WAL - Archive -
archive_mode = on # 归档日志，默认为off，需要开启
archive_command = 'test ! -f /var/lib/pgsql/12/data/pg_archive/archive_active || cp %p /var/lib/pgsql/12/data/pg_archive/%f' # 归档命令默认为空。开启归档时需要配置，
# %p 表示WAL日志文件的路径，%f 表示WAL日志文件名称
# 增加归档标识文件archive_active检测，可以通过标识文件是否存在来控制是否执行后面的归档命令，如果不想归档时、可以删除标识文件archive_active，要归档时自己手动touch archive_active

# REPLICATION - Sending Setting -
max_wal_senders = 50 # max number of walsender processes。主库最多允许多少个并发的standby数据库。PG高版本默认值为10。根据实际环境设置
wal_keep_segments = 64 #默认是0(disable)。用于指定pg_wal目录中保存的过去的wal文件(wal segemnt，wal段)的最小数量，以防备用服务器在进行流复制时需要。防止主库生成WAL日志太快、流复制还没发送到standby就被覆盖，适当调大，但要考虑磁盘空间的占用，一个WAL日志文件的大小是16M

# REPLICATION - Standby Servers -
#primary_conninfo = '' # connection string to sending server. 备节点与主节点连接的连接字符串，主节点该参数无效。
# PG 12开始这里可以不用设置，发现 primary_conninfo 参数会自动注入到 postgresql.auto.conf 中（生效优先级更高、参数先从 postgresql.auto.conf 中加载，如果没有才从 postgresql.conf 中加载）
# postgresql.auto.conf 参数文件是一个动态参数文件，一般不会手动去修改它，而是通过数据库中 alter system set parameter_name = values 的方式来修改该文件中的参数
# show primary_conninfo; 数据库查询命令可以查看参数设置
hot_standby = on # on：热备。off：冷备。"off" disallows queries during recovery。默认为on

# RESOURCE USAGE - 内存优化 -
shared_buffers = 512MB #默认值是128MB

# REPORTING AND LOGGING - 日志设置 -
log_destination = 'csvlog,stderr' #默认'stderr'
logging_collector = on #默认on。Enable capturing of stderr and csvlog into log files. Required to be on for for csvlog.
log_directory = 'log' #默认'log'。directory where log files are written, can be absolute or relative to PGDATA.
log_filename = 'postgresql-%Y-%m-%d.log' #默认'postgresql-%a.log'。日志文件名格式，每天生成一个日志文件
log_rotation_age = 1d #默认1d。单个日志文件的生存期。在日志文件大小没有达到log_rotation_size时，一天只生成一个日志文件
log_rotation_size = 100MB #默认0(disable)。单个日志文件的大小，如果时间没有超过log_rotation_age：一个日志文件最大限制，超过限制将新生成一个日志文件

# REPORTING AND LOGGING - when to log -
# 记录执行慢的SQL耗时
log_min_duration_statement = 30000 #默认-1(disable)。-1 disable; 0:记录所有SQL语句和它们的耗时; > 0:只记录耗时大于等于这个值(ms)的SQL语句。根据实际业务场景设置，我设置30秒

# REPORTING AND LOGGING - what to log -
log_checkpoints = on #默认off。开启后，可从服务器日志中提取信息。
#每个完成的检查点将有详细的统计信息，包括WAL的数量，查询命令: select pg_current_wal_lsn();
#通过该2次查询结果，可以计算出时间段范围内生成产生多大的WAL: select pg_wal_lsn_diff('3E/2203E0F8', '3D/B4020A58')/1024/1024/1024;
log_connections = on #默认off。是否记录连接日志
log_disconnections = on #默认off。是否记录连接断开日志
log_duration = on #记录每条SQL语句执行完成消耗的时间，将此配置设置为on：用于统计哪些SQL语句耗时较长。
log_line_prefix = '%m %p %u %d %r ' #日志输出格式（%m,%p实际意义配置文件中有解释）。可根据自己需要设置（能够记录时间，process ID，用户，dbName，remote host and port等信息，方便定位问题）
log_timezone = 'Asia/Shanghai' #日志时区。最好和服务器设置同一个时区，方便问题定位

# 监控数据库中长时间的锁
log_lock_waits = on #默认off。log lock waits >= deadlock_timeout。控制当一个会话等待时间超过deadlock_timeout而被锁时是否产生一个日志信息。在判断一个锁等待是否会影响性能时是有用的，缺省是off。

# 记录DDL操作
log_statement = 'mod' #none, ddl, mod, all。默认none:不记录。ddl:记录所有数据定义命令，CREATE,ALTER,和DROP等。mod:记录所有ddl语句，加上数据修改语句INSERT,UPDATE等。all:记录所有数据库执行的SQL语句。

# LOCK MANAGEMENT - 锁管理 -
deadlock_timeout = 3s #默认1s。进行死锁检测之前在一个锁上等待的总时间。死锁检测成本较高，可根据实际情况适当增大该值

关于wal_level
控制WAL归档日志记录的不同信息，minimal记录信息最少，磁盘开销小；logical记录日志信息最多，磁盘开销大。
不同的PG版本有区别：
PG<12的低版本支持：minimal(默认), archive, hot_standby, logical。
PG>=12的高版本支持：minimal, replica(默认), logical。
Streaming Replication：流复制（wal_level = replica），流复制已经成为PostgreSQL的一部分，通常用于高可用场景下的读写分离。流复制是基于WAL日志的物理复制，适用于整个数据库实例的复制，并且备库是只读的。
Logical Replication：逻辑复制（wal_level = logical），适用于数据库实例的部分的复制（单个数据库或者某部分表），基于发布/订阅机制（上游创建发布者、下游创建订阅者），可以向下游节点写入数据，也可以将多个数据库实例的数据同步到一个目标数据库等等。

关于wal_keep_segments
Directly moving WAL records from one database server to another is typically described as log
shipping. PostgreSQL implements file-based log shipping by transferring WAL records one file (WAL
segment) at a time. WAL files (16MB) can be shipped easily and cheaply over any distance, whether
709
High Availability, Load
Balancing, and Replication
it be to an adjacent system, another system at the same site, or another system on the far side of the
globe. The bandwidth required for this technique varies according to the transaction rate of the primary
server. Record-based log shipping is more granular and streams WAL changes incrementally over a
network connection (see Section 26.2.5).

关于shared_buffers
shared_buffers 是缓存。在数据库系统中，我们主要关注磁盘IO，而且其大多是随机IO，因此从磁盘的读取比较慢，为了解决这个问题，postgresql将数据缓存在内存中，牺牲内存来换取随机读取的性能。
shared_buffers 参数用来设置数据库服务器将使用的共享内存缓冲区量。默认通常是 12MB，但是如果你的内核设置不支持（在initdb时决定），那么可以会更少，但不能小于 128kB。
不过为了更好的性能，通常会使用明显高于最小值的设置。如果指定值时没有单位(MB等)，则以块为单位，即BLCKSZ字节，通常为8kB。此参数只能在服务器启动时设置。
如果服务器内存被数据库专用、服务器内存 >= 1GB，合理的shared_buffers初始值是设置为系统内存的25%。shared_buffers并非越大越好，shared_buffers增大，也会造成一些工作负载。超过内存 40% 反而会不好。
shared_buffers更大的设置通常要求对max_wal_size也做相应增加。生产系统可以根据实际业务需求适当调整该参数。

注意：
1）从PostgreSQL V12开始，recovery.conf就融合到postgresql.conf中了，这里无需单独处理 recovery.conf 文件
2）primary_conninfo = '' 该参数默认注释掉了，postgresql.conf中无需配置。因为系统会自动生成 /var/lib/pgsql/12/data/postgresql.auto.conf 文件，内部会自动设置该参数。而且postgresql.auto.conf 的优先级高于postgresql.conf，所以即使postgresql.conf中设置了primary_conninfo也不会生效
例如：$ cat postgresql.auto.conf 自动生成的内容如下：
primary_conninfo = 'user=replica passfile=''/var/lib/pgsql/.pgpass'' host=192.168.100.93 port=5432 sslmode=prefer sslcompression=0 gssencmode=prefer krbsrvname=postgres target_session_attrs=any'

重启数据库(主)
主节点配置修改完毕，重启主节点数据库服务
# systemctl restart postgresql-12
# systemctl status postgresql-12

查看日志，检查是否有报错
[root@pgmaster data]# ls -l $PGDATA/log
total 12
-rw------- 1 postgres postgres 308 Oct 21 20:11 postgresql-2021-10-21_201133.csv
-rw------- 1 postgres postgres 188 Oct 21 20:11 postgresql-2021-10-21_201133.log
-rw------- 1 postgres postgres 2583 Oct 21 20:11 postgresql-Thu.log
[root@pgmaster data]#
[root@pgmaster data]# tail -100f $PGDATA/log/postgresql-2021-10-21_201133.log
2021-10-21 20:11:33.555 CST 3116 LOG: database system was shut down at 2021-10-21 20:11:25 CST
2021-10-21 20:11:33.561 CST 3113 LOG: database system is ready to accept connections

[root@pgmaster data]# tail -100f $PGDATA/log/postgresql-2021-10-21_201133.csv
2021-10-21 20:11:33.555 CST,,,3116,,617158f5.c2c,1,,2021-10-21 20:11:33 CST,,0,LOG,00000,"database system was shut down at 2021-10-21 20:11:25 CST",,,,,,,,,""
2021-10-21 20:11:33.561 CST,,,3113,,617158f5.c29,1,,2021-10-21 20:11:33 CST,,0,LOG,00000,"database system is ready to accept connections",,,,,,,,,""

2.备节点从主节点拷贝数据目录
备节点使用 pg_basebackup 命令生成备库的 data（直接从主节点拷贝$PGDATA目录过来）

2.1）先关闭备节点的数据库服务 & 删除备节点已有的 $PGDATA 目录下的所有内容
# systemctl stop postgresql-12
# su - postgres
$ cd $PGDATA
$ mkdir ../back_data_temp
$ mv * ../back_data_temp #清空备节点的 $PGDATA 目录

2.2） pg_basebackup 从主节点拷贝$PGDATA下的所有文件及目录到备节点$PGDATA目录下
$ pg_basebackup --help #查看命令帮助
$ pwd #确认路径正确: /var/lib/pgsql/12/data
$ pg_basebackup -h 192.168.100.93 -D /var/lib/pgsql/12/data -U replica -v -P -R #从主节点拷贝$PGDATA到备节点

pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/1B000028 on timeline 1
pg_basebackup: starting background WAL receiver
pg_basebackup: created temporary replication slot "pg_basebackup_3730"
353133/353133 kB (100%), 1/1 tablespace
pg_basebackup: write-ahead log end point: 0/1B000100
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: syncing data to disk ...
pg_basebackup: base backup completed

注意：网上很多介绍这里都是使用的 postgres 用户，准确来讲这里应该使用 replication 用户（我的是 replica），还要在 pg_hba.conf 中添加授权记录。否则执行会报错。
我开始用的 postgres 用户执行 pg_basebackup 报错：
pg_basebackup: error: FATAL: no pg_hba.conf entry for replication connection from host "192.168.100.94", user "postgres", SSL off

pg_basebackup 参数：
-h: master节点IP
-D: master节点的$PGDATA目录
-U: 连接的数据库用户(dbuser)
-v: 打印详情
-P: 打印处理信息
-R: --write-recovery-conf，生成configuration for replication
-Ft: 指定打包成.tar文件传输、传输本地后再解压处理，如果不指定则直接文件传输，网络质量不好的情况下，建议加-Ft参数，本地网络环境好的话，可以不加

2.3）pg_basebackup 拷贝后的文件确认

pg_basebackup 执行时，如果加了-Ft参数传输.tar文件的，本地会生成 base.tar pg_wal.tar 两个文件，需要解压到对应正确的目录：
tar -xvf base.tar -C ../data/
tar -xvf pg_wal.tar -C ./pg_wal/

pg_basebackup 执行时，如果没有加-Ft参数打包，直接拷贝所有文件，则不需要解压和特殊拷贝处理，默认同步了所有data目录下的文件和文件夹（包含pg_wal下的所有文件）：
-bash-4.2$ ls -l
total 68
-rw------- 1 postgres postgres 226 Oct 21 22:14 backup_label
drwx------ 5 postgres postgres 41 Oct 21 22:14 base
-rw------- 1 postgres postgres 88 Oct 21 22:14 current_logfiles
drwx------ 2 postgres postgres 4096 Oct 21 22:14 global
drwx------ 2 postgres postgres 4096 Oct 21 22:14 log
drwxr-xr-x 2 postgres postgres 4096 Oct 21 22:14 pg_archive
drwx------ 2 postgres postgres 6 Oct 21 22:14 pg_commit_ts
drwx------ 2 postgres postgres 6 Oct 21 22:14 pg_dynshmem
-rw------- 1 postgres postgres 4750 Oct 21 22:14 pg_hba.conf
-rw------- 1 postgres postgres 1636 Oct 21 22:14 pg_ident.conf
drwx------ 4 postgres postgres 68 Oct 21 22:14 pg_logical
drwx------ 4 postgres postgres 36 Oct 21 22:14 pg_multixact
drwx------ 2 postgres postgres 6 Oct 21 22:14 pg_notify
drwx------ 2 postgres postgres 6 Oct 21 22:14 pg_replslot
drwx------ 2 postgres postgres 6 Oct 21 22:14 pg_serial
drwx------ 2 postgres postgres 6 Oct 21 22:14 pg_snapshots
drwx------ 2 postgres postgres 6 Oct 21 22:14 pg_stat
drwx------ 2 postgres postgres 6 Oct 21 22:14 pg_stat_tmp
drwx------ 2 postgres postgres 6 Oct 21 22:14 pg_subtrans
drwx------ 2 postgres postgres 6 Oct 21 22:14 pg_tblspc
drwx------ 2 postgres postgres 6 Oct 21 22:14 pg_twophase
-rw------- 1 postgres postgres 3 Oct 21 22:14 PG_VERSION
drwx------ 3 postgres postgres 60 Oct 21 22:14 pg_wal
drwx------ 2 postgres postgres 18 Oct 21 22:14 pg_xact
-rw------- 1 postgres postgres 283 Oct 21 22:14 postgresql.auto.conf
-rw------- 1 postgres postgres 27995 Oct 21 22:14 postgresql.conf
-rw------- 1 postgres postgres 0 Oct 21 22:14 standby.signal

-bash-4.2$ ls -l pg_wal/
total 16384
-rw------- 1 postgres postgres 16777216 Oct 21 22:14 000000010000000000000023
drwx------ 2 postgres postgres 6 Oct 21 22:14 archive_status

3.配置备节点&重启

修改备节点 pg_hba.conf，配置 replica 用户的授权
$ vi $PGDATA/pg_hba.conf

host replication replica pgmaster trust

重启数据库（备）
# systemctl restart postgresql-12
# systemctl status postgresql-12

查看日志
# tail -f /var/lib/pgsql/12/data/log/postgresql-2021-10-26.log

4.配置recovery.conf & .pgpass文件（主、备）

4.1）配置recovery.conf（主、备）

PostgreSQL 12版本开始有了变化：
1. $PGDATA 目录下$recovery.conf的配置就融合到postgresql.conf中了（包括 Archive Recovery、Recovery Target、Standby Servers 等系列参数），PostgreSQL 12开始不再有recovery.conf文件：
2. standby_mode 参数不再支持，替换为 $PGDATA 目录下新增了两个文件 recovery.signal 和 standby.signal。这两个文件分别代表处于 recovery 模式还是 standby 模式。如果两个文件都存在，则优先为 standby 模式。因此，主备切换配置更简单了，直接 touch 文件即可。
3. 新增 shared_memory_type = mmap #内存相关，默认为nmap，不用修改
4. pg_basebackup 支持 -R 参数（--write-recovery-conf: write configuration for replication），可以直接生成 standby.signal 文件。
5. postgresql.auto.conf 文件会自动加入/填充流复制 primary_conninfo 参数的信息。
6. postgresql.auto.conf 中的配置优先级高于 postgresql.conf 中的配置，如果两个文件中都配置了，那么生效的是 postgresql.auto.conf。
7. trigger_file 参数更名为 promote_trigger_file
8. recovery_target/recovery_target_lsn/recovery_target_name/recovery_target_time/recovery_target_xid 只能指定其中的一个，如果配置两个或以上，启动时会发生致命错误：FATAL: multiple recovery targets specified。而以前老版本PG<12是自动忽略之前参数的错误、只生效最后一个。
9. PostgreSQL 12开始，恢复配置设置甚至可以在主节点上出现，即：任何已配置的恢复设置（例如 primary_conninfo）都将由PostgreSQL读取、并可以正常显示，因此他们的存在不再代表该节点是否为备节点。
10. ALTERSYSTEM 设置始终优先处理。如果配置恢复参数设置在postgresql.conf中个，但认为执行ALTER SYSTEM来更改设置，则ALTER SYSTEM设置的参数（并写入postgresql.auto.conf）始终优先。因此恢复设置参数配置，建议配置在postgresql.auto.conf中。

因此，如果PG>=12，则 recovery.conf 配置可以跳过，无需配置。

如果 PostgreSQL(<12)：需要参考下面处理：
根据$PGDATA目录下的recovery.done还是recovery.conf还区分主、备状态。进行主备切换的话recovery.done -> recovery.conf，recovery.conf -> recovery.done。主备切换可以通过命令触发、也可以通过修改recovery文件来切换。
a）创建/修改主节点的recovery.done
$ cp $PGHOME/share/recovery.conf.sample $PGDATA/recovery.done
$ vi $PGDATA/recovery.done

recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=pgslave port=5432 user=replica password=replica@1q2w3e'
trigger_file = '/var/lib/pgsql/12/data/trigger_file'

b）创建/修改备节点的recovery.conf
$ cp $PGHOME/share/recovery.conf.sample $PGDATA/recovery.conf
$ vi $PGDATA/recovery.conf

recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=pgmaster port=5432 user=replica password=replica@1q2w3e'
trigger_file = '/var/lib/pgsql/12/data/trigger_file'

4.2）配置.pgpass（主、备）
pg_hba中的replica用户配置认证模式为 md5 认证方式才需要配置，trust 方式可以跳过、无需配置。

.pgpass 是连接 postgresql 时使用的密码文件，一般位置为：~/.pgpass。内容格式为：hostname:port:database:username:password
注意：~/.pgpass 上的权限必须不允许所有人或组内访问，可以用命令 chmod 0600 ~/.pgpass 实现。如果权限没有这么严格，该文件将被忽略。权限过大时，后台日志文件会有提醒
# tail -f /var/lib/pgsql/12/data/log/postgresql-2021-10-26.log
WARNING: password file "/var/lib/pgsql/.pgpass" has group or world access; permissions should be u=rw (0600) or less

主节点配置.pgpass（）：
查看primary_conninfo配置，可以通过当前的备节点上查看信息：
$ cat $PGDATA/postgresql.auto.conf |grep primary_conninfo #如果PG<12则执行 cat $PGDATA/postgresql.conf |grep primary_conninfo 查看
primary_conninfo = 'user=replica passfile=''/var/lib/pgsql/.pgpass'' host=192.168.100.93 port=5432 sslmode=prefer sslcompression=0 gssencmode=prefer krbsrvname=postgres target_session_attrs=any'

主节点创建.pgpass密码文件
# su - postgres
$ vi .pgpass #也就是/var/lib/pgsql/.pgpass
pgslave:5432:replication:replica:replica@1q2w3e
$ chmod 0600 .pgpass

备节点创建.pgpass密码文件
# su - postgres
$ vim .pgpass #也就是/var/lib/pgsql/.pgpass
pgmaster:5432:replication:replica:replica@1q2w3e
$ chmod 0600 .pgpass

5.重启数据库服务（主、备）
# systemctl start postgresql-12
# systemctl status postgresql-12

配置完毕、重启服务后，查看日志，发现有报错：
# tail -f $PGDATA/log/postgresql-2021-10-26.log
2021-10-26 14:53:40.483 CST 3352 FATAL: could not connect to the primary server: fe_sendauth: no password supplied
网上查找资料，具体问题原因没有找到，但有两种规避方案：
方案1）pg_hba.conf 中 replica 用户md5 认证改成 trust
方案2）replication 流复制用户直接改成使用 postgres 超级用户 & postgres 密码、不使用单独创建的 replica 用户
我直接使用方案1，replica 用户改成 trust 模式解决掉了。

6.测试主备同步

6.1）主节点上查看主备同步状态（日志发送情况）：
select * from pg_stat_replication; --通过数据字典查询详情
select client_addr,sync_state,state from pg_stat_replication;

postgres=# select client_addr,sync_state,state from pg_stat_replication;
client_addr | sync_state | state
----------------+------------+-----------
192.168.100.94 | async | streaming

client_addr：主备同步客户端IP地址
sync_state：有三种状态：sync(同步)，async(异步)，potential(虽然现在是异步模式，但有可能升级到同步模式)。注意：主备模式下，备库为只读，不能进入备库的testdb01进行insert操作，否则会报错。
state：同步状态：startup（连接中）、catchup（同步中）、streaming（同步）
默认情况下，我们搭建的主备是异步模式（sync_state: async）。除非主动修改为同步模式。同步模式写数据库时需要等待所有standby同步写完成，因此会影响写性能，一般不推荐同步模式。

6.2）备节点上查看主备同步状态（日志接收情况）：
select * from pg_stat_wal_receiver;
select status,receive_start_lsn,received_lsn,last_msg_send_time,sender_host from pg_stat_wal_receiver;

postgres=# select * from pg_stat_wal_receiver;
pid | status | receive_start_lsn | receive_start_tli | received_lsn | received_tli | last_msg_send_time | last_msg_receipt_time | latest_end_lsn |
latest_end_time | slot_name | sender_host | sender_port |
conninfo
------+-----------+-------------------+-------------------+--------------+--------------+-------------------------------+-------------------------------+----------------+-
------------------------------+-----------+----------------+-------------+-------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------------
3998 | streaming | 0/4A000000 | 1 | 0/4A000940 | 1 | 2021-10-26 15:31:23.753266+08 | 2021-10-26 15:31:26.078671+08 | 0/4A000940 |
2021-10-26 15:17:22.055563+08 | | 192.168.100.93 | 5432 | user=replica passfile=/var/lib/pgsql/.pgpass dbname=replication host=192.168.100.93 port=5432 fa
llback_application_name=walreceiver sslmode=prefer sslcompression=0 gssencmode=prefer krbsrvname=postgres target_session_attrs=any

postgres=# select status,receive_start_lsn,received_lsn,last_msg_send_time,sender_host from pg_stat_wal_receiver;
status | receive_start_lsn | received_lsn | last_msg_send_time | sender_host
-----------+-------------------+--------------+-------------------------------+----------------
streaming | 0/4A000000 | 0/4A000940 | 2021-10-26 15:31:23.753266+08 | 192.168.100.93

6.3）查询当前节点的主备角色/主备状态（当前节点是主节点、还是被节点）
select pg_is_in_recovery(); --f:master, t:slave

注意：
1，select * from pg_stat_replication; --仅主节点有查询结果，如果执行在备节点上查询结果无记录，因为备节点无日志发送
2，select * from pg_stat_wal_receiver; --仅备节点有查询结果，如果执行在主节点上查询结果无记录，因为主节点无日志接收
3，如果查询主备同步信息不正确、没有数据同步的话，请检查 replica 用户的授权配置是否正确，检查之前的配置修改是否正确
4，主备节点状态查询有多重方法，其他相关查询命令，详情可以参考“PostgreSQL主备节点常用查询命令”章节的介绍
5，一般默认推荐配置为异步模式。如果希望用同步模式，则需要主库修改（我跳过该步骤）：
synchronous_standby_names = xxx : 指定sync同步模式的备节点（哪些备节点采用同步模式）。例如，synchronous_standby_names = 'any 1 (pgslave)'，指定的N个(如果有多个，逗号分割)standby中的任意1个standby server应用wal变化之后，primary端的事务才能提交。配置为'*'代表所有备节点
synchronous_commit = on : 打开同步模式(sync)
primary_conninfo = 'application_name=pgslave host=192.168.100.94 port=5432 user=replicat password=replica@1q2w3e' #可以不设置，postgres.auto.conf会自动生成配置，优先级更高
主库执行 alter system set synchronous_standby_names='pgslave';

6.2）创建测试表、插入数据，测试主备同步功能是否OK
主节点创建：
postgres=# create table test01(
id integer not null, name character(255) not null,
price decimal(8,2) not null,
primary key(id)
);

postgres=# insert into test01(id,name,price) values (1,'a',11.5),(2,'b',20.3);
postgres=# select * from test01;

备节点查询：
postgres=# \dt
postgres=# select * from test01;

主节点插入的数据，能再备节点上查询到，则说明主备同步功能OK。

注意：备节点仅支持查询、不支持写入，如果被节点写入会报错：
postgres=# insert into test01 values (4,'d',55.20);
ERROR: cannot execute INSERT in a read-only transaction

7.测试主备切换

PG<12的老版本需要通过手动修改 recovery.conf & recovery.done 来控制切换。
PG>12的版本，主备切换就比较方便，$PGDATA 目录下新增了两个文件 recovery.signal 和 standby.signal 分别代表处于 recovery 模式还是 standby 模式。如果两个文件都存在，则优先为 standby 模式。因此，主备切换配置更简单了，直接 touch 文件即可。

7.1 老的主节点停止服务（模拟主节点宕机）& 切换为备
# systemctl stop postgresql-12
# systemctl status postgresql-12
# touch $PGDATA/standby.signal
注意：这里 recovery.signal 是否要 touch？这个可能和日志恢复有关，touch 这个，可能会导致系统启动后后台日志报错。还没有研究透彻，发现不 touch 暂时也没有发现问题

PG>=12用的是标识文件standby.signal。如果PG<12: mv recovery.done recovery.conf，没有则 touch recovery.conf。

7.2 老的备节点切换为主节点（删除standby.signal） & 重启服务
# su - postgres
$ pg_ctl promote
waiting for server to promote.... done
server promoted

$ ls -l $PGDATA/*.signal
pg_ctl promote 命令将备节点提升为主节点后，对应的 *.signal 信号文件，自动消失了。

注意：如果 pg_ctl promote 命令切换不成功，也可以直接手动删除文件的方式来进行切换 standby.signal
# rm $PGDATA/standby.signal
# rm $PGDATA/recovery.signal #如果：recovery.signal 也存在，也删除掉
我就出现过命令切换不成功的情况，最终是手动删除信号文件的方式来完成切换的

7.3 重启老的备节点（新的主）服务
# systemctl restart postgresql-12

查看新的主节点（老的备）状态，已经切换成功：
# ps aux |grep postgres
# pg_controldata |grep cluster
Database cluster state: in production

7.4 重启新的备节点（老的主）：
# systemctl restart postgresql-12

查看新的备节点（老的主）状态，已经切换成功：
# ps aux |grep postgres
# pg_controldata |grep cluster
Database cluster state: in archive recovery

最初我切换后有点问题，日志如下：
# tail -f $PGDATA/log/postgresql-2021-10-27.log
2021-10-27 13:31:55.234 CST 6082 LOG: received fast shutdown request
2021-10-27 13:31:55.236 CST 6082 LOG: aborting any active transactions
2021-10-27 13:31:55.238 CST 6086 LOG: shutting down
2021-10-27 13:31:55.269 CST 6082 LOG: database system is shut down
2021-10-27 13:31:55.426 CST 6108 LOG: database system was shut down in recovery at 2021-10-27 13:31:55 CST
2021-10-27 13:31:55.426 CST 6108 WARNING: specified neither primary_conninfo nor restore_command
2021-10-27 13:31:55.426 CST 6108 HINT: The database server will regularly poll the pg_wal subdirectory to check for files placed there.
2021-10-27 13:31:55.426 CST 6108 LOG: entering standby mode
2021-10-27 13:31:55.427 CST 6108 LOG: consistent recovery state reached at 0/4B0000A0
2021-10-27 13:31:55.427 CST 6108 LOG: invalid record length at 0/4B0000A0: wanted 24, got 0
2021-10-27 13:31:55.428 CST 6105 LOG: database system is ready to accept read only connections

两条信息引起了我的注意：
1，LOG: invalid record length at 0/4B0000A0: wanted 24, got 0
2，WARNING: specified neither primary_conninfo nor restore_command

1，LOG: invalid record length at 0/4B0000A0: wanted 24, got 0
LOG: invalid record length at 0/4B0000A0: wanted 24, got 0
这个告警信息，网上找资料，说是因为数据库异常关闭后重启导致的，例如进程直接被kill。
当数据库异常关闭时，数据库的共享缓冲区中的数据还没有来得及flush到磁盘中，必然导致数据丢失，此时启动数据库则是从不正常的状态启动。
当PostgreSQL数据库崩溃恢复（非正常启动）时，会以最近的checkpoint为基础，不断应用其之后的wal日志来恢复数据。当检测到没有wal日志可以重放时，就会打印该日志。
这个日志应该可以忽略。

2，WARNING: specified neither primary_conninfo nor restore_command
测试了一下，尝试新主节点（老的备）上插入数据看看能否同步到新的备（老的主），发现数据没有同步。
再仔细检查新主、新备节点的进程，发现新主节点没有日志发送进程，新备节点没有日志接收进程，不知道和日志告警有没有关系。

继续定位排查新备（老的主）节点配置

postgresql.auto.conf检查，发现 postgresql.auto.conf 没有自用生成 primary_conninfo 信息：
# cat $PGDATA/postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.

数据库执行命令查看：
# psql -Upostgres
postgres=# show primary_conninfo;

配置信息为空

查找原因，为什么postgresql.auto.conf没有自动生成primary_conninfo信息？
standby.signal
A file determining whether a node starts up as a standby
standby.signal is an optional data directory file determining whether the node starts up as a standby.
standby.signal was added in PostgreSQL 12, replacing the replication configuration parameter standby_mode.

Usage
If the file standby.signal is present in the data directory, the server will start in standby mode and enter recovery.
The standby.signal can be empty, or contain arbitrary data (for example, a replication management tool could write information noting details about when/how the standby was created).
Note that if standby.signal is present, but neither primary_conninfo nor restore_command are specified, the server will start up in recovery and wait for WAL files to be placed in the pg_wal directory by an external process:
[2021-05-12 08:36:12 UTC] WARNING: 01000: specified neither primary_conninfo nor restore_command
[2021-05-12 08:36:12 UTC] HINT: The database server will regularly poll the pg_wal subdirectory to check for files placed there.
If both standby.signal and recovery.signal are present in the data directory, standby.signal takes precedence. This situation is not logged.

最初怀疑是 postgresql.auto.conf 的自动注入信息来自 standby.signal ，以为 standby.signal 我手动touch 生成的空文件的缘故导致的。

手动修改 standby.signal 填入primmary_conninfo，重启数据库，问题也没有得到解决：
# vi $PGDATA/standby.signal
primary_conninfo = 'user=replica passfile=''/var/lib/pgsql/.pgpass'' host=192.168.100.94 port=5432 sslmode=prefer sslcompression=0 gssencmode=prefer krbsrvname=postgres target_session_attrs=any'
# systemc restart postgresql-12

手动直接修改 postgresql.auto.conf 文件，添加配置信息&重启服务，还是没有解决。

再尝试 alter system set parameter_name = values 方式修改：
# psql -Upostgres
postgres=# alter system set primary_conninfo = 'user=replica passfile=''/var/lib/pgsql/.pgpass'' host=192.168.100.94 port=5432 sslmode=prefer sslcompression=0 gssencmode=prefer krbsrvname=postgres target_session_attrs=any'

重启服务
# systemctl restart postgresql-12

终于生效了，问题解决，主节点 walsender 进程 & 备节点 walreceiver 进程起来了。

注意：每次主备切换以后，如果没有自动注入修改生效 primary_conninfo ，还是对应的老的主节点IP，需要手动 alter system 重新修改指定连接主节点信息。还没有找到是否有更好的解决方案。

另外，如果出现primary_conninfo（show primary_conninfo;）配置为空或IP不正确，我有个想法：可能直接在postgresql.conf中指定primary_conninfo，也许能解决该问题（不过我没有再尝试了，因为后面主备切换多次，类似问题没有再次出现，没法验证）。因为官方的处理过程说明是先加载postgresql.auto.conf中的配置，如果没有找到参数配置，则从postgresql.conf中加载参数配置。所以，如果postgresql.auto.conf中没有自动注入配置的话，理论上我直接在每个节点的本地的postgresql.conf中指定了primary_conninfo参数的话，应该也能解决该问题。

查看新主进程：
[root@pgslave data]# ps aux |grep post
root 1110 0.0 0.0 89708 2220 ? Ss Oct23 0:01 /usr/libexec/postfix/master -w
postfix 1112 0.0 0.0 89880 4100 ? S Oct23 0:00 qmgr -l -t unix -u
postfix 30729 0.0 0.0 89812 4080 ? S 14:14 0:00 pickup -l -t unix -u
postgres 30894 0.0 2.5 1056000 202912 ? Ss 15:08 0:00 /usr/pgsql-12/bin/postmaster -D /var/lib/pgsql/12/data/
postgres 30896 0.0 0.0 249708 2056 ? Ss 15:08 0:00 postgres: logger
postgres 30898 0.0 0.1 1057388 11144 ? Ss 15:08 0:00 postgres: checkpointer
postgres 30899 0.0 0.1 1057288 10480 ? Ss 15:08 0:00 postgres: background writer
postgres 30900 0.0 0.2 1056000 18660 ? Ss 15:08 0:00 postgres: walwriter
postgres 30901 0.0 0.0 1060152 3328 ? Ss 15:08 0:00 postgres: autovacuum launcher
postgres 30902 0.0 0.0 251824 1948 ? Ss 15:08 0:00 postgres: archiver
postgres 30903 0.0 0.0 251824 2228 ? Ss 15:08 0:00 postgres: stats collector
postgres 30904 0.0 0.0 1060132 2828 ? Ss 15:08 0:00 postgres: logical replication launcher
root 30959 0.0 0.0 184596 3976 pts/1 S+ 15:36 0:00 psql -Upostgres
postgres 30960 0.0 0.0 1060560 4668 ? Ss 15:36 0:00 postgres: postgres postgres [local] idle
postgres 30976 0.0 0.0 1060692 4320 ? Ss 15:46 0:00 postgres: walsender replica 192.168.100.93(56630) streaming 0/4E000D48
root 30984 0.0 0.0 112816 980 pts/0 S+ 15:51 0:00 grep --color=auto post

查看新备进程：
# ps aux |grep post
root 1178 0.0 0.0 89708 2220 ? Ss Oct26 0:00 /usr/libexec/postfix/master -w
postfix 1186 0.0 0.0 89880 4100 ? S Oct26 0:00 qmgr -l -t unix -u
postfix 6516 0.0 0.0 89812 4084 ? S 15:37 0:00 pickup -l -t unix -u
postgres 6571 0.0 2.5 1056000 202896 ? Ss 15:46 0:00 /usr/pgsql-12/bin/postmaster -D /var/lib/pgsql/12/data/
postgres 6573 0.0 0.0 249708 2048 ? Ss 15:46 0:00 postgres: logger
postgres 6574 0.0 0.0 1056132 3076 ? Ss 15:46 0:00 postgres: startup recovering 00000001000000000000004E
postgres 6575 0.0 0.0 1056000 2068 ? Ss 15:46 0:00 postgres: checkpointer
postgres 6576 0.0 0.0 1056000 6272 ? Ss 15:46 0:00 postgres: background writer
postgres 6577 0.0 0.0 251824 1944 ? Ss 15:46 0:00 postgres: stats collector
postgres 6578 0.1 0.0 1067708 5084 ? Ss 15:46 0:00 postgres: walreceiver streaming 0/4E000D48
root 6579 0.0 0.0 184596 3980 pts/0 S+ 15:46 0:00 psql -U postgres
postgres 6580 0.0 0.0 1061024 5676 ? Ss 15:46 0:00 postgres: postgres postgres [local] idle
root 6585 0.0 0.0 112812 980 pts/1 S+ 15:51 0:00 grep --color=auto post

连接新备（老主）节点数据库，查询表的数据也OK，切换后，新主（老备）节点新加的数据，也已经同步过来了，两边一致了。

遗留问题：
1）主备切换后，新备(老主)节点，为什么 postgresql.auto.conf 中的 primary_conninfo 不会自动注入？
2）为什么直接修改 postgresql.auto.conf 指定 primary_conninfo & 重启服务，配置不生效？必须手动 alter system set parameter_name = values 才能生效？
3）postgresql.auto.conf 的自动注入原理是什么？
4）recovery.signal 的用途？从官方的解释来看，应该是控制 wal 日志重放恢复数据的控制标记。如果当前备节点 touch recovery.signal 启动服务时，如果日志没有同步，可能会导致处理错误
To start the server in targeted recovery mode, create a file called recovery.signal in the data directory.
If both standby.signal and recovery.signal files are created, standby mode takes precedence.
Targeted recovery mode ends when the archived WAL is fully replayed, or when recovery_target is reached. In this mode, the parameters from both this section and Section 19.5.5 will be used.

主备切换过程中遇到的其他问题：
1）主备切换时，新的备库节点重启数据库服务时报错：Unit postgresql-12.service entered failed state. 数据库服务无法启动：

[root@pgslave ~]# systemctl restart postgresql-12
Job for postgresql-12.service failed because the control process exited with error code. See "systemctl status postgresql-12.service" and "journalctl -xe" for details.

[root@pgslave ~]# systemctl status postgresql-12
● postgresql-12.service - PostgreSQL 12 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-12.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2021-10-27 19:11:33 CST; 2min 46s ago
Docs: https://www.postgresql.org/docs/12/static/
Process: 31684 ExecStart=/usr/pgsql-12/bin/postmaster -D ${PGDATA} (code=exited, status=1/FAILURE)
Process: 31678 ExecStartPre=/usr/pgsql-12/bin/postgresql-12-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
Main PID: 31684 (code=exited, status=1/FAILURE)

Oct 27 19:11:32 pgslave postmaster[31684]: 2021-10-27 19:11:32.836 CST 31684 LOG: listening on IPv4 address "0.0.0.0", port 5432
Oct 27 19:11:32 pgslave postmaster[31684]: 2021-10-27 19:11:32.836 CST 31684 LOG: listening on IPv6 address "::", port 5432
Oct 27 19:11:32 pgslave postmaster[31684]: 2021-10-27 19:11:32.837 CST 31684 LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
Oct 27 19:11:32 pgslave postmaster[31684]: 2021-10-27 19:11:32.838 CST 31684 LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
Oct 27 19:11:32 pgslave postmaster[31684]: 2021-10-27 19:11:32.976 CST 31684 LOG: redirecting log output to logging collector process
Oct 27 19:11:32 pgslave postmaster[31684]: 2021-10-27 19:11:32.976 CST 31684 HINT: Future log output will appear in directory "log".
Oct 27 19:11:33 pgslave systemd[1]: postgresql-12.service: main process exited, code=exited, status=1/FAILURE
Oct 27 19:11:33 pgslave systemd[1]: Failed to start PostgreSQL 12 database server.
Oct 27 19:11:33 pgslave systemd[1]: Unit postgresql-12.service entered failed state.
Oct 27 19:11:33 pgslave systemd[1]: postgresql-12.service failed.
[root@pgslave ~]#
[root@pgslave ~]# journalctl -xe
-- Unit postgresql-12.service has begun starting up.
Oct 27 19:04:59 pgslave postmaster[31638]: 2021-10-27 19:04:59.457 CST 31638 LOG: starting PostgreSQL 12.8 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623
Oct 27 19:04:59 pgslave postmaster[31638]: 2021-10-27 19:04:59.457 CST 31638 LOG: listening on IPv4 address "0.0.0.0", port 5432
Oct 27 19:04:59 pgslave postmaster[31638]: 2021-10-27 19:04:59.457 CST 31638 LOG: listening on IPv6 address "::", port 5432
Oct 27 19:04:59 pgslave postmaster[31638]: 2021-10-27 19:04:59.458 CST 31638 LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
Oct 27 19:04:59 pgslave postmaster[31638]: 2021-10-27 19:04:59.458 CST 31638 LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
Oct 27 19:04:59 pgslave postmaster[31638]: 2021-10-27 19:04:59.595 CST 31638 LOG: redirecting log output to logging collector process
Oct 27 19:04:59 pgslave postmaster[31638]: 2021-10-27 19:04:59.595 CST 31638 HINT: Future log output will appear in directory "log".
Oct 27 19:04:59 pgslave systemd[1]: postgresql-12.service: main process exited, code=exited, status=1/FAILURE
Oct 27 19:04:59 pgslave systemd[1]: Failed to start PostgreSQL 12 database server.
-- Subject: Unit postgresql-12.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit postgresql-12.service has failed.
--
-- The result is failed.
Oct 27 19:04:59 pgslave systemd[1]: Unit postgresql-12.service entered failed state.
Oct 27 19:04:59 pgslave systemd[1]: postgresql-12.service failed.
Oct 27 19:04:59 pgslave polkitd[691]: Unregistered Authentication Agent for unix-process:31626:32968459 (system bus name :1.270, object path /org/freedesktop/PolicyKit1/Au
Oct 27 19:06:49 pgslave polkitd[691]: Registered Authentication Agent for unix-process:31646:32979477 (system bus name :1.271 [/usr/bin/pkttyagent --notify-fd 5 --fallback
Oct 27 19:06:49 pgslave systemd[1]: Starting PostgreSQL 12 database server...
-- Subject: Unit postgresql-12.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit postgresql-12.service has begun starting up.
Oct 27 19:06:49 pgslave postmaster[31658]: 2021-10-27 19:06:49.623 CST 31658 LOG: starting PostgreSQL 12.8 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623
Oct 27 19:06:49 pgslave postmaster[31658]: 2021-10-27 19:06:49.623 CST 31658 LOG: listening on IPv4 address "0.0.0.0", port 5432
Oct 27 19:06:49 pgslave postmaster[31658]: 2021-10-27 19:06:49.623 CST 31658 LOG: listening on IPv6 address "::", port 5432
Oct 27 19:06:49 pgslave postmaster[31658]: 2021-10-27 19:06:49.624 CST 31658 LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
Oct 27 19:06:49 pgslave postmaster[31658]: 2021-10-27 19:06:49.625 CST 31658 LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
Oct 27 19:06:49 pgslave postmaster[31658]: 2021-10-27 19:06:49.758 CST 31658 LOG: redirecting log output to logging collector process
Oct 27 19:06:49 pgslave postmaster[31658]: 2021-10-27 19:06:49.758 CST 31658 HINT: Future log output will appear in directory "log".
Oct 27 19:06:49 pgslave systemd[1]: postgresql-12.service: main process exited, code=exited, status=1/FAILURE
Oct 27 19:06:49 pgslave systemd[1]: Failed to start PostgreSQL 12 database server.
-- Subject: Unit postgresql-12.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit postgresql-12.service has failed.
--
-- The result is failed.
Oct 27 19:06:49 pgslave systemd[1]: Unit postgresql-12.service entered failed state.
Oct 27 19:06:49 pgslave systemd[1]: postgresql-12.service failed.
Oct 27 19:06:49 pgslave polkitd[691]: Unregistered Authentication Agent for unix-process:31646:32979477 (system bus name :1.271, object path /org/freedesktop/PolicyKit1/Au
lines 1815-1860/1860 (END)

最后实在没有办法了，把备库的 data 目录备份以后，直接删除 data 下的所有文件，重新从主库拷贝一份过来：
先备份，再删除，再从主库拷贝：
# cd $PGDATA
# rm -rf *

pg_basebackup 从主节点拷贝$PGDATA下的所有文件及目录到备节点$PGDATA目录下
# su - postgres
$ pg_basebackup --help #查看命令帮助
$ pwd #确认路径正确: /var/lib/pgsql/12/data
$ pg_basebackup -h 192.168.100.93 -D /var/lib/pgsql/12/data -U replica -v -P -R #从主节点拷贝$PGDATA到备节点
$ exit
#

重启数据库（备）
# systemctl restart postgresql-12
# systemctl status postgresql-12

OK，问题解决。是否有其他解决办法？后面有空再研究。

PostgreSQL主备节点常用查询命令

> 主节点上查看主备同步状态（日志发送情况）：
select * from pg_stat_replication; --仅主节点有查询结果，如果执行在备节点上查询结果无记录，因为备节点无日志发送
select client_addr,sync_state,state from pg_stat_replication;

> 备节点上查看主备同步状态（日志接收情况）：
select * from pg_stat_wal_receiver; --仅备节点有查询结果，如果执行在主节点上查询结果无记录，因为主节点无日志接收
select status,receive_start_lsn,received_lsn,last_msg_send_time,sender_host from pg_stat_wal_receiver;

> 查询当前节点的主备角色/主备状态（当前节点是主节点还是被节点）
select pg_is_in_recovery(); --f:master, t:slave

> pg_controldata 查询PostgreSQL集群控制信息详情
$ pg_controldata

> pg_controldata 查询集群状态(Database cluster state)
$ pg_controldata |grep cluster #in production: master；in archive recovery: slave

集群状态有下面几种：
   DB_STARTUP = 0 /*数据库启动*/
   DB_SHUTDOWNED /*数据库正常关闭*/
   DB_SHUTDOWNED_IN_RECOVERY /*数据库在恢复时关闭*/
   DB_SHUTDOWNING /*数据库启动到正常关闭过程中崩溃*/
   DB_IN_CRASH_RECOVERY /*数据库在恢复过程中崩溃*/
   DB_IN_ARCHIVE_RECOVERY /*数据库处于归档恢复*/
   DB_IN_PRODUCTION /*数据库处于正常工作状态，等待接受事务处理*/

> 主节点进程查看
通过进程查看也能区分当前节点是主还是被：主节点有日志发送进程、备节点有日志接收进程
-bash-4.2$ ps aux |grep post
root 1075 0.0 0.0 89708 2220 Ss 13:33 0:00 /usr/libexec/postfix/master -w
postfix 1077 0.0 0.0 89880 4104 S 13:33 0:00 qmgr -l -t unix -u
root 2224 0.0 0.0 191884 2360 pts/0 S 15:00 0:00 su - postgres
postgres 2225 0.0 0.0 115544 2052 pts/0 S 15:00 0:00 -bash
postgres 3693 0.0 2.5 1056000 202940 Ss 21:49 0:00 /usr/pgsql-12/bin/postmaster -D /var/lib/pgsql/12/data/
postgres 3695 0.0 0.0 249708 2552 Ss 21:49 0:00 postgres: logger
postgres 3697 0.0 0.1 1057288 11320 Ss 21:49 0:00 postgres: checkpointer
postgres 3698 0.0 0.1 1057288 10876 Ss 21:49 0:00 postgres: background writer
postgres 3699 0.0 0.2 1056000 19016 Ss 21:49 0:00 postgres: walwriter #写WAL日志进程
postgres 3700 0.0 0.0 1060152 3596 Ss 21:49 0:00 postgres: autovacuum launcher
postgres 3701 0.0 0.0 251824 2412 Ss 21:49 0:00 postgres: archiver last was 000000010000000000000025.00000028.backup
postgres 3702 0.0 0.0 251944 2672 Ss 21:49 0:00 postgres: stats collector
postgres 3703 0.0 0.0 1060132 3224 Ss 21:49 0:00 postgres: logical replication launcher
postfix 3725 0.0 0.0 89812 4080 S 21:53 0:00 pickup -l -t unix -u
postgres 3874 0.0 0.0 1060300 4068 Ss 22:43 0:00 postgres: walsender replica 192.168.100.94(56520) streaming 0/26000148 #主节点日志发送进程
root 3877 0.0 0.0 191884 2356 pts/0 S 22:44 0:00 su - postgres
postgres 3878 0.0 0.0 115544 2100 pts/0 S 22:44 0:00 -bash
postgres 3921 0.0 0.0 155476 1876 pts/0 R+ 22:51 0:00 ps aux
postgres 3922 0.0 0.0 112812 980 pts/0 S+ 22:51 0:00 grep --color=auto post
-bash-4.2$

-bash-4.2$ systemctl status postgresql-12
● postgresql-12.service - PostgreSQL 12 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-12.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2021-10-25 21:07:07 CST; 13h ago
Docs: https://www.postgresql.org/docs/12/static/
Process: 13388 ExecStartPre=/usr/pgsql-12/bin/postgresql-12-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
Main PID: 13394 (postmaster)
CGroup: /system.slice/postgresql-12.service
├─13394 /usr/pgsql-12/bin/postmaster -D /var/lib/pgsql/12/data/
├─13396 postgres: logger
├─13398 postgres: checkpointer
├─13399 postgres: background writer
├─13400 postgres: walwriter #写WAL日志进程
├─13401 postgres: autovacuum launcher
├─13402 postgres: archiver
├─13403 postgres: stats collector
├─13404 postgres: logical replication launcher
└─13406 postgres: walsender replica 192.168.100.94(53946) streaming 0/3A0001C0 #主节点日志发送进程

> 备节点进程
通过进程查看也能区分当前节点是主还是被：主节点有日志发送进程、备节点有日志接收进程
-bash-4.2$ ps aux |grep post
root 1078 0.0 0.0 89708 2216 Ss 13:33 0:00 /usr/libexec/postfix/master -w
postfix 1080 0.0 0.0 89880 4100 S 13:33 0:00 qmgr -l -t unix -u
postfix 2936 0.0 0.0 89812 4084 S 21:54 0:00 pickup -l -t unix -u
postgres 3098 0.0 2.5 1056000 202896 Ss 22:43 0:00 /usr/pgsql-12/bin/postmaster -D /var/lib/pgsql/12/data/
postgres 3100 0.0 0.0 249708 2048 Ss 22:43 0:00 postgres: logger
postgres 3101 0.0 0.0 1056132 2808 Ss 22:43 0:00 postgres: startup recovering 000000010000000000000026
postgres 3102 0.0 0.0 1056000 2068 Ss 22:43 0:00 postgres: checkpointer
postgres 3103 0.0 0.0 1056000 6276 Ss 22:43 0:00 postgres: background writer
postgres 3104 0.0 0.0 251824 1944 Ss 22:43 0:00 postgres: stats collector
postgres 3105 0.0 0.0 1062892 4304 Ss 22:43 0:00 postgres: walreceiver #备节点日志接收进程
root 3108 0.0 0.0 191884 2356 pts/0 S 22:45 0:00 su - postgres
postgres 3109 0.0 0.0 115544 2052 pts/0 S 22:45 0:00 -bash
postgres 3144 0.0 0.0 155476 1876 pts/0 R+ 22:52 0:00 ps aux
postgres 3145 0.0 0.0 112816 980 pts/0 S+ 22:52 0:00 grep --color=auto post
-bash-4.2$

-bash-4.2$ systemctl status postgresql-12
● postgresql-12.service - PostgreSQL 12 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-12.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2021-10-25 21:07:16 CST; 13h ago
Docs: https://www.postgresql.org/docs/12/static/
Process: 26764 ExecStartPre=/usr/pgsql-12/bin/postgresql-12-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
Main PID: 26770 (postmaster)
CGroup: /system.slice/postgresql-12.service
├─26770 /usr/pgsql-12/bin/postmaster -D /var/lib/pgsql/12/data/
├─26772 postgres: logger
├─26773 postgres: startup recovering 00000001000000000000003A
├─26774 postgres: checkpointer
├─26775 postgres: background writer
├─26776 postgres: stats collector
└─26777 postgres: walreceiver streaming 0/3A0001C0 #备节点日志接收进程

> 查看快照
postgres-# \c testdb01 --切换对应db
testdb01=# select txid_current_snapshot(); --查看快照，返回主库记录点、备库记录点。主库每增加一条写入，记录点的值就会加1
txid_current_snapshot
-----------------------
490:490:

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/你好赵伟/article/detail/449879?site