Release date of version 6.0

(Tobad357) #1

Are there any timelines for version 6.0 and also is there a document outlining the major developments in that version?

(Evan Tschannen) #2

When we create a pre-release tag on a release branch in GitHub it means any future versions on that release branch will be protocol compatible with that version. This generally means that the release branch is feature complete, and we are going to start vetting it in real world environments.

The 6.0 release is unique because the new multi-region support it provides requires testing it in many more deployment configurations than was previously necessary. Almost all of the changes on the 6.0 branch since 6.0.0 have been made in response to problems found by this new testing.

The main remaining issue blocking a 6.0 release is tracking down a memory leak on the transaction logs. We are optimistic we could have a release out in the next few weeks.

You can check out the release notes for the 6.0 release here:

(Tobad357) #3

Thanks and great news

(Clement Pang) #4

Is there any risk to running 6.0 at this point? Asking since there’s a protocol change and we make custom builds for live 3.x to 5.x migrations (which is still pending validations) but wondering if we should just go directly to 6.0 and skip a multi-version upgrade maneuver (for 50+ clusters). :slight_smile:

(Evan Tschannen) #5

Unfortunately, 6.0 is not compatible with 3.x clusters, so you will have to update to 5.x before upgrading to 6.0 anyways.

There is not a lot of risk with 6.0, especially if you are not using the new multi-region configurations, however I would still recommend waiting a few weeks for us to officially bless it. I doubt you want to be the first users running a new version at a large scale. :grinning:

(Clement Pang) #6

Oh I mean whether I should make 3.x compatible 6.x releases as our upgrade path. want to save us from having to upgrade immediately again from 5.2 to 6.0 that’s all.

(David Scherer) #7

Does 6.0 provide everything needed for satellite replication in production? Is there a practical way to do a manual ACI recovery in an emergency, for example? If so, it would be really good to get something written up about the benefits of the new replication modes and how to set them up in public clouds. If not, what’s not there yet?

(Evan Tschannen) #8

6.0 does provide almost everything needed for satellite replication. The biggest flaws are:

  1. It does not allow arbitrary configurations, you can only use it exactly two regions.
  2. When a region is down, performance of the transaction logs will degrade to about 1/3 their usual bandwidth.

Unfortunately support for manual ACI recovery is not quite ready. The force_recovery_with_data_loss command exists in fdbcli, however correctness testing of the feature turned up data inconsistency if a storage server from the dead datacenter rejoins the cluster at the wrong time. Fixing the bug will require a protocol change, so we have to wait for 6.1 before advertising it.

I will add documentation about all the new multi-region configurations soon.

(Alvin) #9

Hey Evan, thanks for sharing! We are actively evaluating multi-region features FDB 6.0 provides. Do you know where has the most info about it at the moment before the official document is ready? Thanks!

(Alex Miller) #10

Until Evan writes the docs, which should happen as soon as he stops discovering and fixing bugs in the 6.0 release, the Multi-DC replication thread probably has the most information.

(Alvin) #11

Thanks Alex, I have ready that thread before and it is very helpful. Looking forward to seeing the official 6.0 doc!