[Drbd-dev] [PATCH] drbd-utils: Fix the default node id initialization when upgrade v8 to v9
nwang at suse.com
Wed Jan 18 04:14:10 CET 2017
>>> On 1/16/2017 at 6:35 下午, in message <20170116103502.GF9172 at soda.linbit>,
Lars Ellenberg <lars.ellenberg at linbit.com> wrote:
> > > Also, IMO, in virtually all 8 -> 9 upgrade scenarios, you are better off
> > > creating new DRBD 9 meta data instead of trying to "convert”.
> > Is there a technical reason
> There are two basic scenarios, "rolling" upgrade,
> and "stop, replace, and restart the world".
> "stop the world" obviously means downtime.
> But for the "rolling" upgrade,
> you need more steps and at least a switchover,
> which typically also implies a downtime.
> My preferred upgrade procedure would be "replace the world"
> * make sure all data is "stable" and in sync
> * stop all services (yes, that means a short down time)
> * upgrade modules
> * recreate meta data, and prepare to skip the initial sync,
> because we know everything is in sync (see first step)
> potentially allocating more bitmap slots in preparation for N > 2.
> * bring it all online.
> If that is not acceptable, or you think the rolling upgrade incurs less
> service interruption, you go with the "upgrade meta data in place"
> procedure, and hope we got that right :-)
The rolling upgrade as long as the network protocol support can
shorten the downtime to the switch-over time. If all data is in sync,
i think the md(activity log and bitmaps) is safe to be replaced.
So far, for all the scenarios i tried, both "convert meta data" for still
2 nodes and "replace meta data with a new one" for adding more nodes
works for a rolling upgrade on secondary node when all data is in sync:)
More information about the drbd-dev