[svnbook] r5988 committed - branches/1.8/zh/book/appd-berkeley-db.xml
wuzhouhui at users.sourceforge.net
wuzhouhui at users.sourceforge.net
Sun Sep 15 07:23:46 CDT 2019
Revision: 5988
http://sourceforge.net/p/svnbook/source/5988
Author: wuzhouhui
Date: 2019-09-15 12:23:46 +0000 (Sun, 15 Sep 2019)
Log Message:
-----------
1.8/zh: appendix D reviewed
Modified Paths:
--------------
branches/1.8/zh/book/appd-berkeley-db.xml
Modified: branches/1.8/zh/book/appd-berkeley-db.xml
===================================================================
--- branches/1.8/zh/book/appd-berkeley-db.xml 2019-09-14 14:08:06 UTC (rev 5987)
+++ branches/1.8/zh/book/appd-berkeley-db.xml 2019-09-15 12:23:46 UTC (rev 5988)
@@ -62,7 +62,7 @@
配置文件封装而成. Berkeley DB 环境有一套自己的默认配置, 例如在任意
时刻允许持有的数据库锁的个数, 日志文件的最大大小等. Subversion 的
文件系统逻辑根据自己的需要, 为某些 Berkeley DB 配置选项额外选取了默认
- 值. 然而, 你的仓库可能存放的是非常独特的数据, 而且访问模块也很特殊,
+ 值. 然而, 你的仓库可能存放的是非常独特的数据, 而且访问模式也很特殊,
这时候你可能需要一套不同的配置选项值.</para>
<!--
@@ -172,8 +172,8 @@
machine, stick with Windows 2000 or later.</para>
-->
<para>第二, Subversion 使用 Berkeley DB 的方式在 Windows 95/98 中
- 无法工作—如果管理员要在 Windows 系统中创建 Subversion 仓库,
- 必须是 Windows 2000 或更新的版本.</para>
+ 无法工作—如果管理员要在 Windows 系统中创建基于 BDB 的
+ Subversion 仓库, 必须是 Windows 2000 或更新的版本.</para>
</sect2>
@@ -344,10 +344,10 @@
<para>在 <xref linkend="svn.berkeleydb.limitations.faulttolerance" />
提到过, 如果未被恰当地关闭, 基于 Berkeley DB 的仓库可能会处于无法
访问的状态. 如果发生了这种情况, 管理员需要把数据库回滚到一个一致的
- 状态. 这是基于 BDB 的仓库特有的问题—如果仓库的后端存储是 FSFS,
+ 状态. 这是基于 BDB 的仓库所特有的问题—如果仓库的后端存储是 FSFS,
则根本不会出现这种问题. 从 1.4 (Berkeley DB 版本是 4.4) 开始,
Subversion 对异常情况的适应能力越来越强, 但还是有可能出现仓库
- 被卡住的情况, 这时候管理必须知道如何安全地处理这种状况.</para>
+ 被卡住的情况, 这时候管理员必须知道如何安全地处理这种状况.</para>
<!--
<para>To protect the data in your repository, Berkeley
@@ -369,7 +369,7 @@
-->
<para>为了保护仓库里的数据, Berkeley DB 使用了锁机制. 锁机制保证了数据库
的各个部分不会被多个访问者同时修改, 并且每个进程从数据库中读取时都能
- 看到处于正确状态的数据. 当一个进程需要修改数据库时的某个数据时, 它首先
+ 看到处于正确状态的数据. 当一个进程需要修改数据库里的某个数据时, 它首先
查看目标数据上是否存在锁, 如果目标数据未被锁定, 进程将会锁定数据, 然后
修改数据, 最后放锁. 其他进程将一直等待, 直到持锁的进程放锁后, 它们才能
继续访问目标数据. (这和仓库内的版本化文件上的锁一点关系也没有, 我们已
@@ -387,7 +387,7 @@
going to happen).</para>
-->
<para>在使用 Subversion 仓库的过程中, 致命的错误或中断会使得进程没
- 有机会去移除数据库上锁, 由此造成的结果是后端数据库系统被
+ 有机会去移除数据库上的锁, 由此造成的结果是后端数据库系统被
<quote>卡住</quote> 了. 这种情况一旦发生, 任何试图访问仓库的进程
都会被无限期地挂起 (因为每个进程都在等待解锁, 但原本要去解锁的进程
已经不存在了).</para>
@@ -482,7 +482,7 @@
users will be unable to access it.</para>
-->
<para>上面的步骤能够解决导致仓库卡住的大部分问题. 要确保在执行命令时
- 的身份是拥有仓库的用户, 而是不是简单地切换到 <literal>root</literal>
+ 的身份是拥有仓库的用户, 而不是简单地切换到 <literal>root</literal>
用户. 在恢复过程中可能会从头开始创建各种数据库文件 (例如共享内存区).
如果以 <literal>root</literal> 身份执行命令, 将导致新建的文件只属于
<literal>root</literal>, 这就意味着即使仓库重新上线, 普通用户也没
@@ -514,7 +514,7 @@
而言, 消耗磁盘最多的罪魁祸首就是 Berkeley DB 的日志文件, 这些日志
文件是 Berkeley DB 在修改真正地数据库文件之前所写的预写日志. 预写
日志记录了数据库从一个状态到另一个状态过程中所产生的所有活动, 而
- 数据库文件都任意一个时刻都代表了一个特定的状态, 日志文件包含了
+ 数据库文件在任意一个时刻都代表了一个特定的状态, 日志文件包含了
状态 <emphasis>之间</emphasis> 的所有修改, 因此日志会增长地非常
迅速, 消耗的磁盘存储空间也很可观.</para>
@@ -544,7 +544,7 @@
管理员忘记加上选项, 或者是后面又改变了心意, 只需要打开仓库子目录
<filename>db</filename> 里的 <filename>DB_CONFIG</filename> 文件,
注释掉含有 <literal>set_flags DB_LOG_AUTOREMOVE</literal> 的那一行,
- 然后对仓库执行 <command>svnadmin recover</command>, 使得修改的配置
+ 然后对仓库执行 <command>svnadmin recover</command>, 使得修改后的配置
生效.</para>
<!--
@@ -562,7 +562,7 @@
-->
<para>如果不支持日志文件的自动删除, 随着人们不断地使用仓库, 日志文件
会不断累积. 保留日志文件也可以算作数据库系统的一项特性—管理员
- 应该能够在只有日志文件情况下恢复整个数据库, 所以日志文件对于数据库
+ 应该能够在只有日志文件的情况下恢复整个数据库, 所以日志文件对于数据库
的灾备恢复非常有用. 但是在典型情况下, 管理员希望归档不再被 Berkeley
DB 使用的日志文件, 然后从磁盘上删除它们, 以便节省磁盘空间. 命令
<command>svnadmin list-unused-dblogs</command> 可以列出不再使用的
More information about the svnbook-dev
mailing list