5.0.10 Release Notes

We are pleased to announce the release of EventStoreDB 5.0.10!

This release includes some stability backports from version 21.2.

It is available for the following operating systems:

• Windows
• Ubuntu 16.04
• Ubuntu 18.04
• CentOS 7 (Commercial version)
• Amazon Linux 1 (Commercial version)
• Amazon Linux 2 (Commercial version)
• Oracle Linux 7 (Commercial version)

Where Can I Get the Packages?

Downloads are available on our website.The packages can be installed using the following instructions.

curl -s https://packagecloud.io/install/repositories/EventStore/EventStore-OSS/script.deb.sh | sudo bash sudo apt-get install eventstore-oss=5.0.10-1

choco install eventstore-oss -version 5.0.10

dotnet add package EventStore.Client --version 5.0.10

Upgrade Procedure

• Pick a node (Start with follower nodes first, then choose the leader last)
• Stop the node, upgrade it and start it

Changes

Auto-Compatibility Mode

The upgrade from EventStoreDB v5 to v20 and above will typically require an update to the TCP clients' connection strings. This is mainly due to the fact that the v20 servers are secure by default, whereas the v5 servers are not.

This means that the standard upgrade procedure would require you to update clients and connection strings during the server upgrade. This is a disruptive operation, and we want to make this process easier.

To start with this, we have added an auto compatibility mode for connecting to a cluster with ClusterDNS discovery. This mode determines whether to discover a cluster over secure or insecure HTTP. It also sets the host header appropriately to work around a bug in Mono on v5 servers.

When it's enabled, it will do the following:

1. On the first discovery attempt, it will try both a secure and an insecure request against the server.
2. Whichever request succeeds will set whether gossip is to be done over HTTP or HTTPS.
3. From there, the connection can be used as normal.

It does not affect whether the client should connect using secure or insecure TCP connections, but this is planned for future versions.

To use the auto-compatibility mode, you must be using dns discovery:

• connection string:

  “ConnectTo=discover://{address}”

• ClusterSettings:

  “DiscoverClusterViaDns()”

And it can be enabled with:

• connection string:

  “CompatibilityMode=auto”

• ConnectionSettings:

  “SetCompatibilityMode("auto")”

As an example, when connecting to a v20 or higher cluster from a v5.0.10 client:

Connection String:

ConnectTo=discover://{dns_address}:2113;TargetHost={dns_address};UseSslConnection=true;CompatibilityMode=auto;

Connection Settings:
var connectionSettings = ConnectionSettings.Create()
    .SetCompatibilityMode("auto");
var clusterSettings = ClusterSettings.Create()
    .DiscoverClusterViaDns()
    .UseSslConnection({dns_address}, true)
    .SetClusterDns({dns_address})
    .SetClusterGossipPort(2113); 

Thanks to @megakid for the initial work on this feature!

Heartbeat Timeout Improvements

One of the improvements backported from 21.2.0 was the heartbeat timeout improvements. In a scenario where one side of a connection to Event Store is sending a lot of data and the other side is idle, a false-positive heartbeat timeout can occur for the following reasons:

• The heartbeat request may need to wait behind a lot of other data on the send queue on the sender’s side or on the receive queue on the receiver’s side before it can be processed.
• The receiver does not schedule any heartbeat request to the sender as it assumes that the connection is alive.
• The sender’s heartbeat request can eventually take more time than the heartbeat timeout to reach the receiver and be processed causing a false-positive heartbeat timeout to occur.

In this release, we have extended the heartbeat logic by proactively scheduling a heartbeat request from the receiver to the sender to prevent the heartbeat timeout. This should lower the number of incorrect heartbeat timeouts that occur on busy clusters.

Please see the documentation for more information about heartbeats and how they work.

Read Index Cache Capacity

The Read Index Cache Capacity option which was released in 21.2.0 has been backported to this release. Event Store caches the metadata for streams that have been read recently to improve read and write performance.

While the default capacity of 100,000 should be enough for most situations, there are cases where it can be beneficial to increase the cache capacity. For example, if you’re going to be performing a lot of reads and writes to the same 200,000 streams for a period of time.

We’ve added the “StreamInfoCacheCapacity” option to allow tuning this cache. Please be aware that increasing this number will cause EventStoreDB to use more memory.

Event Store 5.0.10 Changelog

• #2761 Expose option for Stream info cache capacity

• #2791 Cluster stability fixes

• #2827 Compatibility mode (thanks to @megakid for the contribution!)

• #2829 Allow 50 logical TB of log size

• #2836 Fix a TCP regression

Documentation

Documentation for EventStoreDB can be found here.

If you have any questions that aren't covered in these release notes or the docs, please feel free to reach out on Discuss, GitHub or Slack.

Providing Feedback

If you encounter any issues, please don’t hesitate to open an issue on GitHub if there isn’t one already.

Additionally, there is a fairly active Discuss channel, and an #eventstore channel on the DDD-CQRS-ES Slack community.