4.2.BDR 特定配置变量

BDR 扩展公开通过 PostgreSQL 的通常配置机制的配置参数的数目。你可以将这些相同的方式设置为通过 postgresql.conf 或使用改变系统的任何其他设置。一些变量也可以设置每用户、 每个数据库或每个会话，但大多数都需要一个服务器重新加载或一个完整的服务器重新启动才能生效。

bdr.conflict_logging_include_tuples （布尔值）

日志记录 BDR 元组时的整个元组。需要服务器重新加载才能生效。 bdr.log_conflicts_to_table （布尔值）

此布尔选项控制是否检测到的 BDR 冲突得到登录到 bdr.bdr_conflict_history 表。查看冲突日志记录的详细信息。需要服务器重新加载才能生效。 bdr.synchronous_commit （布尔值）

BDR 的 synchronous_commit 设置是否适用工人启用此布尔选项控制。它将默认为关闭。如果设置为 off，BDR 适用工人将执行异步提交，允许 PostgreSQL 大大提高吞吐量。

它总是很安全设置在它永远不会导致事务不会重播的感觉。如果这是重要节点尽快为复制数据，所以一个节点丢失造成损失最小的是仍然只在该节点的数据，您应该将此设置为上并配置 PostgreSQL 的同步复制。

注意︰ 使用同步提交和同步复制不会阻止应用冲突过程中出现的多主机使用的 BDR。那里是仍然没有锁定节点和没有全球快照管理之间所以不同节点上的并发事务仍可以更改同一个元组。请参见概述。

启用 PostgreSQL 的同步复制，但离开 bdr.synchronous_commit 禁用不是一般的 adviseable。它将明显增加的时间直到交易证实已被复制。这是因为它只被报告为安全犯一旦沃尔玛刷新在接收方。 bdr.temp_dump_directory （字符串）

指定的路径到临时存储位置，可写的 postgres 用户，都需要有足够的存储空间来包含一个完整转储的潜在克隆的数据库。

在初始过去时通过逻辑拷贝过程中只使用此设置。它不使用 bdr_init_copy。 bdr.max_ddl_lock_delay （毫秒）

控件如何长 DDL 锁尝试可以等待并发的写事务提交或回滚强行中止他们之前回来。-1 （默认值） 使用 max_standby_streaming_delay 的值。可以设置与像 ' 10s 的时间单位。请参阅节 8.1.1。 bdr.ddl_lock_timeout （毫秒）

控件如何长 DDL 锁尝试可以等待获取锁。默认值-1 （默认值） 使用 lock_timeout 的值。可以设置与像 ' 10s 的时间单位。请参阅节 8.1.1。请注意，一旦获得 DDL 锁和 DDL 操作开始此计时器停止滴答作响;它并不会限制可能举行 DDL 锁，事务仅多长时间可以等待一个被收购的总工期。为了限制总体持续时间使用 statement_timeout。 bdr.permit_ddl_locking （布尔值）

允许运行 DDL 命令，获取全球的 DDL 锁的会话。在 DDL 锁上看到 DDL 复制的详细信息。将其设置为 off 以默认方式可以中断生产，意外的 DDL 被阻止。 bdr.trace_ddl_locks_level （布尔值）

重写默认调试日志级别为 BDR DDL 锁 （DDL 复制中使用），以便 DDL 锁相关消息相反发出调试日志级别。这可以用于跟踪系统中的 DDL 锁定活动而无需为整个服务器配置非常冗长的 DEBUG1 或 DEBUG2 日志级别。

按升序排列的详细程度，设置是无，声明、 acquire_release、 同行和调试。在无级 DDL 锁消息只发出在 DEBUG1 和较低的服务器日志级别。语句添加日志输出，只要语句导致的尝试，企图获取 DDL 锁。acquire_release 还记录当实际获取的锁和它后来被释放，或者如果它被拒绝，并记录对等节点应用远程 DDL 时锁定。同行中添加有关 DDL 锁的对等节点之间谈判更多细节和调试部队一切 DDL 锁-相关级别日志记录。

更改生效在服务器上配置重新加载，重新启动计算机不是必需的。

另请参阅监测全球 DDL 锁。

4.2.1.不常见或内部的配置变量

bdr.default_apply_delay （整数）

默认设置为所有配置应用延迟没有显式配置的连接应用延迟。

这主要是用来模拟一个高延迟网络中一种低延迟测试环境。它要求服务器重新加载才能生效。 bdr.skip_ddl_locking （布尔值）

只会影响 BDR。防止采集的全球的 DDL 锁时执行 DDL 语句。