| title | author | authorURL |
|---|---|---|
High Availability Update |
Mark Wylde |
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.
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_ONcan 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.
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.
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.
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.
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.