9.1第十七章

第十七章 服务器设置和操作

目录 17.1 PostgreSQL用户帐号

17.2 建立数据库团

17.3 启动服务器

17.3.1 服务器启动失败

17.3.2 客户连接问题

17.4 管理内核资源

17.4.1 共享内存和信号

17.4.2 资源限制

17.4.3 linux内存过量使用

17.5 关闭服务器

17.6 升级PostgreSQL集群

17.6.1 通过pg dump升级数据

17.6.2 非dump升级方法

17.7 阻止服务器冒名使用

17.8 加密选项

17.9 用SSL连接安全的TCP/IP

17.9.1 利用客户端认证

17.9.2 SSL服务器文件使用

17.9.3 创建一个自签证

17.10 用SSH Tunnels连接安全的TCP/IP

本章讨论如何连接与运行数据库服务器和它与操作系统的交互。

17.1 PostgreSQL 用户帐号

和可从外界访问的任何一种服务器守护一样，建议在一个独立的用户帐号下运行PostgreSQL。该用户帐号应该仅拥有由服务器管理的数据，并且不应该与其他守护进程共享。（例如，使用nobody是一个坏主意）。我们不建议安装由该用户拥有的可执行文件，因为受损的系统可能会修正它们自己的二进制文件。

要在您系统上增加一个Unix用户帐号，参考命令useradd或adduser。经常使用用户名postgres，并且本书都假设用此名，但是您可以选择您喜欢的用户名。

17.2 创建数据库集群

Before you can do anything, you must initialize a database storage area on disk. We call this a database cluster. (SQL uses the term catalog cluster.) A database cluster is a collection of databases that is managed by a single instance of a running database server. After initialization, a database cluster will contain a database named postgres, which is meant as a default database for use by utilities, users and third party applications. The database server itself does not require the postgres database to exist, but many external utility programs assume it exists. Another database created within each cluster during initialization is called template1. As the name suggests, this will be used as a template for subsequently created databases; it should not be used for actual work. (See Chapter 21 for information about creating new databases within a cluster.)

在您可以做任何事之前，您必须在您硬盘上初设一个数据库存储区，我们把它叫作数据库集群（SQL使用目录集群这个术语）。一个数据库集群是数据库的集合，它由一个单独的运行的数据库服务器管理。在初设之后，数据库集群将包含一个名为postgres的数据库，它是作为一个默认数据库被实用程序、用户和第三方应用程序使用的。数据库服务器本身不要求postgres数据库存在，但是许多内部实用程序假设它存在。在初设每个集群中生成的另一个数据库是template1。就如名字所言，它将被用作创建数据库的模板；它对实际工作没什么用处（参考第21章关于在一个集群中创建新的数据库的信息）。

在文件系统条件下，数据库集群是一个独立的目录，所有数据都存储在里面，我们把它叫作data directory或data area。把数据存放到哪个目录下完全由您自己决定，没有默认路径，尽管有些位置，例如/usr/local/pgsql/data或/var/lib/pgsql/data 非常常用。要初始化一个数据库集群，使用命令initdb，它随PostgreSQL一起被安装。您数据库集群的理想文件系统位置由－D选项描述，例如：

$ initdb -D /usr/local/pgsql/data

注意当您登入PostgreSQL用户帐号时您必须执行该命令，帐号在前面一节已经描述。

提醒：作为－D选项的替代，您可以设置环境变量PGDATA。

或者，您可以通过pg_ctl运行initdbm，

$ pg_ctl -D /usr/local/pgsql/data initdb

17.3 启动数据库服务器

任何人在进入数据库之前必须启动数据库服务器。数据库服务器项目称作postgres，postgres项目必须知道从哪里能找到它支持使用的数据，这可以用-D选项完成。因此，启动服务器的最简单方法是：

$ postgres -D /usr/local/pgsql/data

它将使服务器在前台运行，这点必须在以postgreSQL用户账号登陆时必须完成。没有选项-D，服务器讲试图使用由环境变量PGDATA命名的数据目录，如果变量也没有提供，则服务器将启动失败。

一般最好在后台启动postgres，对于这个，使用常用的unix shell语句：

$ postgres -D /usr/local/pgsql/data >logfile 2>&1 &

正如上面显示的，储存服务器的stdout和stderr输出非常重要，它将帮助审查目标和诊断错误。（参考23.3节获得更透彻的关于日志文件的讨论）

postgres项目同时也有许多其他的命令行选项，想得到更多的信息，参考postgers文献页和下面的第十八章的内容。

该shell语句可能很快冗长。因此wrapper项目pg ctl被用来简化一些任务，例如，

pg_ctl start -l logfile

将在后台启动服务器，并将输出放到命名的日志文件中。-D选项和postgers.pg_ctl有相同的意思，它们都能够停止服务器。

一般情况下，您希望在启动计算机时启动数据库服务器，自启动脚本特有的操作系统，

17.5 关闭服务器

There are several ways to shut down the database server. You control the type of shutdown by sending different signals to the master postgres process.

SIGTERM

This is the Smart Shutdown mode. After receiving SIGTERM, the server disallows new connections, but lets existing sessions end their work normally. It shuts down only after all of the sessions terminate. If the server is in online backup mode, it additionally waits until online backup mode is no longer active. While backup mode is active, new connections will still be allowed, but only to superusers (this exception allows a superuser to connect to terminate online backup mode). If the server is in recovery when a smart shutdown is requested, recovery and streaming replication will be stopped only after all regular sessions have terminated.

有许多方法来关闭数据库服务器，您可以通过发送不同的信号给管理postgres程序来控制关闭的类型。

SIGTERM

这是精巧关闭模式。在接收到SIGTERM后，服务器不再允许新的连接，但是会让已存在的部分正常结束其工作。它只在所有阶段都终止后关闭。如果服务器处于备份模式，则它会等到备份模式不再活动为止。当备份模式处于激活状态时，新连接仍然被允许，但是只有超级用户才行。如果当要求精巧关闭时服务器处于修复状态，则修复和流式复制只在多有正常部分终止后停止。

SIGINT

This is the Fast Shutdown mode. The server disallows new connections and sends all existing server processes SIGTERM, which will cause them to abort their current transactions and exit promptly. It then waits for all server processes to exit and finally shuts down. If the server is in online backup mode, backup mode will be terminated, rendering the backup useless.

SIGINT

这是快速关闭模式。服务器不允许新的连接，并且发送所有已经存在的服务器进程SIGTERM，它将导致它们中止它们当前的事物处理并立即退出。它将等到所有服务器进程都退出之后再最后关闭。如果服务器处于备份模式，则备份模式将中断，致使备份无效。

SIGQUIT

This is the Immediate Shutdown mode. The master postgres process will send a SIGQUIT to all child processes and exit immediately, without properly shutting itself down. The child processes likewise exit immediately upon receiving SIGQUIT. This will lead to recovery (by replaying the WAL log) upon next start-up. This is recommended only in emergencies.

SIGQUIT

这是立即关闭模式。管理员postgres进程将发送一个SIGQUIT给所有的子进程并立即退出，不会正当地自动关闭。子进程在接受到SIGQUIT信号后也会立即退出。这将导致在下次启动时恢复，我们建议仅在紧急情况下使用该方法。

The pg_ctl program provides a convenient interface for sending these signals to shut down the server. Alternatively, you can send the signal directly using kill on non-Windows systems. The PID of the postgres process can be found using the ps program, or from the file postmaster.pid in the data directory. For example, to do a fast shutdown:

pg_ctl程序提供一个方便的交互界面来发送这些信号来关闭服务器。作为替换，在非Windows系统下，您可以直接使用kill发送信号。postgres的PID可以使用ps命令找到或从数据目录的postmaster.pid文件中找到。例如，实现快速关闭：

$ kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`

Important: It is best not to use SIGKILL to shut down the server. Doing so will prevent the server from releasing shared memory and semaphores, which might then have to be done manually before a new server can be started. Furthermore, SIGKILL kills the postgres process without letting it relay the signal to its subprocesses, so it will be necessary to kill the individual subprocesses by hand as well.

重要：最好不要使用SIGKILL来关闭服务器，这样做会阻止服务器发行共享内存和信号，这些可能不得不在一个新的服务器启动之前手动完成。而且，SIGKILL会杀死postgres进程，但没有传递信号给其子进程，所以还必须手动杀死单个的子进程。

To terminate an individual session while allowing other sessions to continue, use pg_terminate_backend() (see Table 9-55) or send a SIGTERM signal to the child process associated with the session.

要在允许其他部分运行的同时中断单个部分，使用pg_terminate_backend()（参考表格9-55）或发送信号给与该部分相关的子进程。

17.6 数据库集群的升级

This section discusses how to upgrade your database data from one PostgreSQL release to a newer one.

PostgreSQL major versions are represented by the first two digit groups of the version number, e.g., 8.4. PostgreSQL minor versions are represented by the third group of version digits, e.g., 8.4.2 is the second minor release of 8.4. Minor releases never change the internal storage format and are always compatible with earlier and later minor releases of the same major version number, e.g., 8.4.2 is compatible with 8.4, 8.4.1 and 8.4.6. To update between compatible versions, you simply replace the executables while the server is down and restart the server. The data directory remains unchanged — minor upgrades are that simple.

本部分讨论从一个PostgreSQL发行到一个新发行时如何升级您的数据库数据。

PostgreSQL升级版本用版本数字的前两个数字群表示，例如，8.4。PostgreSQL维护型版本用版本数字的第三个群表示，例如，8.4.2是8.4版本的第二次维护型发行。维护型发行从不改变内部的存储格式且对于同一升级版本，它始终和先前或之后的维护型版本兼容，例如，8.4.2和8.4、8.4.1和8.4.6兼容。想在兼容型版本之间进行升级，您只需在服务器关闭时简单地更改执行文件并且重启服务器。数据目录保持不变－维护型版本升级就是那样简单。

For major releases of PostgreSQL, the internal data storage format is subject to change, thus complicating upgrades. The traditional method for moving data to a new major version is to dump and reload the database. Other methods are available, as discussed below.

对于PostgreSQL的升级型发行，内部数据存储格式常会改变，因此是复杂的升级。将数据移动到一个新的升级型版本的传统方法是转储和重装数据库，其他的方法也可用，例如下面的讨论。

新的升级型版本同样介绍一些用户可见的非兼容性，所以也许要求更改应用程序。所有用户可见的更改都列在了发行说明中（附录E），请特别注意标注了“Migration”的部分。如果您在升级超过几个升级版本时，一定要阅读每个介入版本的发行说明。

谨慎的用户在完全切换之前会想测试下在新版本上他们客户端的应用，因此，设定同时安装老版本和新版本是个不错的建议。在测试一个PostgreSQL升级版升级时，考虑下面可能改变的目录：

Administration

   The capabilities available for administrators to monitor and control the server often change and improve in each major release. 

SQL

   Typically this includes new SQL command capabilities and not changes in behavior, unless specifically mentioned in the release notes. 

Library API

   Typically libraries like libpq only add new functionality, again unless mentioned in the release notes. 

System Catalogs

   System catalog changes usually only affect database management tools. 

Server C-language API

   This involves changes in the backend function API, which is written in the C programming language. Such changes affect code that references backend functions deep inside the server.

管理

管理员管理和控制服务器的可用能力经常改变并且在每个升级版本中会提升。

SQL

这个通常包括新的可用SQL命令，除非在发行说明中特别说明，否杂它在性能上不会改变。

API 库

通常像libpq这个样的库只会增加新函数，除非在发行说明中提到。

系统目录

系统目录更改通常只会影响数据库管理工具。

C语言 API 服务器

这个牵涉到后台函数API的改变，它是用c语言编写的。这样的改变影响引用深入服务器后台函数的代码。

17.6.1. Upgrading Data via pg_dump

To dump data from one major version of PostgreSQL and reload it in another, you must use pg_dump; file system level backup methods will not work. (There are checks in place that prevent you from using a data directory with an incompatible version of PostgreSQL, so no great harm can be done by trying to start the wrong server version on a data directory.)

17.6.1 通过pg_dump升级数据

从PostgreSQL的一个升级型版本转储数据并重装到另外一个版本中，您必须使用pg_dump，文件系统备份方法不再适用。（有适当的核查来阻止您使用一个非兼容版本的数据目录，所以试图在数据目录上启动一个错误的服务器版本不会产生任何危害。）

It is recommended that you use the pg_dump and pg_dumpall programs from the newer version of PostgreSQL, to take advantage of enhancements that might have been made in these programs. Current releases of the dump programs can read data from any server version back to 7.0.

我们推荐您从新版本的PostgreSQL中使用pg_dump 和 pg_dumpall程序 These instructions assume that your existing installation is under the /usr/local/pgsql directory, and that the data area is in /usr/local/pgsql/data. Substitute your paths appropriately.

  1.If making a backup, make sure that your database is not being updated. This does not affect the integrity of the backup, but the changed data would of course not be included. If necessary, edit the permissions in the file /usr/local/pgsql/data/pg_hba.conf (or equivalent) to disallow access from everyone except you. See Chapter 19 for additional information on access control.

     To back up your database installation, type:

     pg_dumpall > outputfile

     If you need to preserve OIDs (such as when using them as foreign keys), then use the -o option when running pg_dumpall.

     To make the backup, you can use the pg_dumpall command from the version you are currently running. For best results, however, try to use the pg_dumpall command from PostgreSQL 9.1devel, since this version contains bug fixes and improvements over older versions. While this advice might seem idiosyncratic since you haven't installed the new version yet, it is advisable to follow it if you plan to install the new version in parallel with the old version. In that case you can complete the installation normally and transfer the data later. This will also decrease the downtime.

17.9 安全连接

17.10