- October 2021
- August 2021
- June 2021
- May 2021
- February 2021
High Availability UpdatePublished by Mark Wylde on 2021-08-11
Over the past few months I've not had the chance to work on canhazdb as much as I'd like, as my projects that use the first prototype (version 7) are still working really well.
But over the last week, I finally got some time to implement events, known as notify
.
Notify
The syntax is still the same as before, but the protocol has now been updated to:
- Use the new lightweight byte syntax, as described in my last blog post
- Each
NOTIFY_ON
can only have oneNOTIFY_PATH
It's working really well, at least for post
's. I still have some work to do to get put
, patch
, delete
working. These are a little more tricky as one command can mutate multiple documents. With a post
, it will only mutate one.
Count
The count
command was very easy to implement. It's basically the same logic as a get
, but instead of returning the documents, it returns just the number from each server.
Lock
Before I could implement the put
, patch
and delete
commands we need locking.
I'm not entirely sure if this lock is needed. But because these commands trigger updates on multiple document replicas, I feel it's important that all replicas contain the same value.
So for now, when one of these three commands is sent, a lock will be placed on the collection while all documents are mutated, and then removed once complete.
I feel like when transactions are implemented further down the line, this could be removed, or at least change shape in some way.
Put, Patch, Delete
The put
, patch
and delete
commands are similar to a post
, but instead of choose three random servers to insert a document, we must go out to all servers and request updates.
With the built in $REPLICATION_FACTOR (currenly 3), if you have 3 or more servers, then each document will be inserted on each of the 3 servers.
So when one of these commands is issued externally, the server looks up every server in the cluster, and forwards the command.
The internal server needs to reply with the number of changes it made. However, it can't simply send how many document where updated. If we have 3 documents, each replicated 3 times, then our total change count would be 9.
Instead, the internal server will only respond with the documents it changed, where it was the first "online" server in the _replicatedNodes
property.
System Statistics
The system.tables
collection has not been implemented at all. I think it will be pretty easy to implement, as most of the logic from v7 can be carried over.