Zones allow you to spread your store across physical installation locations. The different locations can be anything from different physical buildings near each other, to different racks in the same building. The basic idea is that you can guard against large scale infrastructure disruptions, such as power outages or storm damage, by placing the nodes in your store physically as far apart as is possible.

Oracle NoSQL Database provides support for two kinds of zones. Primary zones contain nodes which can serve as masters or replicas. Zones are created as primary zones by default. Secondary zones can be created when Oracle NoSQL Database is installed or expanded and can only contain read-only replicas.

For details on how to create zones and multi data-center please refer to the admin guide 

Zones


Both types of zones require high throughput network connections to transmit the replication data required to keep replicas up-to-date. Failing to provide sufficient network capacity will result in nodes in poorly connected zones falling farther and farther behind.

For primary zones,the network connections with other primary zones should provide for highly reliable and low latency communication. Doing so allows quick master-failover in case of any failure as well as receive the acknowledgments within the request timeout 

For secondary zones, the nodes in the secondary zones do not participate in master elections or acknowledgments.So, the system can tolerate reduced reliability or increased latency for connections between secondary zones and the primary zones. 

Oracle NoSQL Database tries to physically place at least one Replication Node from each shard in each zone. This guards against losing entire shards should a zone become unavailable for any reason. Refer the guide to know the details of topology related commands.

Multiple data centers or Zones,allow customers to take advantage of the fault isolation provided by separate physical data centers to improve the availability of a store because each Zone has a copy of your complete store, including a copy of all the shards. With this settings, when a zone fails, the ability to write is automatically established as normal master election can be held or quorum is held. However, if quorum is lost because of either total zone failure or planned shutdown, the Failover and Switchover feature introduced can be used.

A Failover is typically performed when the primary zone fails or has become unreachable and one of the secondary zones is transitioned to take over the primary role.

Switchovers can be used after performing a failover (to restore the original configuration) or for planned maintenance. It can be thought of a role reversal between a primary zone and one of the secondary zones of the store. Switchover requires quorum and guarantees no data loss. It is typically done for planned maintenance of the primary system.

For example, suppose a store consists of two primary zones "Manhattan" and "JerseyCity", each deployed in its own physical data center. Additionally, suppose that the "Manhattan" zone fails. Resulting in the failure of all of the associated Storage Nodes and a loss of quorum. In this case, if the host hardware of "Manhattan" was irreparably damaged or the problem will take too long to repair you may choose to initiate a failover. Refer to our admin guide to learn how to perform failover to JerseyCity datacenter and once the fault is recovered how to switchover to Manhattan data center.

Failover interfaces :

  • Diagnose failure: ping or verify configuration
  • Disable failed zones: disable-services
  • Repair admin: repair-admin-quorum
  • Failover to remaining zones: plan failover


Switchover Interfaces :

  • Repair topology (after failover): plan repair-topology
  • Wait for consistency (optional): await-consistency
  • Update topology: topology change-zone-type
  • Switch to new topology: plan deploy-topology