Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Florian, 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. Thanks, Doug -----Original Message----- 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: > All, > > 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. Cheers, Florian -- : 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 http://lists.linbit.com/mailman/listinfo/drbd-user