[firebase-br] Perda de Dados

[Gladiston Santana]

Os sistemas unix trabalham com ponteiros para os arquivos, chamados inodes,
assim quando voce renomeia ou move um arquivo com ele em uso não há nenhum
problema porque o inode sempre permanecerá o mesmo. Voce mesmo pode fazer
um teste, faça um download de arquivo, e enquanto estiver baixando tente
renomeiar ou movê-lo para outro lugar, o download será completado 100% e
sem erros mesmo assim porque ao mover o arquivo, inode permanecerá sempre o
mesmo.

O problema descrito na mensagem em inglês é que o camarada pode apagar um
arquivo em uso, porém o mesmo só será literalmente apagado quando o FB
desconectar-se dele, aceitando novas conexões e transações que no final
serão perdidas. Outro problema descrito é copiar arquivos de dados cujo
cache ainda não fez frush e portanto parcialmente em memória. Em ambos os
casos não é um problema do FB, mas um desconhecimento por parte do sysadmin
com respeito a manipulação de uso de arquivos em uso.

Mas estes casos diferem do problema do camarada, que como citou java,
compreendi que o servidor dele era Windows. Para mim, me pareceu apenas o
FB voltando no tempo até o ultimo checkpoint válido antes da corrupção da
base, como ele já tinha muito tempo sem backup, provavelmente a reparação
se deu automaticamente e foi identificado como perda de dados.



Em 31 de outubro de 2013 16:17, Carlos H. Cantu
<listas em warmboot.com.br>escreveu:

> "It is well-known fact that Linux uses the inode mechanism to support
> different file systems. One of the key features of this mechanism is
> the use of cache to handle file descriptors – it means that file
> descriptors are stored both in memory and on disk. To InterBase and
> Firebird it brings an onerous side-effect. If you replace a database
> when users are still connected, the server will continue to work with
> the old file, which is wrongly assumed to be deleted. The danger here
> is that, when the last user detaches, the server will drop the file
> forever and the “new” file steps in to replace it at that point. You
> never know it has happened until it is too late and then, it is most
> likely to be discovered by furious users: “Where is my work from last
> week?!” The longest period of lost data due to such «disappearing»
> that I have observed was 1.5 years. It was a multi-volume database on
> Linux and one of the 4Gb volumes was completely lost. You may say it
> is a very rare circumstance but I can stake a case of beer on the fact
> that, right now, at least one hundred server installations have this
> problem. We receive at least one repair request due to this problem
> every two months!"
>
> http://www.ib-aid.com/articles/item70
>
> []s
> Carlos H. Cantu
> www.FireBase.com.br - www.firebirdnews.org
> www.warmboot.com.br - blog.firebase.com.br
>