Clustrix announced its nResiliency feature which ensures that the database, and hence the application, remains available in the event of multiple simultaneous server or instance failures.

Available now, nResiliency offers confidence that valuable data is safe and continuously available should two or even more servers (nodes) fail at the same time. Companies can now decide on the maximum number of nodes that could potentially fail in the cluster without losing any data, then ClustrixDB automatically generates the number of data replicas necessary to successfully recover, in the event of multi-node failure.

“Too many companies rely on databases for OLTP applications that are susceptible to even single-node failure,” said Mike Azevedo, CEO, Clustrix. “By offering protection against multi-node failure, we’re offering peace of mind through an easy-to-use feature that would otherwise require IT resources that most companies don’t have and can’t afford. This is critically important for larger scale applications that typically service millions of users like in e-commerce, gaming, adtech and social.”

ClustrixDB was developed to address MySQL’s scale limitations, but its architecture is distinct from other MySQL replacements in that it is designed to “scale out” both writes and reads by adding server nodes. This enables it to scale linearly to the point where there are almost no limits to the number of simultaneous transactions it can handle, with practically imperceptible latency to the end user.

Scale-out ability, combined with the new nResiliency protection against multi-node failure, means that companies can now easily scale to the demands placed on their application by millions of concurrent users. E-commerce sites facing holiday shopping traffic; gaming companies launching a new title; consumer web services and social applications can now all freely match database capacity to demand. Easily add scale when you need it, and then scale-back when you don’t, only paying for the servers you need.

ClustrixDB’s new nResiliency feature provides the ability to define the number of servers in the cluster that can become unavailable simultaneously while ensuring continuous database availability: it is easily configurable according to data sensitivity and criticality.

For example, users may:

- Set MAX_FAILURES at a high number for their high-value data that are necessary to keep mission-critical applications running in the event of simultaneous failures

- Set MAX_FAILURES at a mid-range number for high volume data that are not required to have multiple levels of redundancy

- Set MAX_FAILURES at a low number for high-throughput, ‘fast-lane’ data which can be easily replaced