[svnbook-pt-br commit] r352 - trunk/book
codesite-noreply at google.com
codesite-noreply at google.com
Wed Dec 24 19:14:49 CST 2008
Author: mfandrade
Date: Wed Dec 24 15:30:55 2008
New Revision: 352
Modified:
trunk/book/ch05-repository-admin.xml
Log:
Tradução do capítulo 5, ""Administração do Repositório", seção "Manutenção
do Repositório", subseção "Recuperação do Berkeley DB".
Modified: trunk/book/ch05-repository-admin.xml
==============================================================================
--- trunk/book/ch05-repository-admin.xml (original)
+++ trunk/book/ch05-repository-admin.xml Wed Dec 24 15:30:55 2008
@@ -1714,81 +1714,86 @@
<!-- ===============================================================
-->
<sect2 id="svn.reposadmin.maint.recovery">
- <title>Berkeley DB Recovery</title>
+ <title>Recuperação do Berkeley DB</title>
- <para>As mentioned in <xref
- linkend="svn.reposadmin.basics.backends.bdb"/>, a Berkeley DB
- repository can sometimes be left in frozen state if not closed
- properly. When this happens, an administrator needs to rewind
- the database back into a consistent state. This is unique to
- BDB-backed repositories, though—if you are using
- FSFS-backed ones instead, this won't apply to you. And for
- those of you using Subversion 1.4 with Berkeley DB 4.4 or
- better, you should find that Subversion has become much more
- resilient in these types of situations. Still, wedged
- Berkeley DB repositories do occur, and an administrator needs
- to know how to safely deal with this circumstance.</para>
-
- <para>In order to protect the data in your repository, Berkeley
- DB uses a locking mechanism. This mechanism ensures that
- portions of the database are not simultaneously modified by
- multiple database accessors, and that each process sees the
- data in the correct state when that data is being read from
- the database. When a process needs to change something in the
- database, it first checks for the existence of a lock on the
- target data. If the data is not locked, the process locks the
- data, makes the change it wants to make, and then unlocks the
- data. Other processes are forced to wait until that lock is
- removed before they are permitted to continue accessing that
- section of the database. (This has nothing to do with the
- locks that you, as a user, can apply to versioned files within
- the repository; we try to clear up the confusion caused by
- this terminology collision in <xref
+ <para>Como mencionado em <xref
+ linkend="svn.reposadmin.basics.backends.bdb"/>, um repositório
+ Berkeley DB, algumas vezes pode ser deixado em um estado
+ congelado se não for fechado adequadamente. Quando isto
+ acontece, um administrador precisa retroceder a base de dados
+ de volta a um estado consistente. Embora isso seja específico
+ apenas para repositórios baseados em BDB—assim, se você
+ estiver usando repositórios baseados em FSFS, isto não se aplica
+ a você. E para aqueles que estiverem usando o Subversion 1.4
+ com Berkeley DB 4.4 ou superior, vocês deveriam perceber que o
+ Subversion se tornou muito mais resistente nesses tipos de
+ situações. Mas, problemas com repositórios Berkeley DB ainda
+ podem ocorrer, e um administrador precisa saber como agir
+ seguramente nessas circunstâncias.</para>
+
+ <para>Para proteger os dados em seu repositório, o Berkeley DB usa
+ um mecanismo de travas. Este mecanismo assegura que porções da
+ base de dados não sejam modificadas simultaneamente por
+ múltiplos acessos à base de dados, e que cada processo veja os
+ dados no estado correto quando esses dados estiverem sendo lidos
+ da base de dados. Quando um processo precisar modificar algo na
+ base de dados, ele primeiro procura pela existência de uma trava
+ nos dados cuja modificação se destina. Se os dados não
+ estiverem travados, o processo trava os dados, faz as
+ modificações pretendidas, e então destrava os dados. Outros
+ processos são forçados a esperar até que uma trava seja
+ removida antes de conseguir permissão para acessar àquela seção
+ da base de dados. (Isto não tem nada a ver com as travas que
+ você, como usuário, pode criar em arquivos versionados dentro do
+ repositório; tentamos esclarecer a confusão causada por essa
+ colisão de terminologias em <xref
linkend="svn.advanced.locking.meanings" />.)</para>
- <para>In the course of using your Subversion repository, fatal
- errors or interruptions can prevent a process from having the
- chance to remove the locks it has placed in the database. The
- result is that the back-end database system gets
- <quote>wedged</quote>. When this happens, any attempts to
- access the repository hang indefinitely (since each new
- accessor is waiting for a lock to go away—which isn't
- going to happen).</para>
-
- <para>If this happens to your repository, don't panic. The
- Berkeley DB filesystem takes advantage of database
- transactions and checkpoints and pre-write journaling to
- ensure that only the most catastrophic of events
+ <para>Ao longo de sua utilização do repositório do Subversion,
+ erros fatais ou interrupções podem evitar que um processo tenha
+ a oportunidade de remover travas que tenham criado na base de
+ dados. O resultado é que o sistema da base de dados pode ficar
+ <quote>encravado</quote>. Quando isto acontece, quaisquer
+ tentativas de se acessar o repositório pode resultar em
+ travamentos indefinidamente (como cada novo ancestral esteja
+ aguardando por uma trava para prosseguir—o que não é algo
+ que estará para acontecer).</para>
+
+ <para>Se isto acontecer com seu repositório, não se desespere. O
+ sistema de arquivos do Berkeley DB se aproveita das transações
+ e pontos de verificação e journaling de pré-escrita para se
+ assegurar que somente os eventos mais catastróficos
<footnote>
- <para>E.g.: hard drive + huge electromagnet = disaster.</para>
+ <para>P.ex.: disco rígido + grande eletromagnetismo =
desastre.</para>
</footnote>
- can permanently destroy a database environment. A
- sufficiently paranoid repository administrator will have made
- off-site backups of the repository data in some fashion, but
- don't head off to the tape backup storage closet just yet.</para>
+ pode destruir permanentemente um ambiente da base de dados. Um
+ administrador de repositório paranóico terá feito backups dos
+ dados do repositório em máquinas distintas da mesma forma, mas
+ não abra a gaveta das fitas de armazenamento de de backup
+ ainda.</para>
- <para>Instead, use the following recipe to attempt to
- <quote>unwedge</quote> your repository:</para>
+ <para>Ao invés disso, use a seguinte receita para tentar
+ <quote>desencravar</quote> seu repositório:</para>
<orderedlist>
<listitem>
- <para>Make sure that there are no processes accessing (or
- attempting to access) the repository. For networked
- repositories, this means shutting down the Apache HTTP
- Server or svnserve daemon, too.</para>
+ <para>Assegure-se de que não há processos acessando (ou
+ tentando acessar) o repositório. Para repositórios em rede,
+ isto significa derrubar o servidor Apache HTTP ou o daemon
+ svnserve, também.</para>
</listitem>
<listitem>
- <para>Become the user who owns and manages the repository.
- This is important, as recovering a repository while
- running as the wrong user can tweak the permissions of the
- repository's files in such a way that your repository will
- still be inaccessible even after it is
- <quote>unwedged</quote>.</para>
+ <para>Torne-se o usuário que possui e gerencia o repositório.
+ Isto é importante, já que realizar a recuperação de um
+ repositório com o usuário errado pode detonar as permissões
+ dos arquivos do repositório de tal forma que seu repositório
+ ficará inacessível mesmo depois de
+ <quote>desencravado</quote>.</para>
</listitem>
<listitem>
- <para>Run the command <command>svnadmin recover
- /path/to/repos</command>. You should see output like
- this:</para>
+ <para>Execute o comando <command>svnadmin recover
+ /path/to/repos</command>. Você deveria ver uma saída como
+ esta:</para>
<screen>
Repository lock acquired.
@@ -1797,33 +1802,37 @@
Recovery completed.
The latest repos revision is 19.
</screen>
- <para>This command may take many minutes to complete.</para>
+ <para>Este comando pode levar alguns minutos para
completar.</para>
</listitem>
<listitem>
- <para>Restart the server process.</para>
+ <para>Reinicie o processo do servidor.</para>
</listitem>
</orderedlist>
- <para>This procedure fixes almost every case of repository
- lock-up. Make sure that you run this command as the user that
- owns and manages the database, not just as
- <literal>root</literal>. Part of the recovery process might
- involve recreating from scratch various database files (shared
- memory regions, for example). Recovering as
- <literal>root</literal> will create those files such that they
- are owned by <literal>root</literal>, which means that even
- after you restore connectivity to your repository, regular
- users will be unable to access it.</para>
-
- <para>If the previous procedure, for some reason, does not
- successfully unwedge your repository, you should do two
- things. First, move your broken repository directory aside
- (perhaps by renaming it to something like
- <filename>repos.BROKEN</filename>) and then restore your
- latest backup of it. Then, send an email to the Subversion
- user list (at <email>users at subversion.tigris.org</email>)
- describing your problem in detail. Data integrity is an
- extremely high priority to the Subversion developers.</para>
+ <para>Este procedimento vai corrigir praticamente todos os casos
+ de problemas dessa natureza do repositório. Certifique-se de
+ executar este comando como o usuário que possui e gerencia a
+ base de dados, não apenas como usuário <literal>root</literal>.
+ Parte do processo de recuperação pode envolver recriar do zero
+ vários arquivos da base de dados do repositório (regiões de
+ memória compartilhada, por exemplo). Fazer esta recuperação
+ como usuário <literal>root</literal> vai criar estes arquivos
+ como se tivessem pertencido ao <literal>root</literal>, o que
+ quer dizer que mesmo depois de você restaurar a conectividade de
+ seu repositório, usuários normais estarão impossibilitados de
+ acessá-lo.</para>
+
+ <para>Se o procedimento anterior, por alguma razão, não tiver
+ êxito ao desencravar o repositório, você deveria fazer duas
+ coisas. Primeiro, deixe seu diretório problemático de lado
+ (talvez renomeando-o para algo como
+ <filename>repos.BROKEN</filename>) e então restaure o último
+ backup que você tiver dele. Depois, envie um e-mail à lista
+ de usuários do Subversion (em
+ <email>users at subversion.tigris.org</email>) descrevendo seu
+ problema em detalhes. A integridade de dados é uma
+ característica de altíssima prioridade para os desenvolvedores
+ do Subversion.</para>
</sect2>
More information about the svn-pt_br
mailing list