[firebase-br] Perda de dados 2 dias

Thiago Balbino tbalbinos em gmail.com
Ter Dez 22 08:21:27 -03 2009


*Sobre o ext3*

Ext3 difere do ext2 pois traz o conceito de "journal". Com isso, as mudanças
no sistema de arquivos passam a ser logadas em um arquivo journal, isto é, o
kernel mantém uma imagem do estado do sistema de arquivos que é atualizada
constantemente. Caso haja alguma falha como o travamento do sistema, seu
último estado de consistência será restaurado na reinicialização. Isto
substitui a necessidade do fsck verificar toda a metadata do sistema de
arquivos, sendo que apenas o que foi modificado será alterado. Assim
procura-se minimizar downtimes causados por longas checagens e
inconsistências no sistema. O ext3 é totalmente compatível com o ext2, é
possível alterar entre ext2 para ext3 e vice-versa sem problemas. Para
converter um sistema ext2 para ext3 não é realmente preciso desmontar a
partição. No caso da partição previamente montada, será criado um arquivo
.journal visível ao usuário. Se a partição root for convertida, será
necessário ter o suporte a ext3 no kernel e reinicializar o sistema. A
conversão em modo single-user após a criação de um disco inicial de RAM com
suporte a ext3 pode evitar possíveis erros. Com o sistema ext3 é possível
alterar os intervalos de verficação, que ocorrem a cada 180 dias ou após a
20a. montagem.

Pode-se desabilitá-la com o comando: tune2fs -i 0 -c 0 /dev/hdx

O ext3 apresenta diversas formas de "journaling", a padrão é data=ordered,
onde apenas alterações na metadata são gravadas no journal. Na opção
data=journal todas as mudanças nos dados são logadas, sendo a mais lenta mas
garantindo a maior integridade. A opção data=writeback é a mais rápida, pois
grava as mudanças sem aguardar uma sincronização com outras possíveis
mudanças no journal.

Para a alteração no fstab: /dev/hda5 /opt ext3 data=writeback 1 0

O último '0' representa o estágio no processo de boot em que o sistema
deverá ser verificado pelo fsck, no caso desabilitado em nosso sistema
journaled.

2009/12/21 Josauro S.J. <josauro em casasoft.inf.br>:
> É possivel em uma reinicialização de um servidor Linux 4GM memoria e
> firebird 2.0.3 haver perda de dados de 2 dias mais o menos 210 tabelas um
> movimento diario bastante expressivo, sem apresentar qualquer problema no
> banco de dados.
>
> A pergunta é pertinente a um banco de dados que voltou ao seu estado de 2
> dias atras, mais provel o retorno errado de um backup. Porem a pergunta é
> valida para tirar duvidas, sobre responsabilidade do DBA.
>
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>



-- 
Thiago de Souza Balbino

Analista de Sistemas / Programador
Meta Tecnologia e Sistemas - Muriaé / MG
(32) 3721 - 8729
(32) 8867 - 8729
MSN: thiagodeb em hotmail.com



Mais detalhes sobre a lista de discussão lista