云栖社区Java、Redis、MongoDB运营小编,有意合作请联系钉钉:15810436147
32.5. 测试覆盖检查 PostgreSQL 源代码可以使用覆盖测试指令编译,因此可以检查哪些部分的代码被回归测试或任何其他测试套件所覆盖。当前使用 GCC 编译时支持该特性,并且需要gcov和lcov程序。
32.4. TAP Tests 各种测试,尤其是src/bin下的客户端程序测试, 都使用Perl TAP工具,并使用Perl测试程序prove运行。 你可以通过设置make变量PROVE_FLAGS 向prove传递命令行选项,例如: make -C src/bin check PROVE_FLAGS='--timer' 详见prove的手册页。
32.3. 变体比较文件 因为某些测试生来就会产生依赖环境的结果,我们提供了方法来指定替代的“预期”结果文件。每一个回归测试可以有多个比较文件来展示在不同平台上的可能结果。有两种独立的机制来决定为每一个测试使用哪个比较文件。
32.2. 测试评估 32.2.1. 错误消息差异 32.2.2. 区域差异 32.2.3. 日期和时间差异 32.2.4. 浮点差异 32.2.5. 行序差异 32.2.6. 栈深度不足 32.2.7. “失败”测试 32.2.8. 配置参数 一些正确安装的并且全功能的PostgreSQL安装可能会在这些回归测试中的某些上“失败”,其原因是平台相关的因素,例如可变浮点表示和 message wording。
32.1. 运行测试 32.1.1. 在一个临时安装上运行测试 32.1.2. 在一个现有安装上运行测试 32.1.3. 附加测试套件 32.1.4. 区域和编码 32.1.5. 额外测试 32.1.6. 测试热备 回归测试可以在一个已经安装并运行的服务器上运行,或者在编译树中的一个临时安装上运行。
第 31 章 逻辑复制 目录 31.1. 发布 31.2. 订阅 31.2.1. 复制槽管理 31.3. 冲突 31.4. 限制 31.5. 架构 31.5.1. 初始快照 31.6. 监控 31.7. 安全 31.8. 配置设置 31.9. 快速设置 逻辑复制是根据复制标识(通常是主键)复制数据对象及其更改的一种方法。
31.9. 快速设置 首先设置postgresql.conf中的配置选项: wal_level = logical 其他所需设置的默认值对于基本设置来说足够了。 需要调整pg_hba.conf以允许复制 (这里的值取决于你的实际网络配置和你想要用于连接的用户): host all repuser 0.
31.8. 配置设置 逻辑复制需要设置几个配置选项。 在发布者端,必须将wal_level设置为logical, 并且max_replication_slots必须至少设置为预期连接的订阅数量, 加上一些预留用于表同步。
31.7. 安全 用于复制链接的角色必须具有REPLICATION属性 (或者是超级用户)。该用户的访问权限必须在pg_hba.conf中配置。 用户必须具有数据库的CREATE权限才能创建发布。
31.6. 监控 由于逻辑复制基于与物理流式复制 类似的体系结构,因此发布节点上的监视与物理复制主节点的监视类似 (请参见第 26.2.5.2 节)。 有关订阅的监控信息可以在pg_stat_subscription 中看到。
31.5. 架构 31.5.1. 初始快照 逻辑复制首先复制发布者数据库上的数据快照。一旦完成, 发布者的变化就会实时发送给订阅者。订阅者按照发布者提交的顺序应用数据, 以确保任何单个订阅中的发布的事务一致性。
31.4. 限制 逻辑复制目前有以下限制或缺少的功能。 这些可能会在未来的版本中解决。 不复制数据库模式和DDL命令。初始模式可以使用pg_dump --schema-only 手动复制。后续的模式更改需要手动保持同步。
31.3. 冲突 逻辑复制的行为与普通的DML操作类似,因为即使订阅者节点本地更改了数据, 数据也将被更新。如果传入数据违反任何限制,复制将停止。 这被称为冲突。当复制UPDATE 或者DELETE操作时,丢失的数据不会产生冲突,这样的操作将被忽略。
31.2. 订阅 31.2.1. 复制槽管理 订阅是逻辑复制的下游端。定义订阅的节点被称为 订阅者。 订阅定义了与另一个数据库的连接以及它想要订阅的一组发布(一个或多个)。 订阅者数据库的行为与任何其他PostgreSQL实例的行为相同, 并且可以通过定义自己的发布来用作其他数据库的发布者。
31.1. 发布 可以在任何物理复制主机上定义发布。 定义发布的节点称为发布者。 发布是从一个表或一组表中生成的一组更改,也可能被描述为更改集或复制集。 每个发布只存在于一个数据库中。 发布与模式不同,不影响表格的访问方式。
第 30 章 可靠性和预写式日志 目录 30.1. 可靠性 30.2. 预写式日志(WAL) 30.3. 异步提交 30.4. WAL配置 30.5. WAL内部 本章解释预写式日志如何用于获得有效的、可靠的操作。
30.5. WAL内部 WAL是自动被启用的。除了做一些设置满足存放WAL日志的磁盘空间需求以及一些必要的调节以外(参阅第 30.4 节),对管理员没有什么其他要求。 当每个新记录被写入时,WAL记录被追加到WAL日志中。
30.4. WAL配置 有几个WAL相关的配置参数会影响数据库性能。本节将解释它们的使用。关于服务器配置参数的设置的一般信息请参考第 19 章。 检查点是在事务序列中的点,这种点保证被更新的堆和索引数据文件的所有信息在该检查点之前已被写入。
30.3. 异步提交 异步提交是一个允许事务能更快完成的选项,代价是在数据库崩溃时最近的事务会丢失。在很多应用中这是一个可接受的交换。 如前一节所述,事务提交通常是同步的:服务器等到事务的WAL记录被刷写到持久存储之后才向客户端返回成功指示。
30.2. 预写式日志(WAL) 预写式日志(WAL)是保证数据完整性的一种标准方法。对其详尽的描述几乎可以在所有(如果不是全部)有关事务处理的书中找到。简单来说,WAL的中心概念是数据文件(存储着表和索引)的修改必须在这些动作被日志记录之后才被写入,即在描述这些改变的日志记录被刷到持久存储以后。
30.1. 可靠性 可靠性是任何严肃的数据库系统的重要属性,PostgreSQL尽一切可能来保证可靠的操作。可靠的操作的一个方面是,被一个提交事务记录的所有数据应该被存储在一个非易失的区域, 这样就不会因为失去电力、操作系统失败以及硬件失败(当然,除了非易失区域自身失效之外)等原因导致的数据丢失。
第 29 章 监控磁盘使用 目录 29.1. 判断磁盘用量 29.2. 磁盘满失败 本章讨论如何监控PostgreSQL数据库系统的磁盘使用情况。 本文转自PostgreSQL中文社区,原文链接:第 29 章 监控磁盘使用
29.2. 磁盘满失败 一个数据库管理员最重要的磁盘监控任务就是确保磁盘不会写满。一个写满了的数据磁盘可能不会导致数据的崩溃,但它肯定会让系统变得不可用。如果保存 WAL 文件的磁盘变满,会发生数据库服务器致命错误并且可能发生关闭。
29.1. 判断磁盘用量 每个表都有一个主要的堆磁盘文件,大多数数据都存储在其中。如果一个表有着可能会很宽(尺寸大)的列, 则另外还有一个TOAST文件与这个表相关联, 它用于存储因为太宽而不能存储在主表里面的值(参阅第 66.2 节)。
第 28 章 监控数据库活动 目录 28.1. 标准 Unix 工具 28.2. 统计收集器 28.2.1. 统计收集配置 28.2.2. 查看统计信息 28.2.3. 统计函数 28.3. 查看锁 28.4. 进度报告 28.4.1. VACUUM进度报告 28.5. 动态追踪 28.5.1. 动态追踪的编译 28.5.2. 内建探针 28.5.3. 使用探针 28.5.4. 定义新探针 一个数据库管理员常常会疑惑,“系统现在正在做什么?”这一章会讨论如何搞清楚这个问题。
28.5. 动态追踪 28.5.1. 动态追踪的编译 28.5.2. 内建探针 28.5.3. 使用探针 28.5.4. 定义新探针 PostgreSQL提供了功能来支持数据库服务器的动态追踪。
28.4. 进度报告 28.4.1. VACUUM进度报告 PostgreSQL能够在命令执行期间报告某些命令的进度。目前,唯一支持 进度报告的命令是VACUUM。未来可能会添加更多命令支持。
28.3. 查看锁 监控数据库活动的另外一个有用的工具是pg_locks系统表。这样就允许数据库管理员查看在锁管理器里面未解决的锁的信息。例如,这个功能可以被用于: 查看当前所有未解决的锁、在一个特定数据库中的关系上所有的锁、在一个特定关系上所有的锁,或者由一个特定PostgreSQL会话持有的所有的锁。
28.2. 统计收集器 28.2.1. 统计收集配置 28.2.2. 查看统计信息 28.2.3. 统计函数 PostgreSQL的统计收集器是一个支持收集和报告服务器活动信息的子系统。 目前,这个收集器可以对表和索引的访问计数,计数可以按磁盘块和个体行来进行。
28.1. 标准 Unix 工具 在大部分 Unix 平台上,PostgreSQL会修改由ps报告的命令标题,这样个体服务器进程可以被标识。一个显示样例是 $ ps auxww | grep ^postgres postgres 15551 0.
第 27 章 恢复配置 目录 27.1. 归档恢复设置 27.2. 恢复目标设置 27.3. 后备服务器设置 这一章描述recovery.conf文件中可用的设置。它们只应用于恢复期。对于你希望执行的任意后续恢复,它们必须被重置。
27.3. 后备服务器设置 standby_mode (boolean) 指定是否将PostgreSQL服务器作为一个后备服务器启动。如果这个参数为on,当到达已归档 WAL 末尾时该服务器将不会停止恢复,但是将通过使用restore_command获得新的 WAL 段以及/或者通过使用primary_conninfo设置连接到主服务器来尝试继续恢复。
27.2. 恢复目标设置 默认情况下,恢复将会一直恢复到 WAL 日志的末尾。下面的参数可以被用来指定一个更早的停止点。在recovery_target、recovery_target_lsn、recovery_target_name、recovery_target_time和recovery_target_xid中,最多只能使用一个,如果在配置文件中使用了多个,将使用最后一个。
27.1. 归档恢复设置 restore_command (string) 用于获取 WAL 文件系列的一个已归档段的本地 shell 命令。这个参数是归档恢复所必需的,但是对于流复制是可选的。
第 26 章 高可用、负载均衡和复制 目录 26.1. 不同方案的比较 26.2. 日志传送后备服务器 26.2.1. 规划 26.2.2. 后备服务器操作 26.2.3. 为后备服务器准备主控机 26.
26.5. 热备 26.5.1. 用户概览 26.5.2. 处理查询冲突 26.5.3. 管理员概览 26.5.4. 热备参数参考 26.5.5. 警告 术语热备用来描述服务器处于归档恢复或后备模式时连接到服务器并运行只读查询的能力。
26.4. 日志传送的替代方法 26.4.1. 实现 26.4.2. 基于记录的日志传送 前一节描述的内建后备模式的一种替代方案是使用一个轮询归档位置的 restore_command。这是版本 8.4 及以下版本中唯一可用的选项。
26.3. 故障转移 如果主服务器失效,则后备服务器应该开始故障转移过程。 如果后备服务器失效,则不会有故障转移发生。如果后备服务器可以被重启 (即使晚一点),由于可重启恢复的优势,那么恢复处理也能被立即重启。
26.2. 日志传送后备服务器 26.2.1. 规划 26.2.2. 后备服务器操作 26.2.3. 为后备服务器准备主控机 26.2.4. 建立一个后备服务器 26.2.5. 流复制 26.2.6. 复制槽 26.2.7. 级联复制 26.2.8. 同步复制 26.2.9. 后备服务器中的持续归档 连续归档可以被用来创建一个高可用性(HA)集群配置, 其中有一个或多个后备服务器随时准备在主服务器失效时接管操作。
26.1. 不同方案的比较 共享磁盘故障转移 共享磁盘故障转移避免了只使用一份数据库拷贝带来的同步开销。 它使用一个由多个服务器共享的单一磁盘阵列。如果主数据库服务器失效, 后备服务器则可以挂载并启动数据库,就好像它从一次数据库崩溃中恢复过来了。
第 25 章 备份和恢复 目录 25.1. SQL转储 25.1.1. 从转储中恢复 25.1.2. 使用pg_dumpall 25.1.3. 处理大型数据库 25.2. 文件系统级别备份 25.3. 连续归档和时间点恢复(PITR) 25.3.1. 建立WAL归档 25.3.2. 制作一个基础备份 25.3.3. 使用低级API制作一个基础备份 25.3.4. 使用一个连续归档备份进行恢复 25.3.5. 时间线 25.3.6. 建议和例子 25.3.7. 警告 由于包含着有价值的数据,PostgreSQL数据库应当被定期地备份。
25.3. 连续归档和时间点恢复(PITR) 25.3.1. 建立WAL归档 25.3.2. 制作一个基础备份 25.3.3. 使用低级API制作一个基础备份 25.3.4. 使用一个连续归档备份进行恢复 25.3.5. 时间线 25.3.6. 建议和例子 25.3.7. 警告 在任何时间,PostgreSQL在数据集簇目录的pg_wal/子目录下都保持有一个预写式日志(WAL)。
25.2. 文件系统级别备份 另外一种备份策略是直接复制PostgreSQL用于存储数据库中数据的文件,第 18.2 节解释了这些文件的位置。你可以采用任何你喜欢的方式进行文件系统备份,例如: tar -cf backup.tar /usr/local/pgsql/data 但是这种方法有两个限制,使得这种方法不实用,或者说至少比pg_dump方法差: 为了得到一个可用的备份,数据库服务器必须被关闭。
25.1. SQL转储 25.1.1. 从转储中恢复 25.1.2. 使用pg_dumpall 25.1.3. 处理大型数据库 SQL 转储方法的思想是创建一个由SQL命令组成的文件,当把这个文件回馈给服务器时,服务器将利用其中的SQL命令重建与转储时状态一样的数据库。
第 24 章 日常数据库维护工作 目录 24.1. 日常清理 24.1.1. 清理的基础知识 24.1.2. 恢复磁盘空间 24.1.3. 更新规划器统计信息 24.1.4. 更新可见性映射 24.1.5. 防止事务 ID 回卷失败 24.1.6. 自动清理后台进程 24.2. 日常重建索引 24.3. 日志文件维护 和任何数据库软件一样,PostgreSQL需要定期执行特定的任务来达到最优的性能。
24.3. 日志文件维护 把数据库服务器的日志输出保存在一个地方是个好主意, 而不是仅仅通过/dev/null丢弃它们。 在进行问题诊断的时候,日志输出是非常宝贵的。不过,日志输出可能很庞大(特别是在比较高的调试级别上), 因此你不会希望无休止地保存它们。
24.2. 日常重建索引 在某些情况下值得周期性地使用REINDEX命令或一系列独立重构步骤来重建索引。 已经完全变成空的B树索引页面被收回重用。但是,还是有一种低效的空间利用的可能性:如果一个页面上除少量索引键之外的全部键被删除,该页面仍然被分配。
第 23 章 本地化 目录 23.1. 区域支持 23.1.1. 概述 23.1.2. 行为 23.1.3. 问题 23.2. 排序规则支持 23.2.1. 概念 23.2.2. 管理排序规则 23.3. 字符集支持 23.3.1. 被支持的字符集 23.3.2. 设置字符集 23.3.3. 服务器和客户端之间的自动字符集转换 23.3.4. 进一步阅读 本章从管理员的角度描述可用的本地化特性。
23.3. 字符集支持 23.3.1. 被支持的字符集 23.3.2. 设置字符集 23.3.3. 服务器和客户端之间的自动字符集转换 23.3.4. 进一步阅读 PostgreSQL里面的字符集支持你能够以各种字符集存储文本,包括单字节字符集,比如 ISO 8859 系列,以及多字节字符集 ,比如EUC(扩展 Unix 编码 Extended Unix Code)、UTF-8 和 Mule 内部编码。
23.2. 排序规则支持 23.2.1. 概念 23.2.2. 管理排序规则 排序规则特性允许指定每一列甚至每一个操作的数据的排序顺序和字符分类行为。这放松了数据库的LC_COLLATE和LC_CTYPE设置自创建以后就不能更改这一限制。