[DRBD-user] Replacing larger hard drives while keeping services available?

Clint Rosander clint at vmix.com
Mon Apr 21 18:11:44 CEST 2008

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Hello Leroy,

Thanks for you input. However, I have a few questions with some of  
your steps. Please see my comments below...

On Apr 18, 2008, at 2:24 AM, Leroy van Logchem wrote:

>
>>  faced with the issue of needing to replace the current hard- 
>> drives with much larger ones and need to do this while keeping the  
>> MySQL instance available.
>
> To avoid:
> - mixing up the partitions
> - tricky filesystem growing
> - running out of time during the migration

What is the factor contributing to time running out in this situation?

> You could:
>
> 1) Make sure the secondary node does not reconnect by:
> -- Changing /etc/drbd.conf ip and/or port numbers to none existing  
> ones
> -- Disable automatic starting of drbd and heartbeat etc
> 2) Replace the disks and configure the partitions for drbd usage
> -- Perhaps setup seperate metadata

I'm fine up to this step. However, the following two steps don't seem  
to contribute to keeping the services (MySQL) up running and  
available for requests the entire time. Unfortunately, that is the  
requisite I'm working under. What is see is that this will indeed  
involve some sort of downtime on the instance of the database server,  
either through locking to get a consistent snapshot/backup, or  
between the time delta of time from getting the 'final hotcopy',  
shutting down the initial primary, and starting up the new box (read  
old box with new/larger hard drives) as the new primary. If I'm  
misunderstanding how this would keep MySQL up and running, could you  
please elaborate?

> 3) Manually get drbd running
> -- Force to primary
> -- Create the filesystem(s)
> -- Mount it
> 4) Copy the currently running MySQL to your new setup
> -- By means of rsync and mysqlhotcopy
> -- Change the bind-address so you can test

This will indeed involve some sort of downtime on the instance of the  
database server, either through locking to get a consistent snapshot or

> When it's running fine again then re-enable the service startup and  
> prepare the final fail-over:
>
> 1) Stop everything on the new setup and get back to the original  
> configuration files
> 2) After a final hotcopy, pull the plug on the old primary
> 3) Let the new setup start as primary
>
> (this should be scripted to have the smallest gap possible)
>
> Now the server with the smaller disks can be upgraded. Only redo  
> the partitioning steps, so skip the mkfs. During the long initial  
> sync you might want to limit the bandwidth ( force changing speeds  
> by disconnect/reconnect and drbdadm adjust all etc.. verify by  
> watching /proc/drbd ).
>
> Goodluck,
> Leroy
>
>
>
>
>
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user



Thank you again,

Clint


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20080421/73e7e996/attachment.htm>


More information about the drbd-user mailing list