[svnbook-pt-br commit] r276 - trunk/book

codesite-noreply at google.com codesite-noreply at google.com
Sat Nov 22 16:54:49 CST 2008


Author: mfandrade
Date: Sat Nov 22 14:54:20 2008
New Revision: 276

Modified:
    trunk/book/ch05-repository-admin.xml

Log:
Tradução do capítulo "Administração do Repositório", sub-subseção "Berkeley  
DB".

Modified: trunk/book/ch05-repository-admin.xml
==============================================================================
--- trunk/book/ch05-repository-admin.xml	(original)
+++ trunk/book/ch05-repository-admin.xml	Sat Nov 22 14:54:20 2008
@@ -558,129 +558,150 @@
        <sect3 id="svn.reposadmin.basics.backends.bdb">
          <title>Berkeley DB</title>

-        <para>When the initial design phase of Subversion was in
-          progress, the developers decided to use Berkeley DB for a
-          variety of reasons, including its open-source license,
-          transaction support, reliability, performance, API
-          simplicity, thread-safety, support for cursors, and so
-          on.</para>
-
-        <para>Berkeley DB provides real transaction
-          support—perhaps its most powerful feature.  Multiple
-          processes accessing your Subversion repositories don't have
-          to worry about accidentally clobbering each other's data.
-          The isolation provided by the transaction system is such
-          that for any given operation, the Subversion repository code
-          sees a static view of the database—not a database that
-          is constantly changing at the hand of some other
-          process—and can make decisions based on that view.  If
-          the decision made happens to conflict with what another
-          process is doing, the entire operation is rolled back as if
-          it never happened, and Subversion gracefully retries the
-          operation against a new, updated (and yet still static) view
-          of the database.</para>
-
-        <para>Another great feature of Berkeley DB is <firstterm>hot
-          backups</firstterm>—the ability to backup the database
-          environment without taking it <quote>offline</quote>.  We'll
-          discuss how to backup your repository in <xref
-          linkend="svn.reposadmin.maint.backup"/>, but the benefits of  
being
-          able to make fully functional copies of your repositories
-          without any downtime should be obvious.</para>
-
-        <para>Berkeley DB is also a very reliable database system when
-          properly used.  Subversion uses Berkeley DB's logging
-          facilities, which means that the database first writes to
-          on-disk log files a description of any modifications it is
-          about to make, and then makes the modification itself.  This
-          is to ensure that if anything goes wrong, the database
-          system can back up to a previous
-          <firstterm>checkpoint</firstterm>—a location in the
-          log files known not to be corrupt—and replay
-          transactions until the data is restored to a usable state.
-          See <xref linkend="svn.reposadmin.maint.diskspace"/> for
-          more about Berkeley DB log files.</para>
-
-        <para>But every rose has its thorn, and so we must note some
-          known limitations of Berkeley DB.  First, Berkeley DB
-          environments are not portable.  You cannot simply copy a
-          Subversion repository that was created on a Unix system onto
-          a Windows system and expect it to work.  While much of the
-          Berkeley DB database format is architecture independent,
-          there are other aspects of the environment that are not.
-          Secondly, Subversion uses Berkeley DB in a way that will not
-          operate on Windows 95/98 systems—if you need to house
-          a BDB-backed repository on a Windows machine, stick with
-          Windows 2000 or newer.</para>
-
-        <para>While Berkeley DB promises to behave correctly on
-          network shares that meet a particular set of specifications,
+        <para>Quando a fase de projeto inicial do Subversion estava em
+          andamento, os desenvolvedores decidiram usar o Berkeley DB por
+          diversas razões, incluindo sua licença open-source, suporte a
+          transações, confiabilidade, desempenho, simplicidade da API,
+          segurança no uso em multitarefas, suporte para cursores de
+          dados, dentre outras.</para>
+
+        <para>O Berkeley DB oferece suporte real para
+          transações—talvez seu recurso mais poderoso.  Múltiplos
+          processos que acessem seus repositórios Subversion não
+          precisam se preocupar em sobrescrever acidentalmente os dados
+          uns dos outros.  O isolamento oferecido pelo sistema de
+          transações age de tal forma que, para cada operação realizada,
+          o código no repositório do Subversion tenha uma visão estática
+          da base de dados—e não uma base de dados que esteja
+          mudando constantemente nas mãos de alguns outros
+          processoss—e possa tomar decisões baseadas no que vê.
+          Se uma decisão tomada parecer conflitar com o que outro
+          processo esteja fazendo, a operação inteira é desfeita como se
+          nunca tivesse acontecido, e o Subversion graciosamente irá
+          tentar executar a operação sobre uma nova, atualizada (e ainda
+          assim, estática) visão da base de dados.</para>
+
+        <para>Outro grande recurso do Berkeley DB é o <firstterm>backup
+          a quente</firstterm>—a habilidade de executar uma cópia
+          de segurança do ambiente da base de dados sem precisar deixar
+          o sistema <quote>offline</quote>.  Vamos discutir como fazer
+          cópias de segurança de seu repositório em <xref
+          linkend="svn.reposadmin.maint.backup"/>, mas os benefícios de
+          se poder fazer cópias funcionais de seus repositórios sem
+          desligar o sistema devem lhe ser óbvios.</para>
+
+        <para>Berkeley DB é também um sistema de base de dados muito
+          confiável quando utilizado adequadamente.  O Subversion usa as
+          facilidades de registros de log do Berkeley DB, o que quer
+          dizer que a base de dados primeiro escreve uma descrição de
+          quaisuqer modificações que estiver para fazer em seus arquivos
+          de log em disco, e só então realiza a modificação em si.  Isto
+          é para garantir que se qualquer coisa der errado, o sistema da
+          base de dados pode se recuperar para um determinado
+          <firstterm>ponto de verificação</firstterm>
+          (<foreignphrase>checkpoint</foreignphrase>) anterior—um
+          local nos arquivos de log que se sabe não estarem
+          corrompidos—e re-executa as transações até que os dados
+          sejam restaurados para um estado utilizável.  Veja <xref
+          linkend="svn.reposadmin.maint.diskspace"/> para saber mais
+          sobre os arquivos de log do Berkeley DB.</para>
+
+        <para>Mas cada rosa tem seus espinhos, e assim devemos destacar
+          algumas conhecidas limitações do Berkeley DB.  Em primeiro
+          lugar, o ambiente do Berkeley DB não é portável.  Você não
+          pode simplesmente copiar um repositório do Subversion que foi
+          criado em um sistema Unix para dentro de um sistema Windows e
+          esperar que funcione.  Ainda que muito do formato da base de
+          dados do Berkeley DB seja independente de plataforma, há
+          alguns aspectos do ambiente que não o são.  Em segundo lugar,
+          o Subversion utiliza o Berkeley DB de forma que não irá
+          funcionar em sistemas Windows 95/98—se você precisa
+          hospedar um repositório em formato Berkeley DB em uma máquina
+          Windows, utilize-o com sistemas Windows 2000 ou
+          posteriores.</para>
+
+        <para>Ainda que o Berkeley DB prometa se comportar corretamente
+          em compartilhamentos de rede que estejam de acordo com um
+          conjunto de especificações,
            <footnote>
-            <para>Berkeley DB requires that the underlying filesystem
-              implement strict POSIX locking semantics, and more
-              importantly, the ability to map files directly into
-              process memory.</para>
+            <para>O Berkeley DB precisa que o sistema de arquivos em
+              questão onde esteja o compartilhamento deve implementar
+              estritamente a semântica POSIX de travamento, e ainda mais
+              importante, a capacidade de mapear arquivos diretamente
+              para processos em memória.</para>
            </footnote>
-          most networked filesystem types and appliances do
-          <emphasis>not</emphasis> actually meet those requirements.
-          And in no case can you allow a BDB-backed repository that
-          resides on a network share to be accessed by multiple
-          clients of that share at once (which quite often is the
-          whole point of having the repository live on a network share
-          in the first place).</para>
+          e a maioria dos tipos de sistemas de arquivos e aplicações
+          atuais <emphasis>não</emphasis> implementam essas tais
+          especificações.  E de forma nenhuma você pode usar um
+          repositório baseado em BDB que resida em um compartilhamento
+          de rede sendo acessado por múltiplos clientes do
+          compartilhamento de uma só vez (o que muitas vezes é o ponto
+          determinante para não se escolher ter repositórios hospedados
+          em um compartilhamento em primeiro lugar).</para>

          <warning>
-          <para>If you attempt to use Berkeley DB on a non-compliant
-            remote filesystem, the results are unpredictable—you
-            may see mysterious errors right away, or it may be months
-            before you discover that your repository database is
-            subtly corrupted.  You should strongly consider using the
-            FSFS data store for repositories that need to live on a
-            network share.</para>
+          <para>Se você tentar usar Berkeley DB em um sistema de
+            arquivos remoto que não atenda às especificações, os
+            resultados serão imprevisíveis—você pode ver erros
+            misteriosos imediatamente, ou pode levar meses antes de você
+            descobrir que sua base de dados do repositório está
+            sutilmente corrompida.  Você deveria considerar muito
+            seriamente o uso de armazenamento de dados em FSFS para
+            repositórios que precisem residir em um compartilhamento de
+            rede.</para>
          </warning>

-        <para>Finally, because Berkeley DB is a library linked
-          directly into Subversion, it's more sensitive to
-          interruptions than a typical relational database system.
-          Most SQL systems, for example, have a dedicated server
-          process that mediates all access to tables.  If a program
-          accessing the database crashes for some reason, the database
-          daemon notices the lost connection and cleans up any mess
-          left behind.  And because the database daemon is the only
-          process accessing the tables, applications don't need to
-          worry about permission conflicts.  These things are not the
-          case with Berkeley DB, however.  Subversion (and programs
-          using Subversion libraries) access the database tables
-          directly, which means that a program crash can leave the
-          database in a temporarily inconsistent, inaccessible state.
-          When this happens, an administrator needs to ask Berkeley DB
-          to restore to a checkpoint, which is a bit of an annoyance.
-          Other things can cause a repository to <quote>wedge</quote>
-          besides crashed processes, such as programs conflicting over
-          ownership and permissions on the database files.</para>
+        <para>E finalmente, como o Berkeley DB é uma biblioteca
+          interligada diretamente dentro do Subversion, ele é mais
+          sensível a interrupções do que um sistema de uma base de dados
+          relacional.  A maioria dos sistemas SQL, por exemplo, possuem
+          um processo servidor dedicado que intermedia todo o acesso às
+          tabelas.  Se um programa que esteja acessando a base de dados
+          travar por algum motivo, o daemon da base de dados percebe a
+          perda de conexão e efetua uma limpeza de quaisquer vestígios
+          problemáticos que tenham ficado.  E como o daemon da base de
+          dados é o único processo que efetivamente acessa as tabelas,
+          as aplicações não precisam se preocupar com relação a
+          conflitos de permissão.  No entanto, esse tipo de cenário não
+          se aplica ao Berkeley BD.  O Subversion (e os programas que
+          usam bibliotecas do Subversion) acessam as tabelas da base de
+          dados diretamente, o que quer dizer que o travamento de um
+          programa pode deixar a base de dados temporariamente
+          inconsistente, em um estado inacessível.  Quando isso
+          acontece, um administrador precisa solicitar que o Berkeley DB
+          restaure-se a partir de um ponto de verificação, o que um
+          tanto quanto inconveniente.  Outras coisas também podem
+          <quote>comprometer</quote> um repositório em virtude de
+          processos travados, tais como conflitos entre programas
+          relacionados a permissões e propriedades dos arquivos na base
+          de dados.</para>

          <note>
-          <para>Berkeley DB 4.4 brings (to Subversion 1.4 and better)
-            the ability for Subversion to automatically and
-            transparently recover Berkeley DB environments in need of
-            such recovery.  When a Subversion process attaches to a
-            repository's Berkeley DB environment, it uses some process
-            accounting mechanisms to detect any unclean disconnections
-            by previous processes, performs any necessary recovery,
-            and then continues on as if nothing happened.  This
-            doesn't completely eliminate instances of repository
-            wedging, but it does drastically reduce the amount of
-            human interaction required to recover from them.</para>
+          <para>O Berkeley DB 4.4 oferece para o Subversion (nas versões
+            do Subversion 1.4 e superiores) a capacidade de se recuperar
+            o ambiente do Berkeley DB de forma automática e
+            transparente, caso necessário.  Quando um processo do
+            Subversion se interliga a um ambiente Berkeley DB do
+            repositório, ele utiliza alguns mecanismos de contabilização
+            para detectar quaisquer desconexões de processos anteriores,
+            executa alguma recuperação necessária, e então prossegue
+            como se nada tiver acontecido.  Isto não elimina
+            completamente as possibilidade de corrupção de instâncias do
+            repositório, mas reduz drasticamente a necessidade de
+            interação humana necessária para se recuperar desses tipos
+            de problemas.</para>
          </note>

-        <para>So while a Berkeley DB repository is quite fast and
-          scalable, it's best used by a single server process running
-          as one user—such as Apache's <command>httpd</command>
-          or <command>svnserve</command> (see <xref
-          linkend="svn.serverconfig"/>)—rather than accessing it
-          as many different users via <literal>file://</literal> or
-          <literal>svn+ssh://</literal> URLs.  If using a Berkeley DB
-          repository directly as multiple users, be sure to read <xref
+        <para>Assim, por mais que que um repositório Berkeley DB seja
+          bastante rápido e escalável, ele é melhor aproveitado se for
+          utilizado por um único processo servidor executando como um
+          único usuário—como o <command>httpd</command> do Apache
+          ou o <command>svnserve</command> (veja <xref
+          linkend="svn.serverconfig"/>)—ao invés do que por vários
+          usuários diferentes através de URLs <literal>file://</literal>
+          ou <literal>svn+ssh://</literal>.  Se você for usar um
+          repositório em Berkeley DB diretamente para múltiplos
+          usuários, certifique-se de ler <xref
            linkend="svn.serverconfig.multimethod"/>.</para>

        </sect3>


More information about the svn-pt_br mailing list