[Koha-devel] mysqldump & restore issues

Christopher Curry ccurry at amphilsoc.org
Wed Sep 29 22:18:28 CEST 2010


Joe,

You were right.  I tried this restore on a physical host and my problem 
disappeared, so I rebuilt the VM with fixed-size storage and confirmed 
that dynamic allocation was the source of the problem.

Cheers,

Christopher Curry
Assistant Technical Librarian / Assistant IT Officer

American Philosophical Society
105 South Fifth Street
Philadelphia, PA 19106-3386
Tel. (215) 599-4299

ccurry at amphilsoc.org <mailto:ccurry at amphilsoc.org>

Main Library number: (215)440-3400
APS website: http://www.amphilsoc.org



On 09/21/2010 04:26 PM, Christopher Curry wrote:
> Joe,
>
> Thanks for the information.  I think I'll just try restoring the 
> mysqldump on a a physical host and see if I have the same problems.  
> If it works, I'll build another VM with fixed-size storage and 
> hopefully that will be the end of my worries.  I'm hoping to not have 
> to look too closely at the InnoDB stuff.
>
> I wasn't aware that dynamic allocation could have this effect.  I was 
> trying to minimize the footprint of the VM image so I could 
> thoughtlessly copy the image to backup my work.  Now that I have the 
> process all mapped out, I should be able to decide on a sufficient 
> size and still have some easy backup capability for templates, et al.
>
> Cheers,
>
> Christopher Curry
> Assistant Technical Librarian / Assistant IT Officer
>
> American Philosophical Society
> 105 South Fifth Street
> Philadelphia, PA 19106-3386
> Tel. (215) 599-4299
>
> ccurry at amphilsoc.org <mailto:ccurry at amphilsoc.org>
>
> Main Library number: (215)440-3400
> APS website: http://www.amphilsoc.org
>
>
>
> On 09/21/2010 11:15 AM, Joe Atzberger wrote:
>> I wouldn't be surprised if this was related to dynamic allocation on 
>> the VM.  Essentially, it can inject a random very large I/O latency 
>> to any operation.  It may also change the hardware model used by the VM.
>>
>> I would recommend looking at InnoDB diagnostics, and possibly 
>> starting up w/ innodb_force_recovery=1 set in my.cnf.  Run "check 
>> table" on each table (or at least the ones you've detected problems 
>> with) for closer analysis.
>>
>> --Joe
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100929/ea931ea6/attachment.htm>


More information about the Koha-devel mailing list