人大金仓数据库KES RAC流复制的相关参数配置

关键字:

KES、流复制、参数配置、人大金仓

概述

流复制是一个功能强大的特性,这些强大的功能可以通过相关参数进行配置。

walsender进程相关GUC参数

(1)max_wal_senders

walsender进程的最大数量,默认为0。

(2)wal_sender_timeout

wal_sender等待备机连接相应的超时时间,walsender等待超过这个时间,将断开与备机的连接。

walreceiver进程相关GUC参数

(1)wal_receiver_status_interval

指定在后备机上的 redo 接收者进程向主服务器或上游后备机发送有关复制进度的信息的最小频度,它可以使用pg_stat_replication视图看到。 后备机将报告它已经写入的上一个预写式日志位置、它已经刷到磁盘的上一个位置以及它已经应用的最后一个位置。 这个参数的值是报告之间的最大时间量。每次写入或刷出位置改变时会发送状态更新,或者至少按这个参数的指定的频度发送。因此,应用位置可能比真实位置略微滞后。如果指定值时没有单位,则以秒为单位。默认值是 10 秒。将这个参数设置为零将完全禁用状态更新。这个参数只能在kingbase.conf文件中或在服务器命令行上设置。

(2)wal_receiver_timeout

中止处于非活动状态超过这个时间量的复制链接。这对于正在接收的后备服务器检测主服务器崩溃或网络断开有用。 如果指定值时没有单位,则以毫秒为单位。默认值是 60 秒。 这个参数只能在kingbase.conf文件中或者服务器命令行中设置。

startup进程相关GUC参数

(1)wal_retrieve_retry_interval

指定当从任何来源(流复制、本地pg_wal或者 WAL 归档)都得不到 WAL 数据时,后备服务器应该等待多久才去重新尝试获取 WAL 数据。 如果指定值时没有单位,则以毫秒为单位。默认值是 5 秒。 这个参数只能在kingbase.conf文件或者服务器命令行中设置。

(2) recovery_min_apply_delay

默认情况下,后备服务器会尽快恢复来自于发送服务器的 WAL 记录。有一份数据的延时拷贝是有用的,它能提供机会纠正数据丢失错误。 这个参数允许你将恢复延迟一段指定的时间量。

(3)recovery_target_timeline

指定恢复到一个特定的时间线中。该值可以是数字时间线 ID 或特殊值。值current沿着与执行基本备份时相同的时间线恢复。值latest将恢复到归档中能找到的最新的时间线,这在一个备用服务器中有用。latest是默认的。

主备链接相关GUC参数

(1)primary_conninfo

指定备用服务器用来连接发送服务器的连接字符串。

(2)primary_slot_name

有选择地指定通过流复制连接到发送服务器时使用一个现有的复制槽来控制上游节点上的资源移除。这个参数只能在服务器启动时被设置。如果没有设置primary_conninfo则这个设置无效。

流复制同步机制相关GUC参数

类似KES,synchronous_commit和synchronous_standby_names参数用于控制事务提交时redo日志的写入行为。不同的行为对应有不同的性能和数据持久性表现,以下是它们可能的取值及其意义:

(1)synchronous_standby_names非空(有同步备机)

  • synchronous_commit=off,事务提交操作会在redo日志被写入本地操作系统缓存后立即完成,不等待操作系统实际将这些redo日志写入磁盘。这可以显著提高事务提交的速度,尤其是在高负载情况下,但增加了数据丢失的风险。如果系统崩溃,最近的事务可能会丢失。
  • synchronous_commit=local,会导致事务提交只等待redo日志刷写到本地磁盘。在使用同步复制时这通常不是我们想要的效果,但是为了完整性,还是提供了这样一个选项。
  • synchronous_commit=remote_write,事务提交将等待redo日志被写入本地磁盘,并被复制到至少一个同步复制的备用服务器的操作系统缓存中,但不等待远程备用服务器将redo日志写入磁盘。这种设置足以保证数据在后备服务器的KingbaseRAC实例崩溃时得以保存,但是不能保证后备服务器遭受操作系统级别崩溃时数据能被保持,因为数据在后备机上可能未达到稳定存储。
  • synchronous_commit=on,这是默认设置,事务提交将等待redo日志被写入本地磁盘,并被复制到至少一个同步复制的备用服务器的磁盘中。这保证事务将不会被丢失,除非主服务器和所有同步后备都遭受到了数据库存储损坏的问题。
  • synchronous_commit=remote_apply,它要求在事务提交之前,redo日志不仅被发送并写入远程备用服务器的磁盘,而且必须被远程备用服务器应用到其数据库中。这确保了当事务在主服务器上提交后,更改在所有配置为同步的备用服务器上都已可查询。它提供了最强的数据持久性和一致性保证,但导致更高提交延迟。

(2)synchronous_standby_names为空(无同步备机)

synchronous_commit设置为on、remote_apply、remote_write和local都提供了同样的同步级别:事务提交只等待redo日志被刷写到本地磁盘。 synchronous_commit设置为off意义与前面相同。

具体选择何种redo日志写入流程控制参数取决于对数据持久性和系统性能的需求平衡。在处理极其重要的数据时,最好使用on或remote_apply,这样可以确保数据的安全性和一致性。然而,如果性能是一个重要考量,并且可以容忍在极端情况下丢失几秒钟的数据,可以选择off或local来优化事务提交的响应时间。

WAL日志保留相关GUC参数

(1)max_wal_size

两个检查点之间,XLOG日志可增长的最大尺寸,这是一个软限制。

(2)wal_keep_segments

指定在sys_wal目录中保留的过去redo日志文件最小数量,与复制槽一起决定sys_wal目录下最终必须保留的过去redo日志文件最小数量。以防备用服务器在进行流复制时需要。

hot_standby相关GUC参数

(1)hot_standby

指定在恢复期间,你是否能够连接并运行查询,默认值是on。这个参数只能在服务器启动时设置。它只在归档恢复期间或后备机模式下才有效。

(2)max_standby_streaming_delay

当热后备机处于活动状态时,这个参数决定取消那些与即将应用的 WAL 项冲突的后备机查询之前,后备服务器应该等待多久。如果指定值时没有单位,则以毫秒为单位。默认值是 30 秒。值 -1 允许后备机一直等到冲突查询结束。 这个参数只能在kingbase.conf文件中或在服务器命令行上设置。

(3)hot_standby_feedback

指定一个热后备机是否将会向主服务器或上游后备机发送有关于后备机上当前正被执行的查询的反馈。这个参数可以被用来排除由于记录清除导致的查询取消,但是可能导致在主服务器上用于某些负载的数据库膨胀。反馈消息的发送频度不会高于每个wal_receiver_status_interval周期发送一次。默认值是off。这个参数只能在kingbase.conf文件中或在服务器命令行上设置。

  • 12
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值