Managing Gateways

Describes the commands for listing gateways, checking status of gateways, managing gateways if they fail, and troubleshooting gateways.

You can run the following commands to perform operations on your gateways.

Note: If you have configured an intra-cluster gateway, the source and destination clusters are the same.

Running the maprcli cluster gateway set command

The syntax of the maprcli cluster gateway set command is:
/opt/mapr/bin/maprcli cluster gateway set -dstcluster <cluster name> -gateways "<space-delimited list of gateways>"

To generate a list of the existing gateways in a data-fabric cluster, use the maprcli cluster gateway list command. You can then copy this list and paste it into the maprcli cluster gateway set command. Alternatively, to generate a list of the gateways on a local cluster, run the maprcli cluster gateway local -format text command. If you want to run the command from a different cluster and point to the cluster where the gateways are located, use the -cluster parameter to provide the name of that cluster.

For example, suppose that you are configuring table replication from the cluster sanfrancisco to the cluster newyork, and want to use two gateways. The nodes on which these gateways are located are named gw1 and gw2.

The command that you run will be as follows:

/opt/mapr/bin/maprcli cluster gateway set -dstcluster newyork -gateways "gw1.bigcompany.com gw2.bigcompany.com"

Adding a DNS record to your DNS server's zone file for your domain

In your DNS server’s zone file for your domain, you can add a record for the cluster where gateways are located, listing the nodes to use as gateways. You can use the Control System to create a record that you can copy into a DNS configuration file, run a maprcli command to generate the record, or create a record manually.

For details, see Specifying the Location of Gateways.

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 the Control System 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 HPE Ezmeral Data Fabric Database binary table:

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

If you are replicating to a HPE Ezmeral Data Fabric Event Store stream:

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

Troubleshooting

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

HPE Ezmeral Data Fabric Database Lookup Order

HPE Ezmeral Data Fabric Database uses the following order to locate the gateways that are running in a destination cluster.