响应网站建设,惠济区城乡建设局网站,怎么成立网站,子网站怎么建设开头还是介绍一下群#xff0c;如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题#xff0c;有需求都可以加群群内有各大数据库行业大咖#xff0c;CTO#xff0c;可以解决你的问题。加群请联系 liuaustin3 #xff0c;在新加的朋友会分到2群#xff08;共… 开头还是介绍一下群如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题有需求都可以加群群内有各大数据库行业大咖CTO可以解决你的问题。加群请联系 liuaustin3 在新加的朋友会分到2群共1100人左右 1 2 3新人会进入3群 Postgres 16刚刚发布了测试版我对其中的新功能非常兴奋。该新功能允许从待命服务器进行逻辑复制用户可以 从只读的待命服务器创建逻辑解码 减轻主服务器的工作负载 采用新的方式为需要在多个系统之间进行数据同步或审核的应用程序提供高可用性 第二个相关且令人兴奋的新功能是在给定的待命服务器上的复制槽将持久化到将该待命服务器提升为主服务器。这意味着在主服务器故障并将待命服务器提升为主服务器时复制槽将持久存在并且之前的待命服务器订阅者不会受到影响。 这两个功能结合在一起极大地提高了PostgreSQL在处理大数据操作时的性能。适用于在物理位置之间移动数据的应用程序以及进行数据仓库、分析、数据集成和业务智能的人员。我将演示一个示例模式和数据库设置并提供一些用于从待命服务器创建逻辑复制的示例设置和代码。 Background on replication 在高层次上PostgreSQL支持两种主要类型的复制流式/物理复制和逻辑复制。Write-Ahead LogWAL可以通过连接流式传输整个物理文件集并表示磁盘上完整的数据库。逻辑复制提供了一种更精细的方法您可以指定要复制到远程服务器的单个数据库对象如表甚至特定行。您可以在《Data To Go: Postgres Logical Replication》中了解更多关于逻辑复制基础知识。 PostgreSQL通过对主服务器进行基本备份并持续应用主服务器上的所有更改来创建待命服务器。热待命服务器是可以升级为主服务器的待命服务器。PostgreSQL将修改保存在Write-Ahead LogWAL记录中并将其从主服务器复制到待命服务器。配置参数hot_standby_feedback可以防止主服务器过早删除目录行以便待命服务器可以使用它们。 逻辑解码从待命服务器开始于2018年。这个过程涉及了许多复杂的细节需要大量的努力。不容忽视的是这个过程已经经历了5年的发展我们非常兴奋地看到它在Postgres 16中发布。 举个例子我们有三个不同的PostgreSQL服务器管理着一家全球物流公司在全球各地分布的仓库的库存信息。在主服务器上我们有仓库和库存信息备用服务器是一个物理副本高可用性机器还有一个用于报告目的的第三个服务器它正在获取特定的更改。 在您的主实例中您需要具有复制特权的用户。对于这个例子我创建了一个用户将更改流向备用服务器另一个用户将更改发布给订阅者。 CREATE ROLE repuser WITH REPLICATION LOGIN ENCRYPTED PASSWORD somestrongpassword;
CREATE ROLE pubuser WITH REPLICATION LOGIN ENCRYPTED PASSWORD differentstrongpassword; 接下来我创建一个物理插槽来将更改从主服务器复制到备用服务器。严格来说这并不是必需的但在实践中真的是必要的。如果没有物理复制插槽任一节点的重启或连接丢失都会中断复制过程 SELECT pg_create_physical_replication_slot(hot_standby_1); 我们只关心Salt Lake City仓库的库存其代码为SLC。在主服务器上我们将创建一个名为inventory_requirements的发布用于涉及库存表的表还有一个名为inventory_slc_pub的发布 CREATE PUBLICATION inventory_requirements_pub
FOR TABLE regions, countries, warehouses, products;CREATE PUBLICATION inventory_slc_pub
FOR TABLE inventory WHERE (warehouse SLC1);GRANT SELECT ON TABLE regions, countries, warehouses, products, inventory
TO pubuser; 现在我可以创建我的备用实例。我们将使用pgBackRest也可以使用pg_basebackup来初始化备用实例。一旦你的备用数据目录已经恢复你将需要编辑它的postgresql.conf并确保它有一些参数如此文档中所述tream standby about # queries currently executing on this standby
hot_standby_feedback on# Use the physical replication slot we created previously
primary_slot_name hot_standby_1hot_standby on
archive_mode on# If level is changed to below logical, slots will be dropped
wal_level logical# standby streams changes from the primary
primary_conn_info host127.0.0.1 port5432 userrepuser passwordsomestrongpasswordmax_wal_senders 10 # max number of walsender processes
max_replication_slots 10 # max number of replication slots# If an upstream standby server is promoted to become the new
# primary, downstream servers will continue to stream from
# the new primary
recovery_target_timeline latest 连接到该备用实例将确认它处于只读模式 SELECT pg_is_in_recovery();pg_is_in_recovery
-------------------t 此时我们已经具有一个通过物理插槽从主实例复制到一个设置了hot_standby_feedback on的工作备用实例。命名为inventory_requirements_pub和inventory_slc_pub的发布。 从standby 中进行逻辑复制 现在我们可以转到我们的报告 PostgreSQL 实例并从备用实例订阅更改。在 PostgreSQL 16 之前此操作将失败。 逻辑复制的一个主要优点是您可以从不同版本的 PostgreSQL 服务器订阅更改这在处理使用不同版本的 PostgreSQL 的应用程序时为您提供了很大的灵活性。 CREATE SUBSCRIPTION inventory_requirements_sub
CONNECTION dbnameinventory host127.0.0.1 port5434 userpubuser passworddifferentstrongpassword
PUBLICATION inventory_requirements_pub;CREATE SUBSCRIPTION inventory_slc_sub
CONNECTION dbnameinventory host127.0.0.1 port5434 userpubuser passworddifferentstrongpassword
PUBLICATION inventory_slc_pub; 如果您的主服务器处于空闲状态此操作将挂起。这是因为备用实例正在等待来自主实例的信息。您可以通过在主实例上调用新函数pg_log_standby_snapshot()来加快创建此信息的速度。在此示例中我们会调用两次因为我们要创建两个订阅。 这将允许副本继续并生成如下的消息告诉我们在备用实例上创建了一个复制槽。在 PostgreSQL 16 中进行了改进 我们可以在备用实例上通过访问pg_stat_replication系统视图来验证这一点。 一旦更改被复制到备用实例它们将被下游复制到报告服务器并且我们将在那里看到这些更改。请注意只有SLC1的记录会被复制。 SELECT pg_log_standby_snapshot(); pg_log_standby_snapshot------------------------- 0/23000180 NOTICE: created replication slot inventory_requirements_sub on publisher
CREATE SUBSCRIPTION SELECT pid, application_name, state, sync_state FROM pg_stat_replication;pid | application_name | state | sync_state
----------------------------------------------------------23265 | inventory_slc_sub | streaming | async23251 | inventory_requirements_sub | streaming | async
(2 rows) SELECT * FROM inventory ORDER BY product_id;warehouse | product_id | quantity
---------------------------------SLC1 | 11 | 7SLC1 | 13 | 13SLC1 | 15 | 18SLC1 | 22 | 15SLC1 | 24 | 20 从这里如果需要的话我可以创建多个逻辑复制副本用于不同的位置和仓库。 正如我们之前所看到的当我们创建订阅连接到备用服务器时它会在不可写的备用服务器上创建复制槽。如果我们的主服务器发生灾难性故障备用服务器被提升为主服务器那么会发生什么情况呢不同的仓库会停止接收更改因为无法再从原本的备用服务器上获取更改它无法与新的主服务器进行通信。 在Postgres 16中复制槽在故障切换后是持久化的这非常令人兴奋我们之前的备用服务器被提升为主服务器复制槽的故障切换被保留下来我们的订阅者继续接收更改就好像什么都没有发生过一样 在我们的数据仓库报表PostgreSQL服务器上订阅了我们现在的主服务器对库存表的更改出现了而不需要采取任何其他操作确保您要逻辑复制的表设置了REPLICA IDENTITY SELECT pg_promote();pg_promote
------------t
(1 row)SELECT pg_is_in_recovery();pg_is_in_recovery
-------------------f
(1 row)UPDATE inventory SET quantity 2
WHERE warehouse SLC1 and product_id 11;
UPDATE 1 SELECT * FROM inventory WHERE warehouse SLC1 order by product_id;warehouse | product_id | quantity
---------------------------------SLC1 | 11 | 2SLC1 | 13 | 13SLC1 | 15 | 18SLC1 | 22 | 15
SLC1 | 24 | 20 随着越来越多的人选择使用Postgres作为数据库支持更丰富的数据流选项在Postgres中继续出现是有道理的。从几年前开始逻辑复制从备库中继续建立经过多次增强。由于PostgreSQL社区的出色工作在PG 16中备服用户将能够 创建逻辑复制槽 启动逻辑解码 订阅备库的更改 故障切换后持久化逻辑复制槽 备库将能够作为逻辑复制订阅者的源进行服务只需进行很少的更改 开启hot_standby_feedback on 使用物理复制槽从上游复制到备库 如果订阅者在向备库创建订阅时等待更改而发生停顿则在主服务器上运行pg_log_standby_snapshot()。这个新功能的文档仍在编写和改进中我将利用自己的所学来提交改进。
