Previous Next JavaScript must be enabled to correctly display this content

## Using a New Storage Node

To replace a failed Storage Node by using a new, different Storage Node (node uses different host name, IP address, and port as the failed host):

1. If you are replacing hardware, bring it up and make sure it is ready for your production environment.

2. On the new, replacement node, create a "boot config" configuration file using the `makebootconfig` utility with the following commands. Enable the security configuration option in the new node. Do this on the hardware where your new Storage Node runs.

       > mkdir -p KVROOT     (if it doesn't already exist)
       > java -Xmx64m -Xms64m \
       -jar KVHOME/lib/kvstore.jar makebootconfig -root KVROOT \
                                                  -port 5000 \
                                                  -host <hostname> \
                                                  -harange 5010,5020 \
                                                  -capacity 1 \
                                                  -admindir /export/admin1 \
                                                  -admindirsize 3_gb \
                                                  -store-security enable \
                                                  -storagedir /export/data1 \
                                                  -storagedirsize 1_tb \
                                                  -rnlogdir /export/rnlog1

3. Create the security directory under KVROOT in your new node.

       > cd KVROOT
       > mkdir security

4. Copy the security directory from a healthy node to the failed node:

       scp -r <sec dir> node02:KVROOT/security

5. Start the Oracle NoSQL Database software on the new node:

       > nohup java -Xmx64m -Xms64m \
       -jar KVHOME/lib/kvstore.jar start -root KVROOT &

6. Deploy the new Storage Node to the new node. To do this using the CLI:

       > java -Xmx64m -Xms64m \
       -jar KVHOME/lib/kvstore.jar runadmin \
       -port <5000> -host <host> \
        -security security/client.security
       kv-> plan deploy-sn -zn <id> -host <host> -port <5000> -wait

7. Add the new Storage Node to the Storage Node pool. (You created a Storage Node pool when you installed the store, and you added all your Storage Nodes to it, but it is otherwise not used in this version of the product.)

       kv-> show pools
       AllStorageNodes: sn1, sn2, sn3, sn4 ... sn25, sn26
       BostonPool: sn1, sn2, sn3, sn4 ... sn25
       kv-> pool join -name BostonPool -sn sn26
       AllStorageNodes: sn1, sn2, sn3, sn4 ... sn25, sn26
       BostonPool: sn1, sn2, sn3, sn4 ... sn25

8. Make sure the old Storage Node is not running. If the problem is with the hardware, then turn off the broken machine. You can also stop just the Storage Node software by:

       > java -Xmx64m -Xms64m \
       -jar KVHOME/lib/kvstore.jar stop -root KVROOT &

9. Migrate the services from one Storage Node to another. The syntax for this plan is:

       kv-> plan migrate-sn -from <old SN ID> -to <new SN ID> -wait

   Assuming that you are migrating from Storage Node 25 to 26, you would use:

       kv-> plan migrate-sn -from sn25 -to sn26 -wait

10. The old Storage Node is shown in the topology and is reported as UNREACHABLE. The source SNA should be removed and its rootdir should be hosed out. Bringing up the old SNA will also bring up the old Replication Nodes and admins, which are no longer members of their replication groups. This should be harmless to the rest of the store, but it produces log error messages that might be misinterpreted as indicating a problem with the store. Use the `plan remove-sn` command to remove the old and unused Storage Node in your deployment.

        kv-> plan remove-sn sn sn25 -wait

11. Use the ping command to verify the migration to the new node is complete and all services are running well.

        > java -Xmx64m -Xms64m \
                -jar KVHOME/lib/kvstore.jar ping \
                -port <5000> -host <host> \
                -security security/client.security

Note:

Replacing a Storage Node qualifies as a topology change. This means that if you want to restore your store from a snapshot taken before the Storage Node was replaced, you must use the `Load` program. See Using the Load Program for more information.