PostgreSQL9.0文档中“持续归档和基于时间点的恢复”部分的翻译1

本帖最后由 osdba 于 2010-08-19 00:01 编辑

PostgreSQL9.0 beta4版本发布了，在PostgreSQL9.0主要就是对Standby数据库的功能的增加，因为我着重翻译了PostgreSQL9.0文档中的“24.3 持续归档和基于时间点的恢复”
全文见我的blog：http://blog.chinaunix.net/u2/84422/showart_2302556.html

24.3 持续归档和基于时间点的恢复
   PostgreSQL在数据目录的pg_xlog子目录中始终维护一个WAL日志文件。这个日志文件记录数据库数据文件的每个改变。这个日志文件存在的主要目的是为数据库异常崩溃后数据库能安全的恢复:如果系统崩崩溃后，PostgreSQL通过重放最后一次checkpoint后的日志文件把数据库恢复到一致状态。然而，这个日志文件的存在，提供了了第三种的数据库备份策略：我们可以把文件系统备份和WAL备份组合成来。当需要恢复的时候，我们先通过文件系统备份还原数据库，然后再重放我们备份的WAL日志，这样就把数据库带到了当前状态。对于管理者来说这个方法比前面的方法更复杂，但是它有以下更重要的好处：
我们在开始备份数据库的时不再需要一个完美的一致性备份。在备份中的任何数据的非一致性都会被WAL日志文件的重放纠正。所以我们在备份数据库时不再需要一个特别的文件系统的快照就可以完成备份工作，例如通过tar或类似的文件归档工作就可以完成备份工作。
当我们组合一个无限长的WAL日文件的回放，持续的备份就可以通过不断的备份WAL日志文件来完成。这点对大数据库有特别重要的价值。因为这样，大数据库就不需要频繁的做全库备份了。
并不一定要把WAL文件一直重放到结束。我们能够重放到数据库到任何一个数据一致性的快照时间点，从而这项技术支持了基本时间点的恢复：你可以把数据库恢复到基础备份后的任一时间点。
如果我们持续的提供一系列的WAL日志文件给另一台机器上的从基础备份中还原出来的数据库，我们可以得到一个热备份的standby数据库：在任何时间我们都可以在第二台机器打开这个数据库，它拥有当前数据库的最近的数据状态。
   注意：pg_dump 和pg_dumpall不能产生文件系统级别的备份，所以不能做为持续归档的方案。这些dump命令是逻辑的备份，没有包括足够的信息供WAL重放使用。
   文件系统级别的备份的一个解释，这个方法仅支持整个数据库集的恢复，而不能做到部分的恢复。同时，这个方法需要大量的归档存储空间：基础备份可能是庞大的，一个繁忙的系统可能产生大量的WAL日志。然而，在很多需要高可靠的情况下这是首选的备份技术。
   要想通过持续的归档来做到成功的恢复（其它数据库也叫热备份），你需要开始备份之后的所有WAL文件。
所以在你做基础备份前，你需要设置和检查的你WAL归档。

24.3.1 Settup up WAL archiving 设置WAL归档
   在一个抽象的场景中，一个运行的PostgreSQL数据库产生一个无限长的顺序的WAL记录。数据库物理的把这个WAL记录序列分割成WAL文件（每个WAL文件为一个WAL段）,通常每个段的大小为16M(在编译PostgreSQL时可以通过编译选项改变这个大小）。这个段文件的名字是一个数字，用来反映它们在抽象的WAL序列中的位置。当不使用WAL归档时，系统也会创建一些WAL段文件,然后通过把不再需要的WAL文件改名成下一个日志号的方式循环的使用它们。能够被循环重复使用的WAL文件就是那些内容是最后一次checkpoint点之前的产生的的WAL文件。
   在归档WAL数据时，我们需要抓取每个WAL段文件被填充的内容，在被循环使用之前把数据存储到其它地方。依赖于应用和可用的硬件，有不同的方法去把WAL数据归档到其它地方：我们能拷贝WAL文件到一个从另一台机器导出的NFS目录，或把它们写到磁带上（确保你能从磁带备份中识别出每个WAL文件的原始的名字），或批量的把它们刻录到光盘中，或着完全使用其它什么别的办法。为了提供数据库管理的灵活性，PostgreSQL并不对如何做存档的方法做任何假设，相反的，PostgreSQL让管理员指定一个特别的shell命令支执行WAL文件的归档任务。这个shell命令可以非常简单，如一个cp命令，或一个非常复杂的shell命令，这一切都取决你。
   为了允许归档，需要把wal_level参数设置为“archive“或“hot_standby“,archive_mode参数设置为"on",并为archive_command命令指定一个shell命令。在实践中，postgresql.conf文件中将始终设置这些参数。在归档的命令中，“%p“用来替换需要归档的WAL全路径文件名，“%f“表示不带路径的文件名。（路径名是相对的当前的数据工作目录，即数据库的数据目录），如果你要使用“%“，请使用“%%”替代。最简单的归档命令为：
archive_command = 'cp -i %p /mnt/server/archivedir/%f </dev/null'
   这条命令将会把WAL文件拷贝到目录/mnt/server/archivedir目录（这仅是一个示例，而不是必须这样，同时这条命令也不是在所有平台都能正常工作）.当“%p”和“%f”参数被替换后，实际的命令类似如下：
cp -i pg_xlog/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065 </dev/null
　　每个新WAL文件归档时类似这样的一条命令就会被数据库调用。
   归档文件命令将以PostgreSQL服务器运行时的同一个用户去执行归档命令，被归档的一系列的WAL文件包含了数据库中任何有效的东西，你需要确保归档数据不会被非法访问，例如归档的目录不能有被其它用户读取的权限。
   归档命令的返回值仅在成功的时候返加0，这是很重要的。当返回0时，PostgreSQL就会认为文件被成功的归档了，然后就会被删除或循环使用它们。反之，如果返回一个非零值，PostgreSQL会认为文件没有归档，然后会周期的重试，直到成功。
   归档文件命令通常应旨在拒绝覆盖任何预先存在的文件。这是归档的一个重要的安全功能，当发生人为错误时能够保护你的归档（例如，将两个不同的服务器的WAL文件归档到了同一个目录中）。一个建议是测试您的存档命令，以确保它确实不覆盖现有的文件，同时最好在这种情况下返回非零状态。在许多的UNIX平台中，cp -i命令会提示是否覆盖一个文件，“</dev/null”会给出不覆盖的指示，然后命令以失败返回。如果你的平台不支持cp -i这个特性，你需要增加一个命令去测试文件是否存在。例如，命令可以类似如下：
archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
   这条命令可以工作于大多数的UNIX平台。
   在设计您的归档时,需要考虑当归档命令多次失败时将发生什么，如在某些方面需要操作员干预或归档文件运行空间不足的情况。例如：如果你写到不能自动换带的磁带的情况下，这就有可能发生。当磁盘满了，在更换磁盘前任何文件将不会被归档。您应确保任何错误或需要人工操作的要求能够被适当的报告出来，然后可以合理地快速解决。在这情况得到解决之前，pg_xlog目录一直会将处于满的状态。（如果px_xlog目录所在的文件系统满了，PostgreSQL将会做一个PANIC停机。未提交的事务将会丢失，一直到你释放空间之前数据库都会一直处于离线状态。
　　归档命令的速度是不重要的，只要它能跟上您的服务器生成WAL数据的平均速率。即使存档过程有点落后，但正常操作仍然能继续。如果归档大大落后，在一场灾难事件将会使丢失的数据量增加。它还意味着，在 pg_xlog/目录将包含大量的最终可能超过可用磁盘空间的未归档的WAL文件。建议您监视归档的过程，以确保它按您期望的那样工作。
   编写您的归档命令时： 您应假定要归档文件的名称可以是最多64个字符，并且可以包含 ASCII 字母、 数字和“.”的任意组合。不需要保留原始的相对路径 (%p)，但要保存的文件名称 (%f)。
   请注意虽然 WAL存档将允许您恢复PostgreSQL数据库中的数据所做的任何修改，但不会恢复由于那些手动编辑而不是通过SQL操作配置文件（也就是 postgresql.conf、 pg_hba.conf 和 pg_ident.conf） 所做的更改。您可能希望在文件系统的备份过程将配置文件保存在一个位置中。如何重新定位配置文件请参见18.2节。
   归档文件命令归档已经写完的WAL文件。因此，如果你的服务器生成很小WAL流量，完成的事务最后存储到归档记录中可能会有长时间的延迟。为一个限制未归档的数据最多时间是多少，可以设置archive_timeout参数去强制数据库切换到一个新的WAL文件。注意，强制切换的归档文件仍然有整个WAL文件的长度。因此设置非常短的archive_timeout时间是不明智的，它将增加你的归档存储空间。通常合理的archive_timeout值为1分钟。
   如果要确保刚刚完成的事务记录尽快到归档中，可以强制手工调用pg_switch_xlog。与WAL管理相关的其他实用程序列在Table 9-56。
   当wal_level设置为minimal时，一些sql命令被优化掉而不会记录在WAL日志中，请见14.4.7节。如果在执行一个这样的SQL语句时归档或流复制被打开，WAL不会包含足够的信息用于存档恢复。（crash恢复是不受影响的）。因为这样 wal_level只能在服务器启动时更改在。但是archive_command可以使用配置文件重新加载进行更改。如果想暂时停止存档做的一种方法是将 archive_command 设置为空字符串 ('')。这将导致 WAL 文件积累在pg_xlog目录，直到archive_command被重新设置。
   
24.3.2 制作数据库的基础备份
   下面是制作数据库基础备份的一个相对简单的过程：
确保WAL归档被打开和正常工作。
用超级用户连接到数据库并执行下面的命令：
select pg_start_backup('lable');
  label是您要用来标识该备份操作到哪的唯一的任意字符串。（一个很好的做法是使用要备份转储文件的完整路径。） pg_start_backup在数据目录中创建一个叫“backup_label“的backup_label文件，文件中包括了您的备份的开始时间和标签字符串等信息。
   使用此命令时连接到哪个数据库是不重要的。您可以忽略函数的返回的结果，但如果它报告出一个错误，继续之前请先处理完这个错误后再做后续的事情。　
   默认情况下，pg_start_backup会执行一个较长的时间。这是因为它要执行一个checkpoint检查点，
在一段重要的时间周期内checkpoint检查点会发出IO请求，默认情况下会有一半的inter-checkpoint时间（见配置参数checkpoint comlpletion target).这通常是你需要的，因为这样做对查询操作影响最小。如果你想开始备份尽可能使用如下操作：
select pg_start_backup('label',true);
   这条命令让checkpoint尽可以快的完成。
   3. 用一个尽可能方便的文件系统备份工具去执行备份，如cpio命令（而不是pg_dump或pg_dumpall）。当做这个操作时不需要停止正常的数据库操作。
   4. 重新以超级用户连接到数据库，执行下面的命令
   select pg_stop_backup();
   这个操作将中止备份模式然后自动切换到下一个WAL文件.切换的理由是，在归档备份期间写入的最后WAL段文件。
　　5. 最后的WAL段文件是被记录在pg_stop_bakcup的命令结果中。如果archive_mode是enabled，
直到最后的WAL段文件被归档后pg_stop_backup命令才会返回。自从你配置了archive_command参数后，归档就一直会自动的执行。在大多数情况下这个操作是快速的，但建议你是监控你的归档系统以确保不会有大的延迟。如果因为归档命令失败导致归档过程落后了，它会一直重试直到归档成功和备份完成。如果你期望限制
pg_stop_backup命令执行的时间，请设置statement_timeout参数为合适的值。
   在拷贝过程如果试图去拷贝的文件变化了，一些文件系统备份工具会忽略这些错误和警告。当做一个运行数据库的基础备份时，这种情况是正常的而不是错误。然后，你需要去确保能区别这种情况和真正的错误。例如：一些版本的rsync会返回一个单独的返回码表示“消失的源文件”,然后你写一个脚本把这个返回码做为一种非错误的情况处理。有时，如果一个文件被截断，一些版本的GNU tar工具正在拷贝这个文件时返回的一个错误码难以区别是其它严重错误还是这种情况。幸运的是，GNU tar 1.16版本及以后，如果在备份过程中，文件被改变了返回1，其它错误返回2.
　　从pg_start_backup真正开始备份到备份结束的pg_stop_backup之间的时间长短是不需要考虑的，几分钟的延迟不会带来任何伤害。（然后，如果你正常运行数据库时full_page_writes是关闭的，在
pg_start_backup和pg_stop_backup之间，你可能会注意到一个性能的下降，这是因full_page_writes
在备份的时候是强制打开的）。你必须确保这些步骤是按顺序执行的，没有任何可能的重叠，否则你的备份将无效。
   确定你的备份包括了在数据库数据目录（例如：/usr/local/pgsql/data)下的所有文件。如果你使用了所指向的目录不在这个目录之下的表空间，也需要小心的包括这些表空间的目录（也需要确保你的备份把表空间的链接文件也备份进去了，否则恢复时会损坏这个表空间）。
   为了使用备份，你需要保留执行基础备份后产生的所有WAL日志文件。为了辅助你做这个，pg_stop_backup函数在WAL归档区中创建了一个备份历史记录文件。这个文件的名字是以你的文件系统备份需要的第一个WAL日志文件开始。例如：如果开始的WAL日志文件名为：0000000100001234000055CD，则备份历史文件名大致
为：0000000100001234000055CD.007C9330.backup（文件名中的第二部分是在WAL文件中的精确的位置，通常可以忽略）。一旦你安全的归档了文件系统备份和需要的WAL日志文件（被指定在备份历史记录文件中）,所有比这个数字小的WAL日志文件恢复时不再需要，可以删除掉。然而，你应该考虑保留几份备份以确保你绝对能恢复的你数据。
    备份历史记录文件是一个小的文本文件。它包含了一个你传递给pg_start_backup函数的label串，也包含了备份起始时间、结束时间以及WAL日志文件名。如果你使用了这个label去标识这些相关的备份文件，这个备份历史记录文件足以告诉你哪些备份文件需要恢复。
    从最后的基础备份后，你必须保留这之后的所有的WAL日志文件，两个基础备份之间的时间间隔的大小取决你有多少存储空间花费在这些归档的WAL日志文件上。你也必须考虑在恢复数据库时你准备花多长时间，当需要恢复时，系统会重新应用所有的这些WAL日志文件，如果基础备份做得比较久的话，这可能会花费一个较长的时间。
    另一个值得注意的是pg_start_backup函数会建一个名叫“backuip_label”的文件在数据库的数据目录中，这个文件会被pg_stop_backup命令删除。这个文件当然会被归档到备份中。这个label文件包括了你传给pg_start_backup的“label”，也包含了pg_start_backup开始运行的时间和开始的WAL日志文件。可以查看一个备份中的这个文件来确认这个备份是属于哪个备份。
    当然，我们也可以在数据库停止时备份。在这种情况下，你当然不需要使用pg_start_backup或
pg_stop_backup， 你剩下需要做的是记录每个备份所需要的WAL文件是哪些。 通常最好按照上述的连续归档过程。

楼主是自己翻译的不。把所有的内容放到一起去。给你精华。

是我自己翻译的，一个贴子放不下，只好分成两个帖子。