A simple workaround is to make sure we always have at least one snapshot file before upgrading (e.g. we can use a small snapCount to force snap generation). Though from user perspective this is not ideal, but at least this would unblock the upgrade.
I'll create a JIRA so we can discuss what's the best to address this issue. On Mon, Jun 4, 2018 at 11:32 PM, Matteo Merli <[email protected]> wrote: > That is correct, there are only a few transaction so the snapshot has not > been triggered yet. > > The question is more on how to plan for seamless upgrade, from 3.4.10 to > 3.5.x, from an end users perspective. > > On Mon, Jun 4, 2018 at 11:15 PM Michael Han <[email protected]> wrote: > >> Hi Matteo, >> >> Maybe your ZK instance did not take a snapshot at all - it's possible if >> your total number of transactions less than the configured snapCount >> (default value is 10000) at the time you are doing upgrade. You could check >> your transaction log file and the snapCount configuration see if this is >> the case or not. >> >> >> On Mon, Jun 4, 2018 at 10:02 PM, Matteo Merli <[email protected]> wrote: >> >>> >>> >> Also can you advice the steps for people who using 3.4.x to upgrade >>>> to 3.5.4-beta >>>> >>>> The only catch I remember is that if you are using a version older than >>>> 3.4.6, you'd need to upgrade through 3.4.6 first before upgrading to 3.5.x, >>>> if you are doing a rolling upgrade and want to keep the liveness of the >>>> quorum. See more https://zookeeper.apache.org/doc/r3.5.3-beta/ >>>> zookeeperReconfig.html#ch_reconfig_upgrade. >>>> >>> >>> >>> Hi Michael, >>> >>> This is happening upgrading from 3.4.10 to 3.5.4. It's single node >>> embedded ZK server, part of a self-contained standalone service. >>> >>> Definitely , in 3.4.10 single mode, the snapshot dosesn't get created on >>> bootstrap. >>> >>> Thanks, >>> Matteo >>> -- >>> Matteo Merli >>> <[email protected]> >>> >> >> -- > Matteo Merli > <[email protected]> >
