可用性挑战

此页面用于跟踪我（Peter Eisentraut）有关 PostgreSQL 系统中可用性挑战的当前研究与开发项目。

核心服务器管理与配置

• 调优过多
  • 内存管理：太过复杂，几乎没有有用的指南，大部分内容都可以自动化
  • Vacuum：应该是自动的 -- 当然，自动真空
  • 后台写入器配置：谁需要这个？
  • 预写日志配置：太过复杂，应该是自动的
  • 空闲空间映射：该服务器非常清楚需要多少 FSM；另请参见内存管理。
• 缺乏可管理性
  • 用户帐户：仍然没有好办法可以通过 SQL 管理 pg_hba.conf
  • 统计数据：数据太多，但大多数人不知道如何利用
  • 配置文件：过长，包含大多数人不需要的选项过多
  • 插件：使用外部模块很复杂，有时有风险，难以管理。
  • 日志记录：日志记录的可配置性很好，但默认配置对新用户来说不太有用。
  • 跟踪：尽管有这些内容，有时仍然难以弄清楚发生了什么，例如在嵌套 PL/pgSQL 调用、级联外键操作和其它嵌套和级联上下文中。* 客户端
  • 健康检查：大多数用户甚至无法判断其系统可能配置错误。帮助他们。
  • 不支持带外监控。如果 pg_ctl 启动了后端程序但后端程序无法正常启动后端，则唯一的诊断信息就是自由格式文本日志。对于尝试管理和自动化 PostgreSQL 安装的人员来说，这很糟糕。需要一个可以报告信息（例如 Pg 侦听的端口、尝试启动后端时产生的错误、内存状态、正在运行的查询（无须启动新后端即可查询 pg_stat_activity）、锁定状态等）的带外监控工具。通过共享内存传递消息来与后端程序聊天的命令是有意义的，因为如果后端程序成功启动，它会成功绑定到共享内存。
• 数据库转储无法在不同操作系统间移植，因为 Pg 使用了特定操作系统的区域设置名称和 C 库的本地化实现。在某个操作系统上创建的数据库不一定可以在其他操作系统上恢复，而无需编码转换（pg_restore 和 psql 都没有提供相关的工具）或者至少手动使用 hoffefully 兼容的区域设置名称执行 CREATE DATABASE。

psql

• psql 对于鲁棒性强、可靠的自动化和脚本编写来说不是一个好选择。它非常适合交互式使用，但尝试在非交互式场景下对它进行配置，以确保错误检查正常、输出有意义。--- 它一团糟。这篇研究论文的评论中也提到了这一点。

备份、pg_dump、pg_dumpall 和 pg_restore

• Windows 和 Linux（UTF8）系统上选择的默认编码/区域设置不兼容，因此，如果在 Linux 上运行 pg_dump -Fc -f dbname.backup dbname，然后在 Windows 上运行 pg_restore -C --dbname postgres dbname.backup（或反之），则会无法创建数据库并中止恢复！，还会显示一条没有帮助的错误，如 could not execute query: ERROR: invalid locale name en_US.UTF-8。太差劲了！我们需要一个编码/区域设置等价表，并且需要在未来的版本中提供一些与操作系统无关的区域设置或服务器自身的映射。请参阅上方关于核心服务器中与操作系统相关的区域设置的要点。
• 没有一个 pg_dumpall 和 pg_restore --create 始终可以连接到的数据库。用户不应该为这两个命令中的任何一个指定一个数据库 - 这与直觉完全相反 - 但由于 postgres 和 template1 都可以删除且无法连接到 template0，因此没有一个数据库默认情况下始终可以对其进行连接。这会导致奇怪的命令行，如 pg_restore --create --dbname postgres mydb.backup，目的是还原到一个新创建的数据库中，该数据库很可能但并非一定会被称为 mydb，而不是还原到 postgres 数据库中。如果用户省略了 --dbname，他们会得到 SQL 转储内容到控制台的转储！这不利于使用；在执行与数据库无关的操作时，这些工具应该有一个只读、不可删除、始终可用的数据库，以便可以始终对其进行连接。
• pg_dump 不会全局化数据库所依赖的对象，即使在 -Fc 模式下也是如此。这意味着，默认情况下，PostgreSQL 数据库转储无法正确恢复，除非用户另外单独转储其他信息！。pg_dump 应对所转储数据库引用的诸如角色那样的全局对象进行转储，以便默认情况下备份是完整且正确的。
• pg_dumpall 不支持自定义格式。您无法创建包含集群中所有数据库的归档，或让其生成每个数据库一个转储文件再加一个全局文件。这必须使用脚本手动完成，不太友好。默认情况下备份需要容易正确进行！
• pg_restore -C 不允许您为新数据库选择所需的名称，它强制其使用 DB 转储时的名称。如果您需要不同的名称，则必须手动创建具有正确编码、权限、所有权、角色等的数据库。
• pg_restore 不提倡使用 PgAdmin-III 期望的 .backup 文件扩展名

PgAdmin-III（大多数新手的第一个接触点）

• PgAdmin-III 可用性可能有一定缺陷
• 使用 PgAdmin-III 的“还原”对话框并将其指向一个 .sql 转储会生成一条无用的错误消息。它应该提供针对目标数据库运行 SQL 转储，至少在面临包含实用“--- PostgreSQL 数据库转储”标头的 pg_dump sql 转储时如此（尽管它可能已本地化，需要检查）
• PgAdmin-III 没有提供简单方法运行可能包含 psql 命令（如 \connect）的 SQL 脚本。由于 pg_dump 在转储中默认发出 psql 命令，这意味着用户无法使用 PgAdmin-III gui 还原 SQL 转储。
• 加载到 PgAdmin-III 的 SQL 编辑器中的 SQL 脚本由 PgAdmin-III 自动、静默地包装在事务中。如果任何语句失败，则整个脚本都会失败。因为 pg_dump 倾向在转储中生成 \connect dbname 和 CREATE ROLE postgres; 这样的语句，这意味着在能够还原转储之前，必须手动编辑转储。
• PgAdmin-III 使用无用的 .backup 后缀表示它使用 pg_dump -Fc 在幕后创建的备份。备份什么？ 在 pg_restore 中没有任何内容表示文件应该具有 .backup 扩展名，它也不鼓励以这种方式创建文件，因此希望通过 PgAdmin-III 从命令行还原从命令行创建的备份的用户经常不得不在还原之前重命名文件或修改筛选器，才能在文件列表中看到它。
• 它没有注册 .backup 文件的文件扩展名处理程序
• 如果您将 .backup 文件拖放到 PgAdmin-III 中或将它们作为命令行参数传递给 pgadmin3 可执行文件，它没有理解 .backup 文件，并且没有提供文件->打开菜单项
• 即使您打算勾选使用 pg_restore 的 -C 选项的“创建数据库”选项，在还原 .backup 文件之前也必须在 PgAdmin-III 中选择一个数据库。那是真的违反直觉；您应该仅仅能够选择要还原到的服务器，或使用菜单中的还原项并提示目标服务器。
• 使用 PgAdmin-III 的还原、创建数据库选项时，你无权选择新建数据库使用的数据库名称，它会在没有任何提示的情况下直接使用备份文件中的数据库名称。这是 pg_restore 的一个限制。
• 每当使用 pg_dump 或 pg_restore 作业时，PgAdmin-III 的用户界面都会被锁定，对于普通用户来说，它就像崩溃或假死一样。
• PgAdmin-III 不会给出恢复命令失败的原因，它会直接吐出 pg_restore 的命令行输出。

复制

• 内置复制无法只复制集群中的某些数据库；例如，你必须同时复制只有 10MB 的 my-critically-important-10MB-database 和高达 50GB 的 my-totally-unimportant-50GB-database，且使用相同的设置、优先级等。这是一项可使用性挑战，因为它意味着人们必须创建和管理多个集群来控制复制组，而且多个集群很难管理和配置。

另请参见 可用性审查