Thanks Shawn. That makes sense. On Wed, May 9, 2018 at 5:10 PM, Shawn Heisey <apa...@elyograg.org> wrote:
> On 5/9/2018 2:38 PM, Andy C wrote: > > Was not quite sure from reading the JIRA why the Zookeeper team felt the > > issue was so critical that they felt the need to pull the release from > > their mirrors. > > If somebody upgrades their servers from an earlier 3.4.x release to > 3.4.11, then 3.4.11 might be unable to properly read the existing data > because it'll be looking in the wrong place. Worst-case scenario could > result in all data in a ZK ensemble disappearing, and the admin might > have no idea why it all disappeared. (the data would probably still be > recoverable from the disk) > > That's why it was pulled. > > > It does present something of a PR issue for us, if we tell our customers > to > > use a ZK version that has been pulled from the mirrors. Any plans to move > > to ZK 3.4.12 in future releases? > > There should be no issues with running 3.4.12 servers with the 3.4.11 > client in Solr. Other version combinations are likely to work as well, > though there are typically a lot of bugfixes included in later ZK > releases, so running the latest stable release is recommended. > > The ZOOKEEPER-2960 problem is ONLY on the server side. As I mentioned > before, the ZK version information in the release notes is not a > recommendation, it serves to inform users what version of ZK is included > in Solr. > > Thanks, > Shawn > >
