Before we get to Data Redundancy, it’d be useful to understand the architecture options available to us. Let’s start with ‘2+0’.
In 2+0, we have the licence node (as always), and then 2 data nodes in the cluster (hence the 2). There is no failover node (hence 0). As you can see below…
So what is data redundancy? Data redundancy is essentially storing multiple “copies” of the data on other nodes in case the primary keeper of that data fails.
Each cluster node employs at least one Master Segment, where the data is stored. In our example, as above, we are running a 2+0 architecture, which consists of Node 11 and Node 12. Both are “Active” nodes.
Node11 has Master Segment 11 and Node 12 has Master Segment 12. Both segments are sized at 4GB a piece. In this instance we are running a Redundancy 1 approach. Redundancy 1 means that each node must remain online for the data to be accessible. There are no Slave Segments or copies. If for whatever reason Node 11 became inoperable, the data from Node 11 is at risk, and cannot be recovered, until that node has been repaired, or a backup is available.
Essentially in Redundancy 1, there is no database redundancy.
Next time, we’ll focus on a more robust Redundancy 2 (or more) approach.