[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] How (not) to destroy a PostgreSQL db in domU on powerfail
On 03/04/2009 08:28 PM, Javier Guerra wrote: On Wed, Mar 4, 2009 at 11:35 AM, Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx> wrote:I wonder why there's no documentation about this problem. There are people using XEN in production machines - are they not scared by the actual behaviour? Even if I have UPSes and whatever, a crash can always occur. I have a customer who wants to use XEN to replace 10 small servers by a single one, but currently I'm reluctant to recommend XEN because I worry about the data. Imagine you have 10 servers not coming up after a problem - it could take hours to get every single server up and running again.it certainly warrants more investigation. but i guess very few production machines are using imagefiles on top of XFS. the common scenarios are either block devices or imagefiles on top of OCFS/NFS/ext3 But are we sure that it cames from XFS ?Mike seems to describe that he has everything OK with the requirement of XFS. so as I said previously either XFS is doing nasty things when it's in XEN or it is LVM that is doing nasty things in XEN or LVM+XFS ... BTW his first hypothesis was that XEN was lying about fsync, which I guess is not that simple but is at the end something approching. In fact it could be quite interesting (but a bit time consuming) to have a normal linux installation with XFS and postgresql and stress it a little bit (otherwise I guess that you won't face the problem) and meanwhile unplug it. And do the same with XFS + LVM. And one more test with XEN+XFS in domU+postgresql in domU.I insists on the fact that the postgresql should be stressed otherwise data won't be much modified and no nearly no chance of corruption. Matthieu. _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |