Hello, graph-wrangling, database-lovin’ folks out there! It’s been a long winter for us all, but we’ve made the best out of the cold, dreary days to bring you a whole new bag of tricks to keep you occupied for a while. Without further ado, we’re happy to announce that Memgraph 1.3 is officially out!
If there’s one thing we’re proud of, it’s that from now on, the all-new replication feature will enable you to copy and sync your Memgraph database to multiple servers to ensure your data is always available even if your main server goes down.
Of course, we’ve thrown in some extra goodies to spice things up, so read on and bon appetite!
Starting with this release, if you’re a Memgraph Enterprise user, you’ll be able to sync your data between Memgraph instances that run on different machines. In other words, using the replication feature, you’ll be able to create and run clusters of nodes running synced Memgraph instances, ensuring high availability of your graph data.
We provide the main-replica cluster node relationship model (aka leader-follower). A node may take on the role of the main (containing data to be replicated to other nodes), and the nodes that take on the role of replicas work in concert with the main to reconstruct the data present on the main, and keep in sync with it.
To sync data, you’ll be able to choose between the sync, async and semi-sync mode, depending on how hard your consistency requirements are.
This simple but powerful setup enables you to create highly flexible and fault-tolerant clusters that can be easily configured and deployed anywhere!
“How does it work and how can I try it out?”, you may ask. Head on over to the reference guide for a more in-depth explanation of replication, and check out the how-to guide to get you replicating in no time!
Memgraph uses snapshots and WAL files as durability files. These are used to reconstruct the database to the most up-to-date version. Up to now, there was no reliable way to back up those durability files while an instance is running, so to back up a database, one had to either dump it (using the
DUMP DATABASE query), or kill the instance, and then back up the durability files.
To make a live backup easier, we added a locking query
(LOCK | UNLOCK) DATA DIRECTORY that does just what it says - it prevents the instance from deleting durability files from it, giving the user the opportunity to back them up without fear of data loss. No more backup roulette!
We’ve also improved the logging, which is now both faster and more configurable. Now the user can control the level of logging with the
--log-level flag. No more techno gibberish when you don’t want it, and more gibberish when you need it!
We’ve gotten around to implementing the so-called read-write type deduction properly. We faked it before, just to appease the Neo4j driver gods. Turns out, this type can be actually useful! For example, we use the type of the query to forbid write queries on replicas. Nifty, right?
Go on, try it out! You can download the 1.3 version.
If you catch any bugs or generally weird behavior, please drop us a line on our forum.
Check out what it takes to develop a recommendation engine with graph analytics
Join the annual Hacktoberfest and contribute to open source projects