[DRBD-user] How to use drbd to upgrade highly availableapplication?
dknight at wsi.com
Fri Sep 5 22:04:05 CEST 2008
I intentionally left out the data replication step to try to keep it simple. Guess that didn't help. The nature of the data is that its only valuable if its less than so many hours old (no solid gauge as to how many hours, but less than a day or so).
I can see the confusion over "Primary" and "Secondary". The terms as used in my description refer to the host itself, not the status in DRBD. I should have replaced them with something like:
Primary = Current live application host
Secondary = Target (standby) upgrade host
Does that help? The main information I'm looking for is the validity of the commands I'm proposing to use, and the order in which I execute them.
From: drbd-user-bounces at lists.linbit.com [mailto:drbd-user-bounces at lists.linbit.com] On Behalf Of Florian Haas
Sent: Friday, September 05, 2008 3:55 PM
To: drbd-user at lists.linbit.com
Subject: Re: [DRBD-user] How to use drbd to upgrade highly availableapplication?
Knight, Doug wrote:
> I am working on a strategy to upgrade my real time highly available
> application that uses a drbd resource as its file system for its
> database. I am using drbd 8.2.5 and heartbeat 2.1.3, on a CentOS 5.2
> server pair. The idea goes something like this:
> 1. Set drbd on the Primary host to StandAlone, so that the real time
> app continues to run, but releasing the drbd resource on the
> Secondary host
> 2. Mount the drbd resource on the secondary, delete the database
> 3. Upgrade the real time app and its database on the Secondary host
> 4. Switch the running real time app to the Secondary host
> 5. Reconnect the drbd resource on the Primary host to the Secondary
> host, and resync from Secondary to Primary
This description is likely to confuse everyone including yourself,
because you are referring to a host that most of the time will be in
Primary mode as "Secondary" and vice versa.
And before I get into this further, perhaps you want to reconsider
whether you really want to throw away all modifications made to the
database between the time when you break your DRBD pair, and the point
where you pull your app back up on the updated host. It seems like
you're trying to minimize down time for the price of throwing away data,
and that doesn't seem like a sound move to me. If I am understanding
your planned approach correctly, that is. If I'm not, please clarify.
Just my €.02.
: Florian G. Haas
: LINBIT Information Technologies GmbH
: Vivenotgasse 48, A-1120 Vienna, Austria
When replying, there is no need to CC my personal address.
I monitor the list on a daily basis. Thank you.
LINBIT® and DRBD® are registered trademarks of LINBIT.
drbd-user mailing list
drbd-user at lists.linbit.com
More information about the drbd-user