You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Santiago Miguel <ms...@gmail.com> on 2012/07/18 10:56:59 UTC
Derby on NAS = corruption ?
Hi,
I work in a french company which provides secure online file management
services (SaaS solutions).
In one of our applications (backup software), in case of a large file,
we cut it into blocks and we use a Derby db in order to maintain the
block indexes. These Derby dbs (version 10.5.1.1) are stored on a NAS
(cluster Isilon NL series) shared between webservers. The derby db is
directly acceded on NAS and it is thread safe.
Everyday, we are observing many Derby db corruptions (Unknown page
format at page Page(524,Container(0, 1024))) and these dbs are no longer
usable.
I join the derby log file corresponding to the last night on 1 webserver.
Thanks in advance for your help.
Best regards,
Miguel Santiago
Re: Derby on NAS = corruption ?
Posted by "Dag H. Wanvik" <da...@oracle.com>.
Mo Maison <mo...@yahoo.fr> writes:
> Hello,
>
> I have read the referenced thread with great interest,
> and I have a related question.
>
> If we replace NAS with SAN (SAN is basically a remote
> block device).
> If a single server mounts the SAN partition, and a single
> derby server is run on this server, I guess we shouldn't
> encounter any trouble, should we ?
Derby uses a write-ahead log to guarantee that committed transactions
are persisted. If the log device is on the network storage, you need a
guarantee that the log write operations are actually
persisted. Similarly, for safe operation one needs to disable disk
cache in the operating system for the log device.
Cf. http://db.apache.org/derby/docs/10.9/adminguide/cadmindbintegrity.html
Dag
>
> Regards,
>
> M. Maison
>
>
> On 18/07/2012 14:48, Rick Hillegas wrote:
>> On 7/18/12 1:56 AM, Santiago Miguel wrote:
>>> Hi,
>>>
>>> I work in a french company which provides secure online file
>>> management services (SaaS solutions).
>>>
>>> In one of our applications (backup software), in case of a large
>>> file, we cut it into blocks and we use a Derby db in order to
>>> maintain the block indexes. These Derby dbs (version 10.5.1.1) are
>>> stored on a NAS (cluster Isilon NL series) shared between
>>> webservers. The derby db is directly acceded on NAS and it is
>>> thread safe.
>>> Everyday, we are observing many Derby db corruptions (Unknown page
>>> format at page Page(524,Container(0, 1024))) and these dbs are no
>>> longer usable.
>>>
>>> I join the derby log file corresponding to the last night on 1
>>> webserver.
>>> Thanks in advance for your help.
>>>
>>> Best regards,
>>> Miguel Santiago
>>>
>> Hi Miguel,
>>
>> The following email thread may shed light on the problems you are
>> seeing:
>> http://old.nabble.com/Client-server-plus-network-storage-of-database-files-td19565143.html
>>
>> Hope this helps,
>> -Rick
>>
Re: Derby on NAS = corruption ?
Posted by Mo Maison <mo...@yahoo.fr>.
Hello,
I have read the referenced thread with great interest,
and I have a related question.
If we replace NAS with SAN (SAN is basically a remote
block device).
If a single server mounts the SAN partition, and a single
derby server is run on this server, I guess we shouldn't
encounter any trouble, should we ?
Regards,
M. Maison
On 18/07/2012 14:48, Rick Hillegas wrote:
> On 7/18/12 1:56 AM, Santiago Miguel wrote:
>> Hi,
>>
>> I work in a french company which provides secure online file
>> management services (SaaS solutions).
>>
>> In one of our applications (backup software), in case of a large
>> file, we cut it into blocks and we use a Derby db in order to
>> maintain the block indexes. These Derby dbs (version 10.5.1.1) are
>> stored on a NAS (cluster Isilon NL series) shared between webservers.
>> The derby db is directly acceded on NAS and it is thread safe.
>> Everyday, we are observing many Derby db corruptions (Unknown page
>> format at page Page(524,Container(0, 1024))) and these dbs are no
>> longer usable.
>>
>> I join the derby log file corresponding to the last night on 1
>> webserver.
>> Thanks in advance for your help.
>>
>> Best regards,
>> Miguel Santiago
>>
> Hi Miguel,
>
> The following email thread may shed light on the problems you are
> seeing:
> http://old.nabble.com/Client-server-plus-network-storage-of-database-files-td19565143.html
>
> Hope this helps,
> -Rick
>
Re: Derby on NAS = corruption ?
Posted by Bryan Pendleton <bp...@gmail.com>.
>> These Derby dbs (version 10.5.1.1) are stored on a NAS (cluster Isilon NL series) shared between
>> webservers. The derby db is directly acceded on NAS and it is thread safe.
When you say the Derby dbs are stored on a device shared between webservers,
do you mean that there are Derby applications on each webserver directly
accessing the Derby db?
Or do you have some sort of Derby Network Server in place?
Derby attempts to prevent multiple JVMs concurrently opening the same database
with the embedded driver, but if your shared-file-system configuration
circumvents these protections, the database would quickly become corrupt.
thanks,
bryan
Re: Derby on NAS = corruption ?
Posted by Rick Hillegas <ri...@oracle.com>.
On 7/18/12 1:56 AM, Santiago Miguel wrote:
> Hi,
>
> I work in a french company which provides secure online file
> management services (SaaS solutions).
>
> In one of our applications (backup software), in case of a large file,
> we cut it into blocks and we use a Derby db in order to maintain the
> block indexes. These Derby dbs (version 10.5.1.1) are stored on a NAS
> (cluster Isilon NL series) shared between webservers. The derby db is
> directly acceded on NAS and it is thread safe.
> Everyday, we are observing many Derby db corruptions (Unknown page
> format at page Page(524,Container(0, 1024))) and these dbs are no
> longer usable.
>
> I join the derby log file corresponding to the last night on 1 webserver.
> Thanks in advance for your help.
>
> Best regards,
> Miguel Santiago
>
Hi Miguel,
The following email thread may shed light on the problems you are
seeing:
http://old.nabble.com/Client-server-plus-network-storage-of-database-files-td19565143.html
Hope this helps,
-Rick