postgresql 重启记录_PostgreSQL 高可用:PostgreSQL复制和自动故障转移

最新推荐文章于 2024-05-06 19:34:16 发布
最新推荐文章于 2024-05-06 19:34:16 发布
阅读量611 收藏
点赞数
文章标签： postgresql 重启记录
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_39707536/article/details/113579779
版权

原文:PostgreSQL Replication and Automatic Failover Tutorial[1]

作者：Abbas Butt 

翻译整理：alitrack

1.什么是 PostgreSQL 复制？

将数据从一台 PostgreSQL 数据库服务器复制到另一台服务器的过程称为 PostgreSQL 复制。源数据库服务器通常称为主服务器，而接收复制的数据的数据库服务器称为副本服务器。

d0de4f7db57f7e1b217d8fa34bf34777.png

PostgreSQL复制

2.什么是 PostgreSQL 中的自动故障转移？

在 PostgreSQL 中设置并配置了物理流复制后，如果数据库的主服务器发生故障，则可以进行故障转移。故障转移是描述恢复过程的术语，在 PostgreSQL 中可能需要一些时间[2]，特别是因为 PostgreSQL 本身不提供用于检测服务器故障的内置工具。幸运的是，有可用的工具允许自动故障转移，它可以帮助检测故障并自动切换到备用数据库，从而最大程度地减少数据库停机时间。

EnterpriseDB 的EDB Postgres Failover Manager[3]使您能够自动检测数据库故障，并将最新的备用服务器升级为新的主服务器，从而避免了代价高昂的数据库停机时间。EDB Failover Manager 甚至提供快速，自动的故障检测[4]。

3.高可用性和故障转移复制

高可用性是指已建立的数据库系统，以便在主服务器或主服务器发生故障时备用服务器可以快速接管。为了实现高可用性，数据库系统应满足一些关键要求[5]：数据库系统应具有冗余以防止单点故障，可靠的切换机制以及主动监视功能以检测可能发生的任何故障。设置故障转移复制可通过在主服务器或主服务器出现故障时确保备用服务器可用来提供所需的冗余，以实现高可用性。

4.为什么要使用 PostgreSQL 复制？

数据复制可以有多种用途：

  • OLTP 性能
  • 容错能力
  • 数据迁移
  • 并行测试系统

OLTP性能：从联机事务处理(OLTP)系统中消除报告查询负载可以改善报告查询时间和事务处理性能。

容错能力：如果主数据库服务器发生故障，则副本服务器可以接管，因为它已经包含了主服务器的数据。在此配置中，副本服务器也称为备用服务器。此配置还可以用于主服务器的定期维护。

数据迁移：升级数据库服务器硬件，或为另一个客户部署相同的系统。

并行测试系统：将应用程序从一个 DBMS 移植到另一个 DBMS 时，必须比较新旧系统在相同数据上的结果，以确保新系统能够按预期工作。

EnterpriseDB 的EDB Postgres Replication Server[6]使管理 Postgres 复制变得容易，并提供了复制提供的所有好处。

5. PostgreSQL 数据库复制的模型是什么(单主机和多主机)？

  • 单原版复制(SMR)
  • 多主复制(MMR)

在单主复制(SMR)中，将对指定的主数据库服务器中表行的更改复制到一个或多个副本服务器。副本数据库中的复制表不允许接受任何更改(主服务器除外)。但是，即使这样做，更改也不会被复制回主服务器。

在多主复制(MMR)中，对多个指定主数据库中表行的更改将复制到每个其他主数据库中的对应表中。在该模型中，通常采用冲突解决方案来避免诸如重复主键之类的问题。

efe782dc22091b7bea856ea6a415509c.png

PostgreSQL数据库复制

多主复制(MMR)增加了复制的用途：

  • 写可用性和可伸缩性。
  • 可以使用主数据库的广域网(WAN)，该数据库在地理位置上可以接近客户端组，但仍可以保持整个网络的数据一致性。

6. PostgreSQL 复制的类是什么？

  • 单向复制
  • 双向复制

单主复制也称为单向复制，因为复制数据仅在一个方向上从主复制流向复制。

另一方面，多主复制数据在两个方向上流动，因此被称为双向复制。

7. PostgreSQL 数据库中有哪些复制模式？

  • 异步复制模式
  • 同步复制模式

在同步模式复制中，仅当这些更改已复制到所有副本时，才声明主数据库上的事务已完成。副本服务器必须始终都是可用的，事务才能在主服务器上完成。

6496aa01a324f3204f7d05fec79c4642.png

同步模式PostgreSQL复制

在异步模式下，仅在主服务器上完成更改后，即可声明主服务器上的事务已完成。然后，这些更改将在以后及时复制到副本中。副本服务器可以在一定时间内保持不同步状态，这称为复制滞后。

0ad7c14719b0194df15072166d9ae55c.png

PostgreSQL数据库中的复制模式

同步和异步模式都有其成本和收益，用户在配置其复制设置[7]时会希望考虑安全性和性能。

8. PostgreSQL 数据库复制的类型是什么？

  • PostgreSQL 数据库的物理复制
  • PostgreSQL 数据库的逻辑复制

在讨论物理和逻辑复制类型之前，让我们在这里回顾术语物理和逻辑的上下文。

逻辑操作物理操作
1初始化数据库为集群创建基本目录
2创建数据库在基本目录中创建一个子目录
3创建表在数据库的子目录中创建一个文件
4插入更改为此特定表创建的文件，并在当前 WAL 段中写入新的 WAL 记录

例如：

ramp=# create table sample_tbl(a int, b varchar(255));
CREATE TABLE

ramp=# SELECT pg_relation_filepath('sample_tbl');
pg_relation_filepath 
base/34740/706736
(1 row)

ramp=# SELECT datname, oid FROM pg_database WHERE datname = 'ramp';
datname |  oid  
ramp    | 34740
(1 row)

ramp=# SELECT relname, oid FROM pg_class WHERE relname = 'sample_tbl';
relname   |  oid   
sample_tbl | 706736
(1 row)

物理复制处理文件和目录。它不知道这些文件和目录代表什么。物理复制是在文件系统级别或磁盘级别完成的。

另一方面，逻辑复制处理数据库，表和 DML 操作。因此，在逻辑复制中可能只复制某些表集。逻辑复制在数据库集群级别完成。

9. PostgreSQL 数据库中的预写日志(WAL)简介

9.1 在 PostgreSQL 中什么是预写日志(WAL)？为什么需要？

在 PostgreSQL 中，事务所做的所有更改都首先保存在日志文件中，然后将事务的结果发送到启动客户端。数据文件本身不会在每个事务中更改。这是防止操作系统崩溃，硬件故障或 PostgreSQL 崩溃等情况下数据丢失的标准机制。此机制称为预写日志记录(WAL)，而此日志文件称为Write Ahead Log(预写日志)。

事务执行的每个更改(INSERT，UPDATE，DELETE，COMMIT)都作为WAL记录写入日志中。首先将 WAL 记录写入内存中的WAL缓冲区。提交事务后，记录将写入磁盘上的WAL段文件中。

WAL 记录的日志序号(LSN)表示记录保存在日志文件中的位置。LSN 用作 WAL 记录的唯一 ID。从逻辑上讲，事务日志是一个大小为 2^64 字节的文件。因此，LSN 是一个 64 位数字，表示为两个用/分隔的 32 位十六进制数字。例如：

ramp=# select pg_current_wal_lsn();
pg_current_wal_lsn 
0/2BDBBD0
(1 row)

如果发生系统崩溃，数据库可以从 WAL 恢复已提交的事务。恢复从最后一个REDO点或检查点开始。一个检查点是在事务日志中的所有数据文件已被更新，以匹配日志中的信息点。将 WAL 记录从日志文件保存到实际数据文件的过程称为检查点。

让我们考虑一种情况，在两次执行一次插入的事务后数据库崩溃，并且使用 WAL 进行恢复。

  1. 假设已发出检查点，该检查点存储了当前 WAL 段中最新 REDO 点的位置。这还将刷新共享缓冲池中的所有脏页到磁盘。此操作保证了 REDO 点之前的 WAL 记录不再需要恢复，因为所有数据均已刷新到磁盘页面。
  2. 发出第一个 INSERT 语句。该表的页面从磁盘加载到缓冲池。
  3. 元组被插入到加载的页面中。
  4. 该插入的 WAL 记录保存在位置 LSN_1 的 WAL 缓冲区中。
  5. 该页面的 LSN 从 LSN_0 更新为 LSN_1，该 LSN_1 标识了对该页面的最后更改的 WAL 记录。
  6. 发出第一个 COMMIT 语句。
  7. 该提交动作的 WAL 记录被写入 WAL 缓冲区，然后 WAL 缓冲区中直到该页面的 LSN 的所有 WAL 记录都被刷新到 WAL 段文件中。
  8. 对于第二次 INSERT 和 commit，重复步骤 2 至 7。

d3a752e2d39645108405537768f6da7f.png

PostgreSQL中的WAL

如果操作系统崩溃，则共享缓冲池上的所有数据都将丢失。但是，对页面的所有修改都已作为历史数据写入 WAL 段文件中。以下步骤显示了如何使用 WAL 记录将数据库集群恢复到崩溃前的状态。无需执行任何特殊操作-重启后 PostgreSQL 将自动进入恢复模式。

  1. PostgreSQL 从适当的 WAL 段文件中读取第一个 INSERT 语句的 WAL 记录。
  2. PostgreSQL 将表的页面从数据库集群加载到共享缓冲池中。
  3. PostgreSQL 将 WAL 记录的 LSN(LSN_1)与页面 LSN(LSN_0)进行比较。由于 LSN_1 大于 LSN_0，因此 WAL 记录中的元组将插入到页面中，并且页面的 LSN 被更新为 LSN_1。

其余的 WAL 记录以类似的方式重放。

6173686ced32a8b1bb1532bdcd079f84.png

PostgreSQL中的WAL记录

10. PostgreSQL 中的事务日志和 WAL 段文件是什么？

PostgreSQL 事务日志是一个虚拟文件，容量为 8 个字节。从物理上讲，该日志分为 16MB 的文件，每个文件称为 WAL 段。

WAL 段文件名是一个 24 位数字，其命名规则如下：

3c2376966b6879aa0bfc47e6e86025f8.png

PostgreSQL中的WAL段文件

假设当前时间线 ID 为 0x00000001，则第一个 WAL 段文件名将为：

    00000001 00000000 0000000

    00000001 00000000 0000001

    00000001 00000000 0000002

    ……….

    00000001 00000001 0000000

    00000001 00000001 0000001

    00000001 00000001 0000002

    …………

    00000001 FFFFFFFF FFFFFFFD

    00000001 FFFFFFFF FFFFFFFE

    00000001 FFFFFFFF FFFFFFFF

例如：

ramp=# select pg_walfile_name('0/2BDBBD0');
pg_walfile_name      
000000010000000000000002

11. PostgreSQL 中的 WAL Writer 是什么？

WAL 编写器是一个后台进程，它定期检查 WAL 缓冲区并将所有未写的 WAL 记录写入 WAL 段。WAL 编写器避免了 IO 活动的爆发，而是随着时间的推移几乎没有 IO 活动地扩展了其过程。配置参数 wal_writer_delay 控制 WAL 编写器刷新 WAL 的频率，默认值为 200 毫秒。

12. WAL 段文件管理

12.1 WAL 段文件存储在哪里？

WAL 段文件存储在 pg_wal 子目录中。

12.2 PostgreSQL 切换到新的 WAL 段文件时的条件是什么？

PostgreSQL 在以下情况下切换到新的 WAL 段文件：

  • WAL 段已被填满。
  • 已发出函数 pg_switch_wal。
  • 启用了 archive_mode，并且超过了设置为 archive_timeout 的时间。

将它们关掉后，可以删除或回收 WAL 文件，即为将来重命名和重用。服务器在任何时间点将保留的 WAL 文件的数量取决于服务器配置和服务器活动。

每当检查点启动时，PostgreSQL 都会估算并准备该检查点周期所需的 WAL 段文件的数量。基于先前检查点周期中消耗的文件数进行估算。它们是从包含先前 REDO 点的段开始计算的，其值应介于 min_wal_size(默认为 80MB 或 5 个文件)和 max_wal_size(1GB 或 64 个文件)之间。如果启动检查点，则将保留并回收必要的文件，同时将删除不必要的文件。

下图提供了一个示例。假设在检查点开始之前有六个文件，先前的 REDO 点包含在文件 WAL_3 中，并且 PostgreSQL 估计将保留五个文件。在这种情况下，WAL_1 将重命名为 WAL_7 以进行回收，而 WAL_2 将被删除。

4b6044876914c5ea5aa7be4c6c63cc58.png

PostgreSQL中的WAL段文件管理

13. PostgreSQL 的预写日志记录(WAL)示例

步骤 1：

ramp=# SELECT datname, oid FROM pg_database WHERE datname = 'postgres';
datname  |  oid  
postgres | 15709
Note the database OID, i.e. 15709

步骤 2：

ramp=# SELECT oid,* from pg_tablespace;

oid  |  spcname   | spcowner | spcacl | spcoptions 
1663 | pg_default |       10 |        | 
1664 | pg_global  |       10 |        | 

Note the table space OID, i.e. 1663

步骤 3：

ramp=# SELECT pg_current_wal_lsn();

pg_current_wal_lsn 

0/1C420B8

Note the LSN, i.e. 0/1C420B8

步骤 4：

ramp=# CREATE TABLE abc(a VARCHAR(10));

步骤 5：

ramp=# SELECT pg_relation_filepath('abc');
pg_relation_filepath 
base/15709/16384
Note the relation filename, base/15709/16384

步骤 6：

在./pg_waldump --path=/tmp/sd/pg_wal –start=0/1C420B8处查看文件的内容

使用步骤 3 中所述的起始 LSN。

注意，WAL 包含创建物理文件的指令

15709→ 数据库 postgres→ 在步骤 1 中记录

16384→ 表 abc→ 步骤 5 中已记录

rmgrLen(rec/tot)txlsnprevdesc
XLOG30/ 3000/01C420B80/01C42080NEXTOID 24576
Storage42/ 4200/01C420D80/01C420B8CREATE base/15709/16384
Heap203/20312160/01C421080/01C420D8INSERT off 2, blkref #0: rel 1663/15709/1247 blk 0
Btree64/ 6412160/01C421D80/01C42108INSERT_LEAF off 298, blkref #0: rel 1663/15709/2703 blk 2
Btree64/ 6412160/01C422180/01C421D8INSERT_LEAF off 7, blkref #0: rel 1663/15709/2704 blk 5
Heap80/ 8012160/01C422580/01C42218INSERT off 30, blkref #0: rel 1663/15709/2608 blk 9
Btree72/ 7212160/01C422A80/01C42258INSERT_LEAF off 243, blkref #0: rel 1663/15709/2673 blk 51
Btree72/ 7212160/01C422F00/01C422A8INSERT_LEAF off 170, blkref #0: rel 1663/15709/2674 blk 61
Heap203/20312160/01C423380/01C422F0INSERT off 6, blkref #0: rel 1663/15709/1247 blk 1
Btree64/6412160/01C424080/01C42338INSERT_LEAF off 298, blkref #0: rel 1663/15709/2703 blk 2
Btree72/ 7212160/01C424480/01C42408INSERT_LEAF off 3, blkref #0: rel 1663/15709/2704 blk 1
Heap80/ 8012160/01C424900/01C42448INSERT off 36, blkref #0: rel 1663/15709/2608 blk 9
Btree72/ 7212160/01C424E00/01C42490INSERT_LEAF off 243, blkref #0: rel 1663/15709/2673 blk 51
Btree72/ 7212160/01C425280/01C424E0INSERT_LEAF off 97, blkref #0: rel 1663/15709/2674 blk 57
Heap199/19912160/01C425700/01C42528INSERT off 2, blkref #0: rel 1663/15709/1259 blk 0
Btree64/ 6412160/01C426380/01C42570INSERT_LEAF off 257, blkref #0: rel 1663/15709/2662 blk 2
Btree64/ 6412160/01C426780/01C42638INSERT_LEAF off 8, blkref #0: rel 1663/15709/2663 blk 1
Btree64/ 6412160/01C426B80/01C42678INSERT_LEAF off 217, blkref #0: rel 1663/15709/3455 blk 5
Heap171/17112160/01C426F80/01C426B8INSERT off 53, blkref #0: rel 1663/15709/1249 blk 16
Btree64/ 6412160/01C427A80/01C426F8INSERT_LEAF off 185, blkref #0: rel 1663/15709/2658 blk 25
Btree64/ 6412160/01C427E80/01C427A8INSERT_LEAF off 194, blkref #0: rel 1663/15709/2659 blk 16
Heap171/17112160/01C428280/01C427E8INSERT off 54, blkref #0: rel 1663/15709/1249 blk 16
Btree72/ 7212160/01C428D80/01C42828INSERT_LEAF off 186, blkref #0: rel 1663/15709/2658 blk 25
Btree64/ 6412160/01C429200/01C428D8INSERT_LEAF off 194, blkref #0: rel 1663/15709/2659 blk 16
Heap171/17112160/01C429600/01C42920INSERT off 55, blkref #0: rel 1663/15709/1249 blk 16
Btree72/ 7212160/01C42A100/01C42960INSERT_LEAF off 187, blkref #0: rel 1663/15709/2658 blk 25
Btree64/ 6412160/01C42A580/01C42A10INSERT_LEAF off 194, blkref #0: rel 1663/15709/2659 blk 16
Heap171/17112160/01C42A980/01C42A58INSERT off 1, blkref #0: rel 1663/15709/1249 blk 17
Btree72/ 7212160/01C42B480/01C42A98INSERT_LEAF off 186, blkref #0: rel 1663/15709/2658 blk 25
Btree64/ 6412160/01C42B900/01C42B48INSERT_LEAF off 194, blkref #0: rel 1663/15709/2659 blk 16
Heap171/17112160/01C42BD00/01C42B90INSERT off 3, blkref #0: rel 1663/15709/1249 blk 17
Btree72/ 7212160/01C42C800/01C42BD0INSERT_LEAF off 188, blkref #0: rel 1663/15709/2658 blk 25
Btree64/ 6412160/01C42CC80/01C42C80INSERT_LEAF off 194, blkref #0: rel 1663/15709/2659 blk 16
Heap171/17112160/01C42D080/01C42CC8INSERT off 5, blkref #0: rel 1663/15709/1249 blk 17
Btree72/ 7212160/01C42DB80/01C42D08INSERT_LEAF off 186, blkref #0: rel 1663/15709/2658 blk 25
Btree64/ 6412160/01C42E000/01C42DB8INSERT_LEAF off 194, blkref #0: rel 1663/15709/2659 blk 16
Heap171/17112160/01C42E400/01C42E00INSERT off 30, blkref #0: rel 1663/15709/1249 blk 32
Btree72/ 7212160/01C42EF00/01C42E40INSERT_LEAF off 189, blkref #0: rel 1663/15709/2658 blk 25
Btree64/ 6412160/01C42F380/01C42EF0INSERT_LEAF off 194, blkref #0: rel 1663/15709/2659 blk 16
Heap80/ 8012160/01C42F780/01C42F38INSERT off 25, blkref #0: rel 1663/15709/2608 blk 11
Btree72/ 7212160/01C42FC80/01C42F78INSERT_LEAF off 131, blkref #0: rel 1663/15709/2673 blk 44
Btree72/ 7212160/01C430100/01C42FC8INSERT_LEAF off 66, blkref #0: rel 1663/15709/2674 blk 46
Standby42/ 4212160/01C430580/01C43010LOCK xid 1216 db 15709 rel 16384
Txn405/40512160/01C430880/01C43058COMMIT 2019-03-04 07:42:23.165514 EST;... snapshot 2608 relcache 16384
Standby50/ 5000/01C432200/01C43088RUNNING_XACTS nextXid 1217 latestCompletedXid 1216 oldestRunningXid 1217

步骤 7：

ramp=# SELECT pg_current_wal_lsn();
pg_current_wal_lsn 
0/1C43258
(1 row)

步骤 8：

ramp=# INSERT INTO abc VALUES('pkn');

步骤 9：

./pg_waldump --path=/tmp/sd/pg_wal --start=0/1C43258

使用步骤 7 中的起始 LSN。

1663→pg_default 表空间 → 在步骤 2 中记录

15709→ 数据库 postgres→ 在步骤 1 中记录

16384→ 表 abc→ 步骤 5 中已记录

rmgrLen (rec/tot)txlsnprevdesc
Heap59/5912170/01C432580/01C43220INSERT+INIT off 1, blkref #0: rel 1663/15709/16384 blk 0
Transaction34/3412170/01C432980/01C43258COMMIT 2019-03-04 07:43:45.887511 EST
Standby54/5400/01C432C00/01C43298RUNNING_XACTS nextXid 1218 latestCompletedXid 1216 oldestRunningXid 1217; 1 xacts: 1217

步骤 10：

ramp=# SELECT pg_current_wal_lsn();
pg_current_wal_lsn 
0/1C432F8

(1 row)

步骤 11：

ramp=# INSERT INTO abc VALUES('ujy');

步骤 12：

./pg_waldump --path=/tmp/sd/pg_wal –start=0/1C432F8

使用从步骤 10 开始的 LSN。

rmgrLen (rec/tot)txlsnprevdesc
Heap59/5912180/01C432F80/01C432C0INSERT off 2, blkref #0: rel 1663/15709/16384 blk 0
Transaction34/3412180/01C433380/01C432F8COMMIT 2019-03-04 07:44:25.449151 EST
Standby50/5000/01C433600/01C43338RUNNING_XACTS nextXid 1219 latestCompletedXid 1218 oldestRunningXid 1219

步骤 13：检查 WAL 段文件中的实际元组。

Offset  | Hex Bytes| ASCII chars    |

00000060 | 3b 00 00 00 c3 04 00 00  28 00 40 02 00 00 00 00  |;.......(.@.....|

00000070 | 00 0a 00 00 ec 28 75 6e  00 20 0a 00 7f 06 00 00  |.....(un. ......|

00000080 | 5d 3d 00 00 00 40 00 00  00 00 00 00 ff 03 01 00  |]=...@..........|

00000090 | 02 08 18 00 09 70 6b 6e  03 00 00 00 00 00 00 00  |.....pkn........|

000000a0 | 22 00 00 00 c3 04 00 00  60 00 40 02 00 00 00 00  |".......`.@.....|
000000b0 | 00 01 00 00 dd 4c 87 04  ff 08 e4 73 44 e7 41 26  |.....L.....sD.A&|
000000c0 | 02 00 00 00 00 00 00 00  32 00 00 00 00 00 00 00  |........2.......|
000000d0 | a0 00 40 02 00 00 00 00  10 08 00 00 9e 01 36 88  |..@...........6.|
000000e0 | ff 18 00 00 00 00 00 00  00 00 00 03 00 00 c4 04  |................|
000000f0 | 00 00 c4 04 00 00 c3 04  00 00 00 00 00 00 00 00  |................|
00000100 | 3b 00 00 00 c4 04 00 00  c8 00 40 02 00 00 00 00  |;.........@.....|
00000110 | 00 0a 00 00 33 df b4 71  00 20 0a 00 7f 06 00 00  |....3..q. ......|
00000120 | 5d 3d 00 00 00 40 00 00  00 00 00 00 ff 03 01 00  |]=...@..........|
00000130 | 02 08 18 00 09 75 6a 79  04 00 00 00 00 00 00 00  |.....ujy........|
00000140 | 22 00 00 00 c4 04 00 00  00 01 40 02 00 00 00 00  |".........@.....|

00000150 | 00 01 00 00 96 2e 96 a6  ff 08 d8 f3 79 ed 41 26  |............y.A&|

00000160 | 02 00 00 00 00 00 00 00  32 00 00 00 00 00 00 00  |........2.......|

00000170 | 40 01 40 02 00 00 00 00  10 08 00 00 eb 6b 95 36  |@.@..........k.6|

00000180 | ff 18 00 00 00 00 00 00  00 00 00 03 00 00 c5 04  |................|

00000190 | 00 00 c5 04 00 00 c4 04  00 00 00 00 00 00 00 00  |................|

000001a0 | 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

14. PostgreSQL 中基于 WAL 的复制选项是什么？

  • 连续的 WAL 归档
  • 基于日志传送的复制-文件级别
  • 基于日志传送的复制-块级别

14.1 连续 WAL 归档

将生成的 WAL 文件复制到 pg_wal 子目录以外的任何位置以进行存档的过程称为 WAL 归档。每次生成 WAL 文件时，PostgreSQL 都会调用用户提供的脚本进行归档。该脚本可以使用 scp 命令将文件复制到一个或多个位置。该位置可以是 NFS 挂载。存档后，WAL 段文件可用于在任何指定的时间点恢复数据库。

14.2 基于日志传送的复制-文件级别

为了通过重放 WAL 文件来创建另一个备用服务器，将日志文件复制到另一个 PostgreSQL 服务器称为日志传送。该备用服务器配置为处于恢复模式，其唯一目的是在任何新的 WAL 文件到达时应用它们。然后，第二台服务器(也称为备用服务器)成为主 PostgreSQL 服务器的热备份。备用数据库还可以配置为只读副本，在该副本数据库中还可以提供只读查询。这称为热备用。

14.3 基于日志传送的复制-块级别

流复制改善了日志传送过程。无需等待 WAL 切换，而是在记录生成时发送记录，从而减少了复制延迟。另一个改进是备用服务器将使用复制协议通过网络连接到主服务器。然后，主服务器可以直接通过此连接发送 WAL 记录，而不必依赖最终用户提供的脚本。

14.4 主服务器应保留 WAL 段文件多长时间？

如果没有任何流复制客户端，则在存档脚本报告成功后，如果崩溃恢复不需要它们，则服务器可以丢弃(回收)WAL 段文件。

但是，备用客户端的存在会带来一个问题：只要最慢的备用客户端需要 WAL 文件，服务器就需要保留它们。例如，如果备用数据库被关闭了一会儿，然后又恢复在线状态并向主要数据库请求主要数据库不再具有的 WAL 文件，则复制将失败，并显示类似以下错误：

ERROR: requested WAL segment 00000001000000010000002D has already been removed

错误：请求的 WAL 段 00000001000000010000002D 已被删除

因此，主服务器应跟踪备用数据库的距离，而不是删除(回收)任何备用数据库仍需要的 WAL 文件。此功能是通过复制插槽提供的。

每个复制插槽都有一个名称，用于标识该插槽。每个插槽都与：

  1. 插槽的使用者需要的最旧的 WAL 段文件。在检查点期间，不会删除(回收)比此更新的 WAL 段文件。
  2. 插槽的使用者需要保留的最早的交易 ID。真空不会删除任何比此最近的事务所需的行。

15.基于日志传送的复制

15.1 物理流复制

40ae2b7a9b86c0e450bd51821564fd85.png

PostgreSQL中的物理流复制

PostgreSQL 数据库中的物理流复制是基于 WAL 的数据复制。在流复制中，备用服务器连接到主服务器，并使用复制协议接收 WAL 记录。

物理流复制的优点是什么？
  • 备用服务器无需等待 WAL 文件填满，从而改善了复制滞后。
  • 删除了对用户提供的脚本和服务器之间的中间共享存储的依赖。

16. PostgreSQL 中的 WAL 发送者和 WAL 接收者是什么？

在备用服务器上运行的名为WAL Receiver的进程使用 recovery.conf 的primary_conninfo参数中提供的连接详细信息，并使用 TCP/IP 连接连接到主服务器。

WAL Sender是在主服务器上运行的另一个进程，负责将 WAL 记录在生成时发送到备用服务器。WAL 接收器将 WAL 记录保存在 WAL 中，就好像它们是由本地连接的客户端的客户端活动生成的一样。一旦 WAL 记录到达 WAL 段文件，备用服务器就会不断重放 WAL，以便备用数据库和主数据库是最新的。

16.1 WAL 流协议详细信息

7987585f26aa307cfe0f6a1985729304.png

PostgreSQL中的WAL流协议详细信息

17. PostgreSQL 复制和故障转移设置

该设置包括两台通过 LAN 连接的 CentOS 7 计算机，在该计算机上安装了 PostgreSQL 版本 10.7。

17.1 使用 WAL 流配置 PostgreSQL 复制

**步骤 1：**在两台计算机上禁用并停止防火墙：

sudo firewall-cmd
sudo systemctl stop firewalld
sudo systemctl disable firewalld
sudo systemctl mask

**步骤 2：**在主服务器上，允许复制连接和来自同一网络的连接。修改 pg_hba.conf：

Local  all           all                       md5
host   all           all   172.16.214.167/24   md5
host   all           all   ::1/128             md5
local  replication   all                       md5
host   replication   all   172.16.214.167/24   md5
host   replication   all   ::1/128             md5

**步骤 3：**在主服务器上，编辑 postgresql.conf 以修改以下参数：

max_wal_senders = 10
wal_level = replica
max_replication_slots = 10
synchronous_commit = on
synchronous_standby_names = '*'
listen_addresses = '*'

**步骤 4：**启动主服务器：

./postgres -D ../pr_data -p 5432

步骤 5：进行基本备份以引导备用服务器：

./pg_basebackup --pgdata=/tmp/sb_data/ \
--format=p --write-recovery-conf \
--checkpoint=fast --label=mffb \
--progress --verbose \
--host=172.16.214.167 --port=5432 \
--username=postgres

**步骤 6：**检查基本备份标签文件：

START WAL LOCATION: 0/2000028 (file 000000010000000000000002)
CHECKPOINT LOCATION: 0/2000060
BACKUP METHOD: streamed
BACKUP FROM: master
START TIME: 2019-02-24 05:25:30 EST
LABEL: mffb

**步骤 7：**在基本备份中，在 recovery.conf 中添加以下行：

primary_slot_name = 'node_a_slot'

**步骤 8：**检查/tmp/sb_data/recovery.conf 文件

standby_mode = 'on'
primary_conninfo = 'user=enterprisedb 
password=abc123 
host=172.16.214.167 
port=5432 
sslmode=prefer 
sslcompression=1 
krbsrvname=postgres 
target_session_attrs=any'
primary_slot_name = 'node_a_slot'

**步骤 9：**连接到主服务器并发出以下命令：

edb=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
slot_name  | xlog_position 
node_a_slot | 
(1 row)

edb=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
slot_name  | slot_type | active 
node_a_slot | physical  | f
(1 row)

**步骤 10：**将基本备份转移到备用服务器：

scp /tmp/sb_data.tar.gz abbas@172.16.214.166:/tmp
sudo mv /tmp/sb_data /opt/PostgreSQL/10/
sudo chown postgres:postgres /opt/PostgreSQL/10/sb_data/
sudo chown -R postgres:postgres /opt/PostgreSQL/10/sb_data/
sudo chmod 700 /opt/PostgreSQL/10/sb_data/

**步骤 11：**启动备用服务器：

./postgres -D ../sb_data/ -p 5432

主服务器将在日志中显示此内容：

LOG: standby "walreceiver" is now a synchronous standby with priority 1

日志：备用“ walreceiver”现在是优先级为 1 的同步备用

待机状态将显示：

LOG:  database system was interrupted; last known up at 2018-10-24 15:49:55
LOG:  entering standby mode
LOG:  redo starts at 0/3000028
LOG:  consistent recovery state reached at 0/30000F8
LOG:  started streaming WAL from primary at 0/4000000 on timeline 1
LOG：数据库系统被中断；最后知道于2018-10-24 15:49:55
日志：进入待机模式
日志：重做从0/3000028开始
日志：一致的恢复状态达到0 / 30000F8
日志：在时间轴1上从0/4000000开始从主要流式传输WAL

步骤 12：连接到主服务器并发出一些简单命令：

create table abc(a int, b varchar(250));
insert into abc values(1,'One');
insert into abc values(2,'Two');
insert into abc values(3,'Three');

步骤 13：检查副本上的数据：

postgres=# select * from abc;
a |   b   
1 | One
2 | Two
3 | Three
(3 rows)

18. PostgreSQL 手动故障转移步骤是什么？

步骤 1：使主服务器崩溃。

步骤 2：通过在备用服务器上运行以下命令来升级备用服务器：

$ ./pg_ctl promote -D ../sb_data/
server promoting

步骤 3：连接到升级后的备用服务器并插入一行：

edb=# insert into abc values(4,'Four');

该插入工作良好的事实意味着备用服务器(否则是只读服务器)已被提升为新的主服务器。

19.如何在 PostgreSQL 中自动执行故障转移和复制

使用 EDB Postgres 故障转移管理器(EFM)可以轻松设置自动故障转移。在每个主节点和备用节点上下载并安装 EFM[8]之后，您可以创建一个EFM 群集[9]，该群集[10]由一个主节点，一个或多个备用节点以及一个可选的 Witness 节点组成，该节点在发生故障时确认断言。

EFM 持续监视系统运行状况，并根据系统事件发送电子邮件警报。发生故障时，它将自动切换到最新的备用服务器，并重新配置所有其他备用服务器以识别新的主服务器。它还重新配置负载均衡器(例如 pgPool)，并防止“分裂大脑”(当两个节点各自认为它们是主要节点时)发生。

20. PostgreSQL 的 repmgr

另一个开源工具是 repmgr(复制管理器)，它也管理 PostgreSQL 集群的复制和故障转移。EDB 提供了有关安装和运行 PostgreSQL repmgr的深入教程[11]。如果配置正确，则 repmgr 可以检测主服务器何时发生故障并执行自动故障转移。

参考资料

[1]

PostgreSQL Replication and Automatic Failover Tutorial: https://www.enterprisedb.com/postgres-tutorials/postgresql-replication-and-automatic-failover-tutorial

[2]

可能需要一些时间: http://www.postgres.cn/docs/12/warm-standby-failover.html

[3]

EDB Postgres Failover Manager: https://www.enterprisedb.com/products/postgresql-automatic-failover-manager-cluster-high-availability

[4]

快速，自动的故障检测: https://www.enterprisedb.com/blog/edb-postgres-automatic-failover-detection-high-availabile-clusters

[5]

关键要求: https://www.enterprisedb.com/blog/what-does-database-high-availability-really-mean

[6]

EDB Postgres Replication Server: https://www.enterprisedb.com/products/postgresql-replication-server-single-or-multi-master-mode

[7]

配置其复制设置: https://www.enterprisedb.com/blog/why-use-synchronous-replication-in-postgresql-configure-streaming-replication-wal

[8]

下载并安装 EFM: https://www.enterprisedb.com/edb-docs/p/edb-postgres-failover-manager

[9]

EFM 群集: https://www.enterprisedb.com/edb-docs/d/edb-postgres-failover-manager/installation-getting-started/quick-start/3.10/index.html

[10]

群集: https://www.enterprisedb.com/edb-docs/d/edb-postgres-failover-manager/installation-getting-started/quick-start/3.10/index.html

[11]

的深入教程: https://www.enterprisedb.com/postgres-tutorials/how-implement-repmgr-postgresql-automatic-failover

weixin_39707536
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
流复制环境中重启主库后报错WAL被removed的解决方法
lk的窝
09-12 3113
流复制环境中重启主库后报错WAL被removed的解决方法 [postgres@db1 testspace]$ /usr/local/pgsql/bin/pg_ctl -D ./pgdb -o "--ssha_role=primary" start server starting [postgres@db1 testspace]$ LOG:  database system was shut
PostgreSQL(一)PostgreSQL一主二从集群部署
weixin_65635758的博客
10-19 4684
PostgreSQL(一)PostgreSQL一主二从集群部署
Windows中安装的PostgreSQL 数据库如何重启
最新发布
舒一笑的博客
05-06 949
如果你知道PostgreSQL的安装目录，可以使用。
Centos7部署PostgreSQL 12集群（主备）
sunny05296的博客
10-27 7755
Centos7部署PostgreSQL 12集群（主备） 关于备份模式 常规的备份模式有三种：热备、冷备和双活。 热备：仅主节点承担用户的业务、提供数据库服务，在不关闭数据库服务（不停服）的情况下对主节点进行备份。 为了保证数据库服务的正常不间断运行，一般用两台机器作为数据库服务机器。其中一台用于实际数据库操作应用、提供数据库服务，而另外一台则实时从前者中获取数据以保持数据的一致性。 如果当前的主节点故障宕机，当前的备节点机器立马（人为手动触发或由配置自动触发）取代当前的主节点机器继续提...
linux postgres服务重启,PostgreSQL（Linux）安装、启动、停止、重启
weixin_31992389的博客
05-02 1645
If we don't already have PostgreSQL installed, we must install it.$ sudo apt-get install postgresqlThis command installs the PostgreSQL server and various other packages.$ sudo update-rc.d -f postgres...
【PostgreSQL启动，停止命令(重启)】
ChenJin_2的博客
10-12 1071
【PostgreSQL启动，停止命令(重启)】
PAF：PostgreSQL自动故障转移：基于Pacemaker和Corosync的Postgres的高可用性
02-05
"PAF：PostgreSQL自动故障转移"是一个解决方案，它利用Pacemaker和Corosync这两个工具来实现Postgres的高可用性。让我们深入探讨这个主题。 PostgreSQL是一种开源的对象关系型数据库管理系统（RDBMS），以其稳定性...
pg_timetable：pg_timetable：PostgreSQL高级调度
01-30
pg_timetable：PostgreSQL高级调度 pg_timetable是PostgreSQL高级作业调度程序，与cron等传统调度程序相比，具有许多优势。 它完全由数据库驱动，并提供了一些高级概念。 # ./pg_timetable Application Options: -...
pg_auto_failover：Postgres扩展和服务，用于自动故障转移和高可用性
02-05
pg_auto_failover是PostgreSQL扩展和服务，用于监视和管理Postgres集群的自动故障转移。 它针对简单性和正确性进行了优化，并支持Postgres 10和更高版本。 pg_auto_failover支持几种Postgres架构，并为您的...
PostgreSQL find_in_set 内核开发
03-20
博客：PostgreSQL的学习心得和知识总结（六十五）|关于PostgreSQL数据库 实现MySQL数据库find_in_set()函数 的实现方案
PostgreSQL 主从复制高可用集群搭建
06-20
在构建 PostgreSQL 高可用集群时，主从复制是一种常见的策略，它能够提供数据冗余和故障转移能力。本文将详细介绍如何在 PostgreSQL 16 beta 1 版本上搭建异步复制模式的主从集群。异步复制在性能上表现出色，但可能...
postgresql集群主备模式负载均衡故障转移恢复
07-26
postgresql9.5集群环境搭建，采用双机热备，pgpool做负载均衡和故障恢复转移，另外还有使用arcsde空间化postgres
postgreSQL服务重启
热门推荐
strut的博客
09-01 2万+
1. 查看postgresql进程： ps -ef|grep postgres 2. 查看psotgresql端口： netstat -npl | grep postgres 3.启停服务 su - postgres pg_ctl start #启动 pg_ctl stop #停止 pg_ctl restart #重启 4.返回第一步骤，通过查看进程是否存在来判断启停状态。 注意：如果命令不存在，请先配置环境变量或找到数据库bin目录./pg_ctl执行 ...
PostgreSQL重启恢复---Checkpoint&Redo
obvious__的博客
08-01 3288
Checkpoint&Redo 预备知识 《数据库基础—重做日志》 概述 前面的文档中，我们讨论了很多关于XLOG问题：XLOG如何组织？如何写入log buffer？log buffer如何落盘？现在我们来阐述XLOG的用处：当数据库意外发生宕机后，如何依据XLOG来做数据恢复？在《数据库基础—重做日志》中，我们阐述过数据库几种基于日志的恢复策略，其中提到undo\redo策略是现在应用最广泛的策略。而PostgreSQL也使用的这种策略。 依据undo\redo策略，我们在数据库重启恢复时，需
pg数据库（三）之重启pg库
weixin_55282974的博客
03-03 7169
执行 ps -ef | grep postgres 查看进程的情况得到： pgsql 的位置 /usr/pgsql-11/bin/postgres 数据存储在 /var/lib/pgsql/data
【postgresql 基础入门】数据库服务的管理，启动、停止、状态查看、配置加载、重启都在这里
一个追逐梦想的码农
09-03 9926
postgresql 数据库是一款通用的关系型数据，在开源数据库中能与商业数据媲美，在业界也越来越流行。因为是开源数据库，不仅公开源码，还有很多使用案例，好用的插件，所以它的慢慢变成了数据库的先驱和标准，通过postgresql可以很好从使用到原理，彻底搞懂；如果是学习编程，也可以学到丰富的编程知识，数据结构，编程技巧，它里面还有很多精妙的架构设计，分层思想，可以灵活定制的思想。
PostgreSQL常见问题及命令
m0_55877125的博客
04-10 3669
数据库
pgsql误删除pg_wal文件后，服务启动失败
weixin_44911287的博客
07-20 1411
pgsql误删pg_wal 解决办法
PostgreSQL重启恢复---Log Buffer
obvious__的博客
08-01 1389
Log Buffer 预备知识 《PostgreSQL重启恢复—XLOG 1.0》 《PostgreSQL重启恢复—XLOG 2.0》 概述 在前面的文章中，我们解决了对于数据页的insert操作，需要组装一个怎样的XLOG以及XLOG写入log buffer的流程。接下来我们需要来更加深入的了解下log buffer，了解他的组织结构，了解log buffer的作用，更重要的是要了解XLOG如何落盘。还记得WAL的两大准则么： XLOG落盘之后，对应的数据才能落盘。 一个事务相关的所有XLOG都落盘之后
pg高可用之repmgr篇
02-21
- repmgrd守护程序：监控集群状态，检测复制故障，触发故障转移，并可以执行自定义脚本发送告警邮件 2、PostgreSQL+repmgr高可用集群安装部署 部署过程涉及以下步骤： - 部署规划：确定主、备节点的配置和网络设置 ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值