<< snowcast - Hazelcast Client and the snowcast logo | Home | The Hazelcast Incubator >> | Conferences & TechTalks Calendar | Legal Notice | Google+ Profile | Twitter Page | My Profile Page

snowcast - Migration and Failover

Current Status: Feature Complete

When I started snowcast back at end of 2014 I haven't thought that people will really be interested but most of the times it will work out differently from your imagination. A still fairly small group of interested people showed up and I got a lot of nice words and gratulations for that idea. It seems like it will take off over time.

 

Migration and Failover Support

The last big piece of the puzzle that was a must feature from my side was support for graceful failover on node failures and migration on topology changes. snowcast now supports backups and creates complete backup partitions on other nodes in the cluster. In case of node failures those backups are used to recreate the data to stay in a consistent state. The number of backups is configurable but one backup by default. To find more information about the backup system and how to configure it please read the about backups in the README.

The second thing, migration, handles partition movements when the cluster topology changes and the partition table layout is updated. After new nodes join or old ones leave there, normally, is a migration going on to rebalance the system over all cluster nodes and snowcast now takes place in this process! Please read more about it here.

A short word to split-brain situations:
Those are still not handled gracefully. I have a few ideas how to solve those problems on re-merging the clusters after split-brain cause has been resolved but it wouldn't guarantee the time of the split-brain. I'm open to any kind of idea and suggestion on how to solve that. Split-brain is such a big problem that this alone would make a change for a 2.0 version ;-).

 

Current Status: Feature Complete

On the other hand I steadly worked on the missing features and I'm glad to announce that snowcast seems to me like FEATURE COMPLETE for a first GA release. I will add a lot more code comments, Javadocs to the public API classes and interfaces as well as improve the documentation. To make the documentation as clear as possible I request all people to copy-edit it and either send pull requests on github or create issues.

I plan 2 different release candidates until the final GA release, therefore I added a continuous build server and snapshots are deployed to Sonatypes snapshot repository.

 

Maven Coordinates

As most of you know the Maven repositories went into a de-facto standard over the last years. Next to Maven most build systems for Java build on top of the Maven repository design like SBT, Gradle, Ivy and much more, therefore I decided again to deploy the snowcast artifacts to a Maven repository and eventually the RC and GA releases will go into Maven central for convenience.
The Maven coordinates for the artifacts are available here.

Related Posts
The Hazelcast Incubator
snowcast - Hazelcast Client and the snowcast logo
snowcast - like christmas in the distributed Hazelcast world


Categories : Java, Projects, Other, hazelcast


Avatar: Paulo Pires

Re: snowcast - Migration and Failover

 You can define a quorum of total of n nodes where n = nodes / 2 +1 for the split-brain?

Avatar: Noctarius

Re: snowcast - Migration and Failover

 But it doesn't really solve the time of the split-brain where you might end up assigning the same id twice. What might be interesting is not to assign the logical node IDs serial but randomized, therefore the chance to end up with the same is lower. WDYT?


Add a comment Send a TrackBack