Menu
▾
▴
Re: [Exist-open] Possible problem with exist backup and restore where there are errors in the dom.dbx
|
From: Willem v. d. W. <wav...@gm...> - 2011-09-03 19:39:08
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Case 1: <br>
eXist Version: 1.4.1dev<br>
eXist Build: 20110522<br>
SVN Revision: 14490<br>
Operating System: Linux 2.6.18-164.el5 amd64<br>
Java<br>
Vendor: Sun Microsystems Inc.<br>
Version: 1.6.0_21<br>
Implementation: Java HotSpot(TM) 64-Bit Server VM<br>
<br>
Case 2:<br>
<br>
eXist Version: 1.4.1dev<br>
eXist Build: 20110611<br>
SVN Revision: 14669<br>
Operating System: Linux 2.6.18-194.el5xen amd64<br>
Java<br>
Vendor: Sun Microsystems Inc.<br>
Version: 1.6.0_21<br>
Implementation: Java HotSpot(TM) 64-Bit Server VM<br>
<br>
<br>
Willem<br>
<br>
On 2011/09/03 09:10 PM, Dmitriy Shabanov wrote:
<blockquote
cite="mid:CADD4p=6sT...@ma..."
type="cite">eXist version, please?<br>
<div><br>
</div>
<div>That issues was discuses and it should be fixed for 1.4.1 <br>
</div>
<div><br>
</div>
<div class="gmail_quote">On Thu, Sep 1, 2011 at 12:14 PM, Willem
van der Westhuizen <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:wav...@gm...">wav...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">I want to
report some issues with backup and restores for your
consideration.<br>
<br>
We have recently had two production databases that developed
errors in the dom.dbx (as reported in the report.log). The
causes for these errors were external, a hard drive filling up
unexpectedly, and a problematic xquery locking up the database
repeatedly leading to forced shutdown and restart sequences
over a period of time. In both cases the backup / restore
functions partially failed.<br>
<br>
We noticed that in the presence of these dom.dbx errors the
backups generated were becoming unreliable. Backups generated
from the backup.sh would exit prematurely, excluding large
amounts of data, and backups triggered through the user
interface failed in two ways:<br>
<br>
1. In one case it exited completely before finishing leaving
an invalid zip file. Fortunately, in this case the backup.sh
backup worked correctly and we could restore the database
completely.<br>
<br>
2. In the other case the data in the zip file was complete,
but there were inconsistencies in the __content__.xml file
entries that would omit all sub-collections of a particular
name. In this case all sub-collections with the name
"workspace" were present in the data backed up, but absent in
the __content__.xml, hence not restoring when we restored the
database. There were another few sub-collection terms that had
the same problem. We were able to restore the database in the
end by creating restore shellscripts for each "workspace"
sub-collection, and restoring them individually. The bulk of
the database consist of collections for which the basic
structure is repeated. It seems to happen that if there is a
dom.dbx corruption on one of these sub-collections, all the
other collection structures with the same sub-collection is
affected when creating the __content__.xml file.<br>
<br>
It is always best to try and prevent dom.dbx errors. But it
seems that there might be some ways in which the backup and
restore procedures could be improved, particularly not to make
the creation of the __content__.xml dependent on the possibly
broken indexes. Since the data is still present, it should be
possible to create the __content__.xml in a way that would not
be affected by index corruptions.<br>
</blockquote>
</div>
<br>
-- <br>
Dmitriy Shabanov<br>
</blockquote>
<br>
</body>
</html>
|