History

sleto-it 0ba532b16a Doc - Replication Refactor - Part 1 (#4555 ) Next steps after DC2DC and Cluster doc improvements: - We refactor replication sections and make more intuitive separation between Master/Slave and the new Active Failover in 3.3 - We create corresponding sections for Master/Slave and Active Failover in the Administration and Deployment chapters, as well as in the Scalability chapter, where these "modes" are introduced - We touch and improve the "Architecture" chapter as well, where some architecture info have to be placed - We reorg the TOC having in more "logical" order: -- Deployment -- Administration -- Security -- Monitoring -- Troubleshooting - We adds parts in the TOC - We add toc per pages, using page-toc plugin - We also put close together "Scalability" and "Architecture" chapters, preliminary steps of further improvements / aggregation - We improve swagger Internal Ref: - https://github.com/arangodb/planning/issues/1692 - https://github.com/arangodb/planning/issues/1655 - https://github.com/arangodb/planning/issues/1858 - https://github.com/arangodb/planning/issues/973 (partial fix) - https://github.com/arangodb/planning/issues/1498 (partial fix)	2018-02-28 12:23:19 +01:00
..
README.md	Doc - Replication Refactor - Part 1 (#4555 )	2018-02-28 12:23:19 +01:00

Doc - Replication Refactor - Part 1 (#4555 )

Next steps after DC2DC and Cluster doc improvements:

- We refactor replication sections and make more intuitive separation between Master/Slave and the new Active Failover in 3.3
- We create corresponding sections for Master/Slave and Active Failover in the Administration and Deployment chapters, as well as in the Scalability chapter, where these "modes" are introduced
- We touch and improve the "Architecture" chapter as well, where some architecture info have to be placed
- We reorg the TOC having in more "logical" order:
-- Deployment
-- Administration
-- Security
-- Monitoring
-- Troubleshooting
- We adds parts in the TOC
- We add toc per pages, using page-toc plugin
- We also put close together "Scalability" and "Architecture" chapters, preliminary steps of further improvements / aggregation
- We improve swagger

Internal Ref:
- https://github.com/arangodb/planning/issues/1692
- https://github.com/arangodb/planning/issues/1655
- https://github.com/arangodb/planning/issues/1858
- https://github.com/arangodb/planning/issues/973 (partial fix)
- https://github.com/arangodb/planning/issues/1498 (partial fix)

2018-02-28 12:23:19 +01:00

README.md

Doc - Replication Refactor - Part 1 (#4555 )

2018-02-28 12:23:19 +01:00

README.md

HTTP Interface for AQL Queries

Explaining and parsing queries

ArangoDB has an HTTP interface to syntactically validate AQL queries. Furthermore, it offers an HTTP interface to retrieve the execution plan for any valid AQL query.

Both functionalities do not actually execute the supplied AQL query, but only inspect it and return meta information about it.

@startDocuBlock post_api_explain

@startDocuBlock PostApiQueryProperties

Query tracking

ArangoDB has an HTTP interface for retrieving the lists of currently executing AQL queries and the list of slow AQL queries. In order to make meaningful use of these APIs, query tracking needs to be enabled in the database the HTTP request is executed for.

@startDocuBlock GetApiQueryProperties

@startDocuBlock PutApiQueryProperties

@startDocuBlock GetApiQueryCurrent

@startDocuBlock GetApiQuerySlow

@startDocuBlock DeleteApiQuerySlow

Killing queries

Running AQL queries can also be killed on the server. ArangoDB provides a kill facility via an HTTP interface. To kill a running query, its id (as returned for the query in the list of currently running queries) must be specified. The kill flag of the query will then be set, and the query will be aborted as soon as it reaches a cancelation point.

@startDocuBlock DeleteApiQueryKill