Recently, Dan wrote a great piece on testing network failures with NuoDB's support for geo-distribution. If you haven't read it, then go do that right now. It's cool, and it illustrates pretty clearly how you can tune the rules for durability based on awareness of regions .

We've made our tools region-aware: you can define where your database is running and what the criteria are for acknowledging commit back to a client. So in Dan's test, he simulated a network partition that

In NuoDB 2.0.1, a region is a property that represents a geographic location for the database. Such locations might include a data center in a major city, country, or building location . A single NuoDB database can have multiple distinct regions. In addition to representing a location, regions can also be used to enforce database

Hello, blog readers. Some of you may know that Kyle Kingsbury of jepsen fame turned the baleful eye of his test framework against NuoDB 1.2. Specifically, the jepsen test attempts to quantify how a system with durability guarantees behaves in the presence of short-lived network partitions. Unfortunately, the jepsen tests ran into node instability issues while testing was underway. Since the big push for 2.0.x is for good multiple-datacenter support, we have been looking at this stuff pretty closely (in between all the other stuff we're working

For NuoDB, it is important that Transaction Engines (TEs) and Storage Managers (SMs) communicate effectively with each other over a network. These interconnected nodes form the back-end fabric that a database instance rests on. Although modern day networks are fairly reliable, there is always the risk that communication between database nodes is affected by either a break in