| Re: Re: vzmigrate standby mode [message #42743 is a reply to message #42742] |
Wed, 18 May 2011 11:30   |
Tim Small
Messages: 24
Registered: April 2011
|
Junior Member |
|
|
On 18/05/11 11:54, Aleksandar Ivanisevic wrote:
> Sterling Windmill <sterling@ampx.net> writes:
>
> [...]
>
>
>> vzctl chkpnt and restore guarantees consistency in that the state of the
>> container is dumped when the checkpoint is created and restored upon
>> restoration of said checkpoint. As long as the dump file and unadulterated
>> filesystem are available, restoration should result in a perfect copy of the
>> container as of when it was checkpointed. That being said, checkpointing
>> makes the container unavailable for a brief period of time and wouldn't be
>> ideal as a means of taking backups of production systems on a
>> regular basis.
>>
> Yes, sorry, forgot to mention that. Unfortunately there is no easy
> solution for applications like databases that constantly change big
> files. You simply have to handle them separately, either by
> replication on a database level or by putting the disk in DRBD or SAN.
>
We use a hacked version of mylvmbackup to backup an entire container.
Each container lives on its own logical volume, and the process calls
into the logical volume to ask the database (mysql in this case) to make
its data-on-disk consistent. At this point, and LVM snapshot is taken,
then mysql is told it can carry on writing to disk. The LVM snapshot is
then fscked and mounted on a different mountpoint, once mounted, the
contents are rsynced to the standby machine, and the lvm snapshot is
removed.
I'm guessing that this could be combined with a vzctl chkpnt, but I
haven't looked into that.
Tim.
--
South East Open Source Solutions Limited
Registered in England and Wales with company number 06134732.
Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ
VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
