Managing Gateways

To see a list of the gateways for a particular destination cluster, run the maprcli cluster gateway get command on the source cluster. Specify the name of the destination cluster with the -dstcluster parameter. If you run the command remotely from you source cluster, specify the name of the source cluster with the -cluster parameter.
To see a list of the gateways for all of the destination clusters that the source cluster is replicating to, run the maprcli cluster gateway list command on the source cluster. If you run the command remotely from your source cluster, specify the name of the source cluster with the -cluster parameter.
To remove the list of gateways that you specified for a destination cluster by using the maprcli cluster gateway set command, run the maprcli cluster gateway delete command on the source cluster. Specify the name of the destination cluster with the -dstcluster parameter. If you run the command remotely from your source cluster, specify the name of the source cluster with the -cluster parameter.
To find out how MapR-DB or MapR Streams is finding gateways (for example, from DNS records, lists created by the maprcli cluster gateway set command, or the mapr-clusters.conf file), run the command maprcli cluster gateway resolve on the source cluster. Specify the name of the destination cluster with the -dstcluster parameter. If you run the command remotely from your source cluster, specify the name of the source cluster with the -cluster parameter.
If you need to stop and start one or more gateways, run the following commands on the clusters where the gateways are running:
```
maprcli node services -name gateway -action stop -nodes <hostnames or IP addresses>
```
```
maprcli node services -name gateway -action start -nodes <hostnames or IP addresses> 
```
Hostnames and IP addresses are separated by spaces.

To check the status of a gateway service on a particular node, run the command maprcli service list on the clusters where the gateways are running.

If a Gateway Fails

If a gateway fails, the warden service tries three (3) times to restart it automatically. After an interval, the warden tries again three times to start the gateway. You can configure the interval by using the parameter services.retryinterval.time.sec in the warden.conf file. The default is 30 minutes.

During the time that the gateway is down, source clusters will resend updates to other gateways. Source clusters will also ping the failed gateway with an exponentially increasing backoff.

If all of the gateways fail in a destination cluster, source clusters will ping the failed gateways in the same manner. Updates pending replication are stored on disk in an internal data structure until at least one gateway in the destination cluster comes back online. Therefore, you will see additional storage costs during a gateway outage. The Gateway Service Down alarm in MCS will notify you when none of the gateways in a destination cluster can be reached.

If the additional storage becomes too costly, you can follow either of these procedures:

If you are replicating to a MapR-DB binary table:

Run the maprcli table replica remove command to stop replicating to the replica. This action deletes the pending updates.
Resolve the gateway outage.
Recreate the replica and start replicating to it by running the maprcli table replica autosetup command.

If you are replicating to a MapR Streams stream:

Run the maprcli stream replica remove command to stop replicating to the replica stream. This action cancels the pending updates to the replica stream.
Resolve the gateway outage.
Run the command maprcli stream replica autosetup to recreate the replica stream and start replicating to it.

If you are replicating to an Elasticsearch type:

Run the maprcli table replica elasticsearch remove command to stop replicating to the type. This action deletes the pending updates.
Resolve the gateway outage.
Delete the type from the Elasticsearch cluster.
Recreate and load the Elasticsearch type with the maprcli table replica elasticsearch autosetup command. If you originally created the type manually because you set up custom mapping of MapR-DB data to data types other than string, first recreate the type with the manual method that you used. Then, run the maprcli table replica elasticsearch autosetup command.

Troubleshooting

You can refer to two log files for each gateway when troubleshooting. Both are in the /opt/mapr/logs directory on the node where the gateway is running:

gateway.log
gatewayinit.log

MapR-DB Lookup Order

MapR-DB uses the following order to locate the gateways that are running in a destination cluster.

Look up the name of the destination cluster and the addresses of the gateways in the information specified by the maprcli cluster gateway set command. If no list of gateways for the destination cluster is found, then a DNS lookup is performed.
Perform a DNS lookup of the destination cluster and the addresses of the gateways. If no DNS record for the destination cluster is found, then the lookup goes to the mapr-clusters.conf file.
Look up the name of the destination cluster and the addresses of the CLDB nodes in that cluster in the mapr-clusters.conf file, under the assumption that gateways are running on all of the CLDB nodes and only on those nodes.