PostgreSQL Replication之第三章 理解即时恢复（3）

3.3 做基础备份

在上一节中，您已经看到，启用归档只需要几行命令，并提供了极大的灵活性。在本节，我们将看到如何创建一个所谓的基础备份，稍后这可以使用XLOG。一个基本备份是一个最初的数据的拷贝。

[请记住，XLOG本身是没有什么价值的。只是在和初始备份联合起来的时候是有用的。]

在PostgreSQL中，有两个主要的选择来创建一个初始的基本备份：

• 使用 pg_basebackup

• 传统的基于 copy/rsync 的方法

下面两节将详细地介绍如何创建一个基础备份：

使用pg_basebackup

第一个也最常见的创建一个现有的服务器备份是运行一个称为 pg_basebackup 的命令，该命令在PostgreSQL 9.1.0 被引入。基本上，pg_basebackup 能够直接通过一个数据库连接获取一个数据库基本备份。但在slave上执行时，pg_basebackup 会连接到一个您选择的数据库服务器，并复制数据目录中的所有数据文件到您的机器。没有必要再登陆到服务器，它所需要的只有一行代码并运行它；pg_basebackup 将为您做所有剩余的工作。

在这个例子中，我们将假设我们要对一个称为 postgresql-support.de 的主机做一个基础备份。必须执行以下几步：

• 修改 pg_hba.conf  以允许复制

• 给 master 发信号考虑 pg_hba.conf 的变化

• 调用 pg_basebackup

修改pg_hba.conf

为了允许远程服务器登录到一个PostgreSQL 服务器，并允许流传送 XLOG，您必须明确地允许复制。

在PostgreSQL中，有一个成为pg_hba.conf 的文件，它告诉服务器允许哪台服务器使用哪种类型的凭据来连接。可以允许整个IP地址范围或者干脆通过pg_hba.conf 丢弃。

要启用复制，我们必须为我们希望允许的IP地址范围增加一行。

以下列表包含一个有效配置的例子：

# TYPE DATABASE USER ADDRESS METHOD

host replication all 192.168.0.34/32 md5

在这个例子中，我们允许复制从192.168.0.34 连接。IP 地址范围使用32位来确定(这仅仅代表我们的例子)。我们决定使用MD5作为认证方法。这意味着pg_basebackup 必须给服务器提供一个密码。如果您在一个安全要求不高的环境中使用trust 作为认证方法可能也是一中选择。

[ 如果您真的有一个称为replication的数据库在您的系统中会发生什么？基本上，设置数据库为复制只会配置您流行为，如果您要为处理数据库名为replication的数据库引入规则，您必须引用数据库名如下：“replication”。然而，我们强烈建议不要这样做一避免混淆。]

向master服务器发送信号

一旦对pg_hba.conf做了改变，我们就可以告诉PostgreSQL重新加载配置。没有必要完全重新启动数据库。我们有三个选择来重新加载pg_hba.conf:

• 通过运行SQL命令：SELECT pg_reload_conf();

• 通过给master 发送一个信号： kill –HUP 4711 (4711为master的进程ID)

• 通过调用 pg_ctl: pg_ctl –D $PGDATA reload ($PGDATA 是您的数据库实例的home 目录)

一旦我们告诉服务器作为数据源接受流连接，我们可以继续运行pg_basebackup。

pg_basebackup-基本功能

对于PostgreSQL来说，pg_basebackup 是一个非常易用的命令行工具。它必须由目标系统调用，并为您提供一个准备使用的基础备份，它准备为即时恢复消耗事务日志。

pg_basebackup 的语法如下：

iMac:dbhs$ pg_basebackup --help

pg_basebackup takes a base backup of a running PostgreSQL server.

Usage:

pg_basebackup [OPTION]...

Options controlling the output:

-D, --pgdata=DIRECTORY receive base backup into

directory

-F, --format=p|t output format (plain (default),

tar)

-x, --xlog include required WAL files in

backup (fetch mode)

-X, --xlog-method=fetch|stream

include required WAL files with

specified method

-z, --gzip compress tar output

-Z, --compress=0-9 compress tar output with given

compression level

General options:

-c, --checkpoint=fast|spread

set fast or spread checkpointing

-l, --label=LABEL set backup label

-P, --progress show progress information

-v, --verbose output verbose messages

-V, --version output version information, then exit

-?, --help show this help, then exit

Connection options:

-h, --host=HOSTNAME database server host or

socket directory

-p, --port=PORT database server port number

-s, --status-interval=INTERVAL

time between status packets sent to server (in seconds)

-U, --username=NAME connect as specified database

user

-w, --no-password never prompt for password

-W, --password force password prompt (should

happen automatically)

一个基本的pg_basebackup 如下：

iMac:dbhs$ pg_basebackup -D /target_directory \

-h sample.postgresql-support.de

在这个例子中，我们将从sample.postgresql-support.de获取基础备份，并把它放入我们的本地目录/target_directory。它需要这一行来复制整个数据库实例到目标系统。当我们创建一个基础备份是，如本节所示，pg_basebackup将连接到服务器并在实际进程开始之前等待一个检查点发生。这是必须的，因为重放进程将在XLOG的该点启动。问题是，等到一个检查点发生需要一段时间，pg_basebackup 不强制直接在源服务器上做检查点，以确保正常操作不受干扰。

[如果您不想等待一个检查点，可以考虑使用—checkpoint=fast。它会强制立即执行一个检查点，并且pg_basebackup将立即开始复制。]

默认情况下，一个基本的基础备份将被创建。它将包括能在源服务器目录中找到的所有文件。如果基础备份要存储到磁带上，我们建议使用 –format=t。他将自动创建一个TAR 归档(也许在磁带上)。如果您要将数据转移到磁带上，您可以可以容易的省去中间步骤。当使用TAR时，和—gzip一起使用，以减少磁盘上基础备份的大小是非常有益处的。

[还有一种方式，在做基础备份是看进度条，但是我们不推荐使用这个选项(--progress)，因为它需要pg_basebackup来首先确定源实例的大小，这可能是昂贵的。]

pg_basebackup-自给自足的备份

一般情况下，没有XLOG的基础备份是没有用的。这是因为基本备份是从完全正常运行的master取的。尽管采取了基础备份，那些在数据库实例中存储的文件可能基因被严重修改了。XLOG的目的是为了解决那些依赖的数据文件的潜在的问题。但是，如果我们要创建一个基础备份，它可以没有(明确归档的)XLOG？在这种情况下，我们可以使用—xlog-method=stream 选项。如果这个选项已被选定，pg_basebackup 将不只是复制数据，它也将流在我们为我们的目的服务器创建基础备份期间被创建的XLOG。这将为我们提供足够的XLOG允许我们直接启动使用那种方式做的基础备份。它是自给自足的，并且不需要额外的XLOG文件。这不针对即时恢复，但它可以在有麻烦的情况下派上用场。有一个可以马上启动的基础备份通常是一件好事，并且它的成本相当低。

[请注意，--xlog-method=stream将需要数据库连接到源服务器，不只是一个。当在源服务器上调整max_wal_senders 时，您必须记住这一点。]

如果您计划使用即时恢复，并且不需要启动备份，您可以放心地跳过XLOG并节省一些空间(缺省模式)。

利用传统的方法来创建基础备份

现在 pg_basebackup 是获得一个数据库服务器的初始副本最常用的方法。这并非总是如此。传统上，一个不同的方法已被使用，工作如下：

• 调用 SELECT pg_start_backup('some label');

• 通过 rsync 或者任何其它方法复制所有数据文件到远程服务器

• 运行 SELECT pg_stop_backup();

这个老方法的主要优势是，不需要打开数据库连接，不需要在源服务器上配置XLOG流基础设施。

另一个主要的优势的您可以使用一些例如ZFS-snapshots 或者类似的方法，这可以减少创建初始备份的I/O数量。

[一旦您已经启动了pg_start_backup，不要着急。不需要这样，甚至尤其不要希望离开备份模式。如果您处于备份模式，什么都不会发生。PostgreSQL 将和往常一样归档事务日志，用户不会有任何不利。当然，当基础备份在运行时PostgreSQL的内部工作方式不会发生改变。没有东西填充，没有磁盘I/O延迟，或者任何这种事情。]

表空间问题

如果您碰巧使用一个以上表空间，pg_basebackup 会很好地处理这个问题，如果在目标服务器的文件系统布局和master 上的文件系统的布局一样。但是，如果您的目标系统没有使用相同的文件系统布局，还有更多的事情要做。使用传统的方法做基础备份可能在这种情况下会有好处。

如果您使用的是 –format=t(对于 TAR)，将会为您提供每个表空间一个TAR文件。

密切关注网络带宽

让我们假设一个包含两台服务器的场景。每台服务器可能只有一个磁盘(没有SSD)。我们的两台服务器可能通过1个千兆的链接互联。如果第二台服务器开始运行 pg_basebackup，您的应用会发生什么呢？第二台服务器将连接，开始全速流数据并通过使用您的网络的全部带宽损坏您的硬盘驱动器。在 master 上运行的应用程序可能会立即面临磁盘等待提供较高的响应时间。因此，强烈推荐通过rsync控制带宽使用，以确保您的商业应用有足够的备用能力(通常来说磁盘，CPU不是问题)。

[如果您要限制rsync到20MB/sec，您可以简单地使用rsync –bwlimit=20000。这会让基础备份的创建花费更长的时间，但是它将确保您的客户端应用不会面临问题。一般我们建议一个master 和 slave 之间的专用网络互联，以确保基础备份不会影响正常的操作。]

限制带宽不能使用pg_basebackup的板载功能。当然，您可以使用任何其它工具来复制数据，并实现类似的效果。

[如果您正在使用—gzip使用gzip压缩，它可以作为一个减速工具来工作。但是，这主要是一种可能的变通方法。]