When you configure ArcGIS Data Store, you associate it with the GIS Server site that serves as your portal's hosting server. Actions that change or check the status of the data store are performed from the ArcGIS Server Administrator Directory for the hosting server as the ArcGIS Server administrator. (The URL format is https://gisserver.domain.com:6443/arcgis/admin.) You can also remove a standby machine from a relational data store or tile cache data store running in primary-standby mode and remove the standby machine from the GIS Server site in the ArcGIS Server Administrator Directory. The following sections summarize these operations and link to the ArcGIS API documentation.
If you are not the ArcGIS Server administrator for the hosting server, you will need to work with that person to complete the tasks described here.
The following are the paths in the ArcGIS Server Administrator Directory that you need to follow to access operations for each type of data store:
- Relational data store—Click data > items > enterpriseDatabases > <data store name> > machines > <machine name>.
- Spatiotemporal big data store—Click data > items > nosqlDatabases > AGSDataStore_bigdata_<data store name> > machines > <machine name>.
- Tile cache data store—Click data > items > nosqlDatabases > AGSDataStore_nosql_<data store name> > machines > <machine name>.
- Graph store—Click data > items > nosqlDatabases > AGSDataStore_graph_<data store name> > machines > <machine name>.
- Object store—Click data > items > objectStores > <data store name> > machines > <machine name>.
Change the status of a data store machine
You can stop and restart individual machines in a data store. You can also promote a standby relational data store, tile cache data store, or graph store machine to be the primary.
Stopping the primary data store machine does not cause the data store to fail over in an on-premises deployment, as you may not want to fail over if you are performing a maintenance task, such as temporarily taking the data store offline.
For example, you change data store machine status as part of the following upgrade scenario:
- Stop the standby machine.
- Upgrade the standby.
- Start the standby.
- Promote the standby to primary using the makePrimary command.
- Stop the former primary machine.
- Upgrade the former primary.
- Start the former primary.
- Add the former primary machine back to the data store as the standby machine.
Sign in to the ArcGIS Server Administrator Directory for the hosting server as the ArcGIS Server site administrator and go to a specific machine to use any of the following commands to change the status of a data store machine:
- stop
- start
- makePrimary (standby machines in a relational data store, graph store, or tile cache data store in primary-standby mode only)
Validate the data store
You can check the status of the machines in a data store using the validate ArcGIS Server REST command.
Sign in to the ArcGIS Server Administrator Directory for the hosting server as the ArcGIS Server site administrator, go to one of the machines in the specific data store type you want to check, and click validate to see information related to that data store. Important information related to a data store's status includes the following:
- overallhealth—Values are as follows:
- Healthy—All the components on all the member machines are reachable and working.
- HealthyWithWarning—This state applies to object and graph stores only. One or more components are not available, but the data store is still usable. For object stores that contain more than one machine, the data store may not be highly available at this point.
- Unhealthy—A data store is considered unhealthy if more than half the machines in it are inaccessible ("datastore.overallhealth": "Unhealthy"). A machine is considered unhealthy if it is inaccessible ("machine.overallhealth": "Unhealthy").
- status—For relational or tile cache data stores, possible values are Started or Stopped. When stopped, you cannot publish hosted feature layers or hosted scene layers to your portal.
- clusterStatus—For spatiotemporal big data stores, statuses are as follows:
- green—All data is available.
- yellow—The data is available, but some or all replica copies of the data are not available and your spatiotemporal big data store is not currently highly available. You will always see this status if you configured a single-machine spatiotemporal big data store. You may also see this status if machines are rebalancing data, or one or more of the machines in your spatiotemporal big data store are inaccessible. If you have a multimachine spatiotemporal big data store and see a yellow status, confirm that all machines are still available by validating each machine. If they are available, wait several hours and check again. If the status is still yellow, examine the ArcGIS Server logs for errors.
- red—Some or all of the data is inaccessible. Examine the logs and correct errors.
- role—This applies to machines in a relational data store, graph store, or primary-standby tile cache data store only and indicates whether the machine is the primary or standby machine. For an object store, the role will be primary for a single instance, and cluster_member for an object store deployed in cluster mode.
- messages—You will see warning and error messages related to the data store status here. For example, if you validate a multimachine tile cache data store, you will receive a message if scene cache data is not currently highly available (in other words, there is only one copy of one or more of the scene caches).
You can validate the data store to confirm a machine has been stopped or started, to confirm the standby was made primary after you used the makePrimary command, to identify whether your tile cache data store is in a highly available state, or as an initial troubleshooting step if hosted feature or scene layers cannot be published or accessed, if you cannot create or access a knowledge graph, or you cannot run GeoAnalytics Tools.
Remove a standby machine
You can remove a standby machine from a relational data store or primary-standby tile cache data store using the remove ArcGIS Server REST command. For example, if you want to use a different computer for the standby, you can remove the old standby machine from the data store, install ArcGIS Data Store on the new machine, and configure the new machine as the standby.
Sign in to the ArcGIS Server Administrator Directory for the hosting server as the ArcGIS Server site administrator to use the remove command.
Manage query response caches for hosted feature layers
For hosted feature layers that are queried frequently, the ArcGIS Server administrator for the hosting server can enable query response caching on individual layers to help improve performance. Once enabled, each time the feature service receives a unique query, the features and extent are cached in the object store. Depending on how long caches are stored (the cache expiration policy) and how much disk space is available on the machine or machines where the object store is running, the object store may fill up and stop functioning.
As the ArcGIS Data Store administrator, you must configure the object store on a machine or machines separate from other software and ensure there is ample disk space available to store these caches. You must also monitor the ArcGIS Data Store logs to detect when the object store is nearing capacity. You can validate the object store to see what percentage of disk space is in use on the object store machines and run a utility to determine what layer caches are largest. If necessary, work with the ArcGIS Server administrator to change the cache expiration policy or to delete large layer caches.
Enable query response caching for feature layers
To enable caching on a layer or layers in a hosted feature layer (feature service), the ArcGIS Server administrator of the hosting server site must sign in to the ArcGIS Server Administrator Directory for the hosting server and submit the following request with the Update Definition REST operation:
{
"layerCache": {
"enabled": true
}
}If data is updated frequently, don't enable caching; every time the layer is updated, the cache has to be rebuilt, so you won't see any performance gains when using cached queries on frequently edited feature layers.
Set or change the cache expiration policy
Caches are built per unique query. If you have enough disk space on the object store machine and the layer is accessed by many clients, set the cache to not expire. The example request shown in the previous section enables caching with no expiration.
For layers that aren't accessed continuously, or if disk space is a concern, set how long (in days) the query response cache for a layer is retained.
{
"layerCache": {
"enabled": true,
"expiration": <duration_in_days>
}
}Be aware that caches expire at midnight UTC time. If you set the expiration policy to 1, the cache can persist for up to nearly two days, depending on when the cache is created.
For example, if a client accesses a feature layer at 4:00 UTC, its cache will persist until 24:00 UTC the following day.
Delete a cache for a layer
If the object store is running out of disk space, you'll see a warning in the ArcGIS Data Store logs and the validate REST command will show how much disk space is used. You cannot add disk space or machines to an existing object store, so you may need to clean out caches to free up disk space. To do this, the ArcGIS Server administrator of the hosting server must disable caching for that layer.
{
"layerCache": {
"enabled": false
}
}