Open topic with navigation
Examples of Failure Scenarios
Here are some examples of failure scenarios.
A Minimally Redundant database provides data redundancy. This means that data is duplicated in two or more archive areas. It does this with two TEs and two SMs, typically running on two hosts, one TE/SM combination on each host. If one TE/SM combination is gracefully shut down, the database is still available via the other TE/SM combination. However, if there is an interruption in service of one of the hosts, the database will be left in the following state:
ping-timeout) would cause the processes on the remaining host to shut down as well because they are also in a minority.
The scenario described above leads to the conclusion that high availability requires at least a three machine setup. The following must be done:
ping-timeoutdatabase option to enable engine failure detection.
commitdatabase option to guarantee that all transactions are replicated across regions, or allow that they do not have to be replicated.
A network partition refers to the situation where a network device fails and certain nodes in the network can no longer communicate with other nodes. If this situation occurs, two things can happen with your NuoDB domain.
ping-timeoutis not set) and if the commit protocol does not require commits across multiple storage managers, then the database could go into split-brain mode. This means that depending on which database process (transaction engine) your client accesses, on one side of the partition or the other, it will have a different view of the database and incur changes in one place and not the other. In other words, it is as if you have two databases instead of one.
ping-timeoutis set) and there are an even number of hosts on each side of the partition, then the domain will shut down.