Indication in ChangeLog to identify when FDB went private

Using FoundationDB
2

3.0.7 was the last release before we went private. In addition to the change log, here is a high level summary of what has changed.

  • Backup and restore have been improved immensely. In 3.0.7 restore was done by a single writer, making it extremely slow. Backup could only be done to files, and required you to manually restart every few weeks so backups would not get too large.

  • Added asynchronous replication to a read-only replica of the database. Basically you can stream all of the mutations from one cluster to a different cluster. The second cluster will generally be less than a second behind the primary. If the primary dies, and you switch to the second cluster you will have lost the last few committed transactions but otherwise your data will be consistent (you still have the ACI of ACID). If both cluster are healthy you can seamlessly switch which one is primary without losing data. Check out https://apple.github.io/foundationdb/backups.html for more information.

  • Improved performance and reliability, especially when recovering from machine failures. In 3.0.7 there were a number of different pathologies that could cause either lower throughput or temporary unavailability while the database was healing from a failure. We have also had a lot more experience running the software than when we were private, which has overall improved the quality of the software.

  • Improved the performance of the storage engine. If you have a cluster running 3.0.7 and upgrade to 5.1.5 you will need to run “configure ssd” to take advantage of the storage engine improvements. The 3.0.7 storage engine also did not have checksums.

  • Added version stamp operations. https://apple.github.io/foundationdb/api-python.html#atomic-operations

  • Added the multi-version client support, for seamless upgrades. Clients can load client libraries from two different versions of FoundationDB using environment variables, and will automatically connect using the correct library depending on the version of the server. A typical upgrade will involve first loading both client libraries on the client. Then loading the new server binary on all the machines, and setting up fdbmonitor so that it will switch to the new version the next time the process restarts. Finally you can use fdbcli to restart all of the processes in the cluster simultaneously to switch the cluster to the new version. https://apple.github.io/foundationdb/administration.html?#upgrading-foundationdb

  • Improved the Java bindings.

  • Enabled better monitoring of FoundationDB clusters by increasing the amount of information reported in status.

  • Added the ability to store a sample of client transactions to help debug client performance issues. This can be useful if a lot of your transactions are conflicting and you do not know why. You can turn this on from fdbcli.

5 Likes