Use Case 4: Drop a Region

An organization deploys three on-premise KVStores, one each at Frankfurt, London, and Dublin. As per their requirement, they created a few MR Tables in all three regions. As part of business down-sizing, they decided to exclude the Dublin region resulting in a two-region NoSQL Database. In the next few topics, you learn how to drop an existing region from the NoSQL environment that you had set up in the previous sections.

If you have not set up a Multi-Region NoSQL Database with three regions already, execute the steps outlined in:

Prerequisites

Learn about the conditions to be satisfied before dropping a region from a Multi-Region NoSQL Database.

Before removing a region from a Multi-Region NoSQL Database, it is recommended to:

Stop writing to all the MR Tables linked to that region.
Ensure that all writes to the MR Tables in that region have synchronized with other regions. This helps in maintaining consistent data across the different regions.

Note:

As of the current release, there is no provision in Oracle NoSQL Database to make a table read-only. Hence, you must stop writes to the identified MR Tables at the application level.

Isolate the Region

Learn how to isolate a region from a Multi-Region NoSQL Database.

When you decide to drop a region, it is a good practice to isolate that region from all the other participating regions. Isolating a region disconnects it from all the MR Tables in the Multi-Region NoSQL Database.

For example, isolating the DUB region ensures that:

DUB cannot see writes from the remaining regions, that is, FRA and LND.
Regions FRA and LND cannot see writes from the DUB region.

Note:

Even though it is not mandatory to isolate the region before dropping it from a Multi-Region NoSQL Database, this is considered a cleaner approach and hence suggested.

Isolating a region from the Multi-Region NoSQL Database environment involves two tasks. They are:

Dropping the target region from all the MR Tables in the other participating regions.
1. To drop the DUB region from the Users MR Table in FRA and LND regions, execute the following command from each region's kv prompt.
```
kv-> execute 'alter table Users drop regions DUB'
```
2. Optionally, you can execute the following command to verify that the region is dropped successfully.
```
kv-> show table -name Users
```
Dropping all the other regions from all the MR Tables in the region to be isolated.
1. To drop the FRA and LND regions from the Users MR Table in the DUB region, execute the following command from kv prompt.
```
kv-> execute 'alter table Users drop regions FRA, LND'
```
2. Optionally, you can execute the following command to verify that the regions are dropped successfully.
```
kv-> show table -name Users
```

Verifying that the DUB region is dropped from the Users table in the Frankfurt (FRA) region:

kv-> show table -name Users 
{ 
  "json_version" : 1, 
  "type" : "table", 
  "name" : "Users", 
  "shardKey" : [ "id" ], 
  "primaryKey" : [ "id" ], 
  "fields" : [ { 
    "name" : "id", 
    "type" : "INTEGER", 
    "nullable" : false, 
    "default" : null 
  }, { 
    "name" : "name", 
    "type" : "STRING", 
    "nullable" : true, 
    "default" : null 
  }, { 
    "name" : "team", 
    "type" : "STRING", 
    "nullable" : true, 
    "default" : null 
  } ], 
  "regions" : { 
    "2" : "LND", 
    "1" : "FRA" 
  } 
}

Verifying that the DUB region is dropped from the Users table in the London (LND) region:

kv-> show table -name Users 
{ 
  "json_version" : 1, 
  "type" : "table", 
  "name" : "Users", 
  "shardKey" : [ "id" ], 
  "primaryKey" : [ "id" ], 
  "fields" : [ { 
    "name" : "id", 
    "type" : "INTEGER", 
    "nullable" : false, 
    "default" : null 
  }, { 
    "name" : "name",
    "type" : "STRING",
    "nullable" : true,
    "default" : null
  }, { 
    "name" : "team", 
    "type" : "STRING", 
    "nullable" : true, 
    "default" : null 
  } ], 
  "regions" : { 
    "2" : "FRA", 
    "1" : "LND" 
  } 
}

Verifying that the FRA and LND regions are dropped from the Users table in the Dublin (DUB) region:

kv-> show table -name Users 
{ 
  "json_version" : 1, 
  "type" : "table", 
  "name" : "Users", 
  "shardKey" : [ "id" ], 
  "primaryKey" : [ "id" ], 
  "fields" : [ { 
    "name" : "id", 
    "type" : "INTEGER", 
    "nullable" : false, 
    "default" : null 
  }, { 
    "name" : "name", 
    "type" : "STRING", 
    "nullable" : true, 
    "default" : null 
  }, { 
    "name" : "team", 
    "type" : "STRING", 
    "nullable" : true, 
    "default" : null 
  } ], 
  "regions" : { 
    "1" : "DUB" 
  } 
}

Drop MR Tables in the Isolated Region

After you ensure that the region to be dropped is isolated, you can drop all the MR Tables created in that region safely. Dropping an MR Table is exactly similar to dropping a local table.

For example:

To drop the Users MR Table from the DUB region, execute the following command from the kv prompt.
```
kv-> execute 'drop table Users'
```
Optionally, you can execute the following command to verify that the Users table is dropped successfully.
```
kv-> show tables
```

Drop the Isolated Region

Finally, you can drop the region from all the participating regions.

Note:

Dropping an isolated region is not mandatory. You can retain the isolated region without dropping from other regions, for any future use.

To drop the isolated region from each participating region:

Connect to the kv prompt from the local region, and connect to the local KVStore.
To drop DUB from the local region, execute the following command.
```
kv-> EXECUTE 'DROP REGION DUB'
```
Optionally, you can execute the following command to ensure that the DUB region is dropped successfully.
```
kv-> execute 'show regions'
```

Verifying that the DUB region is dropped from the Frankfurt (FRA) region:

kv-> execute 'show regions' 

regions 
 FRA (local, active) 
 LND (remote, active)

Verifying that the DUB region is dropped from the London (LND) region:

kv-> execute 'show regions'
 
regions 
 LND (local, active) 
 FRA (remote, active)