Update backup.sgml

Author: chegong18

postgresql/doc/src/sgml/backup.sgml

@@ -286,8 +286,8 @@ ____________________________________________________________________________-->
 
 <!--==========================orignal english content==========================
    <para>
-    After restoring a backup, it is wise to run <xref
-    linkend="sql-analyze"/> on each
+    After restoring a backup, it is wise to run <link
+    linkend="sql-analyze"><command>ANALYZE</command></link> on each
     database so the query optimizer has useful statistics;
     see <xref linkend="vacuum-for-statistics"/>
     and <xref linkend="autovacuum"/> for more information.
@@ -297,7 +297,7 @@ ____________________________________________________________________________-->
    </para>
 ____________________________________________________________________________-->
    <para>
-    一旦完成恢复，在每个数据库上运行<xref linkend="sql-analyze"/>是明智的举动，这样优化器就有有用的统计数据了，更多信息参见<xref linkend="vacuum-for-statistics"/>和<xref linkend="autovacuum"/>。更多关于如何有效地向<productname>PostgreSQL</productname>里装载大量数据的建议， 请参考<xref linkend="populate"/>。
+    一旦完成恢复，在每个数据库上运行<link linkend="sql-analyze"><command>ANALYZE</command></link>是明智的举动，这样优化器就有有用的统计数据了，更多信息参见<xref linkend="vacuum-for-statistics"/>和<xref linkend="autovacuum"/>。更多关于如何有效地向<productname>PostgreSQL</productname>里装载大量数据的建议， 请参考<xref linkend="populate"/>。
    </para>
   </sect2>
 
@@ -448,31 +448,48 @@ ____________________________________________________________________________-->
      The <command>split</command> command
      allows you to split the output into smaller files that are
      acceptable in size to the underlying file system. For example, to
-     make chunks of 1 megabyte:
+     make 2 gigabyte chunks:
 
 <programlisting>
-pg_dump <replaceable class="parameter">dbname</replaceable> | split -b 1m - <replaceable class="parameter">filename</replaceable>
+pg_dump <replaceable class="parameter">dbname</replaceable> | split -b 2G - <replaceable class="parameter">filename</replaceable>
 </programlisting>
 
      Reload with:
 
 <programlisting>
 cat <replaceable class="parameter">filename</replaceable>* | psql <replaceable class="parameter">dbname</replaceable>
 </programlisting>
+
+     If using GNU <application>split</application>, it is possible to
+     use it and <application>gzip</application> together:
+
+<programlisting>
+pg_dump <replaceable class="parameter">dbname</replaceable> | split -b 2G -&minus;filter='gzip > $FILE.gz'
+</programlisting>
+
+     It can be restored using <command>zcat</command>.
     </para>
 ____________________________________________________________________________-->
     <para>
-     <command>split</command>命令允许你将输出分割成较小的文件以便能够适应底层文件系统的尺寸要求。例如，让每一块的大小为1兆字节：
+     <command>split</command>命令允许你将输出分割成较小的文件以便能够适应底层文件系统的尺寸要求。例如，让每一块的大小为2吉字节：
 
 <programlisting>
-pg_dump <replaceable class="parameter">dbname</replaceable> | split -b 1m - <replaceable class="parameter">filename</replaceable>
+pg_dump <replaceable class="parameter">dbname</replaceable> | split -b 2G - <replaceable class="parameter">filename</replaceable>
 </programlisting>
 
      恢复：
 
 <programlisting>
 cat <replaceable class="parameter">filename</replaceable>* | psql <replaceable class="parameter">dbname</replaceable>
 </programlisting>
+
+     如果使用 GNU <application>split</application>, 可能会把它和 <application>gzip</application> 一起使用:
+
+<programlisting>
+pg_dump <replaceable class="parameter">dbname</replaceable> | split -b 2G -&minus;filter='gzip > $FILE.gz'
+</programlisting>
+
+     它可以用 <command>zcat</command> 恢复。
     </para>
    </formalpara>
 
@@ -1022,6 +1039,21 @@ ____________________________________________________________________________-->
     有一点很重要：当且仅当归档命令成功时，它才返回零退出。在得到一个零值结果之后，<productname>PostgreSQL</productname>将假设该文件已经成功归档， 因此它稍后将被删除或者被新的数据覆盖。但是，一个非零值告诉<productname>PostgreSQL</productname>该文件没有被归档； 因此它会周期性的重试直到成功。
    </para>
 
+<!--==========================orignal english content==========================
+   <para>
+    When the archive command is terminated by a signal (other than
+    <systemitem>SIGTERM</systemitem> that is used as part of a server
+    shutdown) or an error by the shell with an exit status greater than
+    125 (such as command not found), the archiver process aborts and gets
+    restarted by the postmaster. In such cases, the failure is
+    not reported in <xref linkend="pg-stat-archiver-view"/>.
+   </para>
+____________________________________________________________________________-->
+   <para>
+    当归档命令被一个信号(不是作为服务器关闭的一部分所用的<systemitem>SIGTERM</systemitem>)或者是退出状态超过125(例如命令没有发现)的脚本的一个错误所终止时，
+    归档进程会退出并且被postmaster重新启动。当这种情况下，<xref linkend="pg-stat-archiver-view"/> 中不会报告故障。
+   </para>
+
 <!--==========================orignal english content==========================
    <para>
     The archive command should generally be designed to refuse to overwrite
@@ -1385,7 +1417,8 @@ SELECT * FROM pg_stop_backup(false, true);
      <filename>backup_label</filename> in the root directory of the backup. The
      third field should be written to a file named
      <filename>tablespace_map</filename> unless the field is empty. These files are
-     vital to the backup working, and must be written without modification.
+     vital to the backup working and must be written byte for byte without 
+     modification, which may require opening the file in binary mode.
     </para>
    </listitem>
    <listitem>
@@ -1474,16 +1507,15 @@ SELECT pg_start_backup('label', false, false);
     <para>
      在同一个连接中，发出命令：
 <programlisting>
-SELECT * FROM pg_stop_backup(false);
+SELECT * FROM pg_stop_backup(false, true);
 </programlisting>
      这会终止备份模式。在主控机上，它还执行一次自动切换到下一个WAL段。在后备机上，它无法自动切换WAL段，因此用户可能希望在主控机上运行<function>pg_switch_wal</function>来执行一次手工切换。要做切换的原因是让在备份期间写入的最后一个WAL段文件能准备好被归档。
     </para>
     <para>
      <function>pg_stop_backup</function>将返回一个具有三个值的行。这些域的
      第二个应该被写入到该备份根目录中名为<filename>backup_label</filename>的
      文件。第三个域应该被写入到一个名为<filename>tablespace_map</filename>
-     的文件，除非该域为空。这些文件对该备份正常工作来说是至关重要的，
-     不能被随意修改。
+     的文件，除非该域为空。这些文件对该备份正常工作来说是至关重要的，必须逐个字节的写入而不能被随意修改，可能需要采用二进制的方式打开文件。
     </para>
    </listitem>
    <listitem>
@@ -1533,7 +1565,7 @@ ____________________________________________________________________________-->
      non-exclusive one, but it differs in a few key steps. This type of
      backup can only be taken on a primary and does not allow concurrent
      backups.  Moreover, because it creates a backup label file, as
-     described below, it can block automatic restart of the master server
+     described below, it can block automatic restart of the primary server
      after a crash.  On the other hand, the erroneous removal of this
      file from a backup or standby is a common mistake, which can result
      in serious data corruption.  If it is necessary to use this method,
@@ -1607,9 +1639,9 @@ SELECT pg_start_backup('label', true);
      this will result in corruption.  Confusion about when it is appropriate
      to remove this file is a common cause of data corruption when using this
      method; be very certain that you remove the file only on an existing
-     master and never when building a standby or restoring a backup, even if
+     primary and never when building a standby or restoring a backup, even if
      you are building a standby that will subsequently be promoted to a new
-     master.
+     primary.
     </para>
    </listitem>
    <listitem>
@@ -1794,16 +1826,16 @@ ____________________________________________________________________________-->
    <para>
     It is often a good idea to also omit from the backup the files
     within the cluster's <filename>pg_replslot/</filename> directory, so that
-    replication slots that exist on the master do not become part of the
+    replication slots that exist on the primary do not become part of the
     backup.  Otherwise, the subsequent use of the backup to create a standby
     may result in indefinite retention of WAL files on the standby, and
-    possibly bloat on the master if hot standby feedback is enabled, because
+    possibly bloat on the primary if hot standby feedback is enabled, because
     the clients that are using those replication slots will still be connecting
-    to and updating the slots on the master, not the standby.  Even if the
-    backup is only intended for use in creating a new master, copying the
+    to and updating the slots on the primary, not the standby.  Even if the
+    backup is only intended for use in creating a new primary, copying the
     replication slots isn't expected to be particularly useful, since the
     contents of those slots will likely be badly out of date by the time
-    the new master comes on line.
+    the new primary comes on line.
    </para>
 ____________________________________________________________________________-->
    <para>
@@ -2280,16 +2312,17 @@ ____________________________________________________________________________-->
 
 <!--==========================orignal english content==========================
    <para>
-    The default behavior of recovery is to recover along the same timeline
-    that was current when the base backup was taken.  If you wish to recover
-    into some child timeline (that is, you want to return to some state that
-    was itself generated after a recovery attempt), you need to specify the
-    target timeline ID in <xref linkend="guc-recovery-target-timeline"/>. You cannot recover into
-    timelines that branched off earlier than the base backup.
+    The default behavior of recovery is to recover to the latest timeline found
+    in the archive. If you wish to recover to the timeline that was current
+    when the base backup was taken or into a specific child timeline (that
+    is, you want to return to some state that was itself generated after a
+    recovery attempt), you need to specify <literal>current</literal> or the
+    target timeline ID in <xref linkend="guc-recovery-target-timeline"/>. You
+    cannot recover into timelines that branched off earlier than the base backup.
    </para>
 ____________________________________________________________________________-->
    <para>
-    恢复的默认行为是沿着相同的时间线进行恢复，该时间线是基础备份创建时的当前时间线。如果你希望恢复到某个子女时间线（即，你希望回到在一次恢复尝试后产生的某个状态），你需要在<xref linkend="guc-recovery-target-timeline"/>中指定目标时间线ID。你不能恢复到早于该基础备份之前分支出去的时间线。
+    恢复的默认行为是沿着归档中所发现的最新的时间线进行恢复。如果你希望恢复到执行基础备份时的当前时间线或者某个指定的子时间线（即，你希望回到在一次恢复尝试后产生的某个状态），你需要指定<literal>current</literal>或者在<xref linkend="guc-recovery-target-timeline"/>中指定目标时间线ID。你不能恢复到早于该基础备份之前分支出去的时间线。
    </para>
   </sect2>
 
@@ -2416,22 +2449,22 @@ ____________________________________________________________________________-->
       If archive storage size is a concern, you can use
       <application>gzip</application> to compress the archive files:
 <programlisting>
-archive_command = 'gzip &lt; %p &gt; /var/lib/pgsql/archive/%f'
+archive_command = 'gzip &lt; %p &gt; /mnt/server/archivedir/%f.gz'
 </programlisting>
       You will then need to use <application>gunzip</application> during recovery:
 <programlisting>
-restore_command = 'gunzip &lt; /mnt/server/archivedir/%f &gt; %p'
+restore_command = 'gunzip &lt; /mnt/server/archivedir/%f.gz &gt; %p'
 </programlisting>
      </para>
 ____________________________________________________________________________-->
      <para>
       如果担心归档存储的尺寸，你可以使用<application>gzip</application>来压缩归档文件：
 <programlisting>
-archive_command = 'gzip &lt; %p &gt; /var/lib/pgsql/archive/%f'
+archive_command = 'gzip &lt; %p &gt; /mnt/server/archivedir/%f.gz'
 </programlisting>
       那么在恢复时你将需要使用<application>gunzip</application>：
 <programlisting>
-restore_command = 'gunzip &lt; /mnt/server/archivedir/%f &gt; %p'
+restore_command = 'gunzip &lt; /mnt/server/archivedir/%f.gz &gt; %p'
 </programlisting>
      </para>
     </sect3>
@@ -2550,7 +2583,7 @@ ____________________________________________________________________________-->
   <itemizedlist>
    <listitem>
     <para>
-     If a <xref linkend="sql-createdatabase"/>
+     If a <link linkend="sql-createdatabase"><command>CREATE DATABASE</command></link>
      command is executed while a base backup is being taken, and then
      the template database that the <command>CREATE DATABASE</command> copied
      is modified while the base backup is still in progress, it is
@@ -2563,7 +2596,7 @@ ____________________________________________________________________________-->
 
    <listitem>
     <para>
-     <xref linkend="sql-createtablespace"/>
+     <link linkend="sql-createtablespace"><command>CREATE TABLESPACE</command></link>
      commands are WAL-logged with the literal absolute path, and will
      therefore be replayed as tablespace creations with the same
      absolute path.  This might be undesirable if the log is being
@@ -2584,13 +2617,13 @@ ____________________________________________________________________________-->
   <itemizedlist>
    <listitem>
     <para>
-     如果一个<xref linkend="sql-createdatabase"/>命令在基础备份时被执行，然后在基础备份进行时<command>CREATE DATABASE</command>所复制的模板数据库被修改，恢复中可能会导致这些修改也被传播到已创建的数据库中。这当然是我们不希望的。为了避免这种风险，最好不要在创建基础备份时修改任何模板数据库。
+     如果一个<link linkend="sql-createdatabase"><command>CREATE DATABASE</command></link>命令在基础备份时被执行，然后在基础备份进行时<command>CREATE DATABASE</command>所复制的模板数据库被修改，恢复中可能会导致这些修改也被传播到已创建的数据库中。这当然是我们不希望的。为了避免这种风险，最好不要在创建基础备份时修改任何模板数据库。
     </para>
    </listitem>
 
    <listitem>
     <para>
-     <xref linkend="sql-createtablespace"/>命令会WAL以其字面绝对路径记录，并且因此将在重放时以相同的绝对路径来创建表空间。当日志在一台不同的机器上被重放时，这可能也不是我们希望的。即使日志在同一台机器上被重放也是危险的，就算是恢复到一个新的数据目录重放过程也会覆盖原来表空间的内容。为了避免这种潜在的陷阱，最佳做法是在创建或丢弃表空间后创建一个新的基础备份。
+     <link linkend="sql-createtablespace"><command>CREATE TABLESPACE</command></link>命令会WAL以其字面绝对路径记录，并且因此将在重放时以相同的绝对路径来创建表空间。当日志在一台不同的机器上被重放时，这可能也不是我们希望的。即使日志在同一台机器上被重放也是危险的，就算是恢复到一个新的数据目录重放过程也会覆盖原来表空间的内容。为了避免这种潜在的陷阱，最佳做法是在创建或丢弃表空间后创建一个新的基础备份。
     </para>
    </listitem>
   </itemizedlist>