Re: [Drbd-dev] [PATCH] drbd-utils: Fix the default node id initialization when upgrade v8 to v9

["Nick Wang" <nwang@suse.com>]

>>> On 1/16/2017 at  6:35 下午, in message <20170116103502.GF9172@soda.linbit>,
Lars Ellenberg <lars.ellenberg@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:)

Best regards,
Nick