Migrate Database Management and Alias management pages from Cypher Ma… (#1139)

…nual to Operations Manual (#826)

First attempt to migrate Administration chapter in Cypher Manual to
Operations Manual.

Note, this PR does not contain examples about clustering, server
management, and the rbac commands, as these pages in the Cypher Manual
will be added to more relevant pages in the operations manual.

Includes updates from the following Cypher Manual PRs making changes to
the impacted pages:

- neo4j/docs-cypher#653 (5.10)
- neo4j/docs-cypher#680 (5.11)
- neo4j/docs-cypher#649 (5.11)

---------

Co-authored-by: Jens Pryce-Åklundh <[email protected]>
Co-authored-by: Love Kristofer Leifland <[email protected]>

Author: 3 people

modules/ROOT/content-nav.adoc

@@ -102,16 +102,23 @@
 *** xref:configuration/configuration-settings.adoc#_transaction_settings[Transaction settings]
 *** xref:configuration/configuration-settings.adoc#_transaction_log_settings[Transaction log settings]
 
-* xref:manage-databases/index.adoc[]
-** xref:manage-databases/introduction.adoc[]
-** xref:manage-databases/configuration.adoc[]
-** xref:manage-databases/queries.adoc[]
-** xref:manage-databases/errors.adoc[]
-** xref:manage-databases/remote-alias.adoc[]
-** xref:composite-databases/index.adoc[]
-*** xref:composite-databases/administration.adoc[]
-*** xref:composite-databases/sharding-with-copy.adoc[]
-*** xref:composite-databases/queries.adoc[]
+* xref:database-administration/index.adoc[]
+** Standard databases
+*** xref:database-administration/standard-databases/naming-databases.adoc[]
+*** xref:database-administration/standard-databases/manage-databases.adoc[]
+*** xref:database-administration/standard-databases/configuration-parameters.adoc[]
+*** xref:database-administration/standard-databases/errors.adoc[]
+** Database aliases
+*** xref:database-administration/aliases/naming-aliases.adoc[]
+*** xref:database-administration/aliases/manage-aliases-standard-databases.adoc[]
+*** xref:database-administration/aliases/manage-aliases-composite-databases.adoc[]
+*** xref:database-administration/aliases/remote-database-alias-configuration.adoc[]
+** Composite databases
+*** xref:database-administration/composite-databases/concepts.adoc[]
+*** xref:database-administration/composite-databases/manage-composite-databases.adoc[]
+*** xref:database-administration/composite-databases/querying-composite-databases.adoc[]
+*** xref:database-administration/composite-databases/sharding-with-copy.adoc[]
+** xref:database-administration/syntax.adoc[]
 
 * xref:database-internals/index.adoc[]
 ** xref:database-internals/transaction-management.adoc[]

modules/ROOT/pages/backup-restore/copy-database.adoc

@@ -13,7 +13,7 @@ However, the command will output Cypher statements, which you can run to recreat
 ====
 * `neo4j-admin database copy` preserves the node IDs (unless `--compact-node-store` is used), but the relationships get new IDs.
 * `neo4j-admin database copy` is not supported for use on the `system` database.
-* `neo4j-admin database copy` is not supported for use on xref:composite-databases/index.adoc[Composite databases].
+* `neo4j-admin database copy` is not supported for use on xref:database-administration/composite-databases/manage-composite-databases.adoc[Composite databases].
 It must be run directly on the databases that are associated with that Composite database.
 * `neo4j-admin database copy` is an IOPS-intensive process.
 For more information, see <<copy-estimating-iops, Estimating the processing time>>.
@@ -273,7 +273,7 @@ Labels are processed independently, i.e., the filter ignores any node with a lab
 
 [TIP]
 ====
-For a detailed example of how to use `neo4j-admin database copy` to filter out data for sharding a database, see xref:composite-databases/sharding-with-copy.adoc[Sharding data with the `copy` command].
+For a detailed example of how to use `neo4j-admin database copy` to filter out data for sharding a database, see xref:database-administration/composite-databases/sharding-with-copy.adoc[Sharding data with the `copy` command].
 ====
 
 [[compact-database]]

modules/ROOT/pages/backup-restore/offline-backup.adoc

@@ -117,6 +117,6 @@ The command creates a file called _<database>.dump_ where `<database>` is the da
 
 [NOTE]
 ====
-`neo4j-admin database dump` cannot be applied to xref:composite-databases/index.adoc[Composite databases].
+`neo4j-admin database dump` cannot be applied to xref:database-administration/composite-databases/manage-composite-databases.adoc[Composite databases].
 It must be run directly on the databases that are associated with that Composite database.
 ====

modules/ROOT/pages/backup-restore/planning.adoc

@@ -96,7 +96,7 @@ The recommended way to restore a database in a cluster is to xref:clustering/dat
 
 [NOTE]
 ====
-The Neo4j Admin commands `backup`, `restore`, `dump`, `load`, `copy`, and `check-consistency` are not supported for use on xref:composite-databases/index.adoc[Composite databases].
+The Neo4j Admin commands `backup`, `restore`, `dump`, `load`, `copy`, and `check-consistency` are not supported for use on xref:database-administration/composite-databases/manage-composite-databases.adoc[Composite databases].
 They must be run directly on the databases that are associated with that Composite database.
 ====
 

modules/ROOT/pages/backup-restore/restore-backup.adoc

@@ -15,7 +15,7 @@ Restoring a database backup to a previous Neo4j version is not supported.
 
 You must create the database (using `CREATE DATABASE` against the `system` database) after the restore operation finishes, unless you are replacing an existing database.
 `neo4j-admin database restore` must be invoked as the `neo4j` user to ensure the appropriate file permissions.
-For more information, see xref:manage-databases/configuration.adoc#manage-databases-administration[Administrative commands].
+For more information, see xref:database-administration/standard-databases/manage-databases.adoc[Manage databases].
 
 [NOTE]
 ====

modules/ROOT/pages/backup-restore/restore-dump.adoc

@@ -121,6 +121,6 @@ For more information, see xref:clustering/databases.adoc#cluster-seed[Seed a clu
 
 [NOTE]
 ====
-`neo4j-admin database load` cannot be applied to xref:composite-databases/index.adoc[Composite databases].
+`neo4j-admin database load` cannot be applied to xref:database-administration/composite-databases/manage-composite-databases.adoc[Composite databases].
 It must be run directly on the databases that are associated with that Composite database.
 ====

modules/ROOT/pages/clustering/databases.adoc

@@ -9,7 +9,7 @@ If a database is no longer needed, the command `DROP DATABASE` deletes the datab
 
 == `CREATE DATABASE`
 
-The command to create a database in a cluster is not significantly different from the command to create a database in a non-clustered environment (see link:{neo4j-docs-base-uri}/cypher-manual/{page-version}/administration/databases[Cypher Manual -> Database management] for more information on database management on single servers).
+The command to create a database in a cluster is not significantly different from the command to create a database in a non-clustered environment (see xref::database-administration/standard-databases/manage-databases.adoc[Database management] for more information on database management on single servers).
 The difference in a clustered environment is that the topology can be specified, i.e. how many primaries and secondaries are desired for the database.
 To create a database `foo` with 3 servers hosting the database in primary mode and 2 servers in secondary mode, the command looks like this:
 
@@ -60,7 +60,7 @@ It is not possible to automatically transition to a topology with a single prima
 
 However, it is possible to _manually_ do this transition.
 The first step is to back up the database, see xref:backup-restore/index.adoc[Backup and restore] for more information.
-Once the database is backed up, the next step is to drop the database, see xref:manage-databases/configuration.adoc#manage-databases-administration[Administrative commands] for more information.
+Once the database is backed up, the next step is to drop the database, see xref:database-administration/standard-databases/manage-databases.adoc[Manage databases] for more information.
 The last step is to either seed a cluster from the backup with the new topology, or to restore the backup on a single server.
 See xref:clustering/databases.adoc#cluster-seed[Seed a cluster] further on for information on seeding.
 
@@ -253,7 +253,7 @@ Some seed providers may also want to pass credentials into the provider.
 These are specified with the `seedCredentials` option.
 Seed credentials are securely passed from the Cypher command to each server hosting the database.
 For this to work, Neo4j on each server in the cluster must be configured with identical keystores.
-This is identical to the configuration required by remote aliases, see xref:manage-databases/remote-alias.adoc#remote-alias-config-DBMS_admin-A[Configuration of DBMS with remote database alias].
+This is identical to the configuration required by remote aliases, see xref:database-administration/aliases/remote-database-alias-configuration.adoc#remote-alias-config-DBMS_admin-A[Configuration of DBMS with remote database alias].
 If this configuration is not performed, the `seedCredential` option fails.
 
 For example, in the case of `S3SeedProvider`(the default provider): `seedCredentials: [accessKey];[secretKey]` where `accessKey` and `secretKey` are provided by AWS.
@@ -322,7 +322,7 @@ See xref:clustering/clustering-advanced/default-database.adoc[Default database i
 == Handling errors
 
 Databases can get into error states.
-Typically you can observe this with the `SHOW DATABASES` command, and use the xref:manage-databases/errors.adoc[error handling guidance] to help.
+Typically you can observe this with the `SHOW DATABASES` command, and use the xref:database-administration/standard-databases/errors.adoc[error handling guidance] to help.
 
 In more serious cases you may be dealing with a disaster situation, where the whole DBMS may not be responding correctly, or some specific databases cannot be restored without downtime.
 Refer to the xref:clustering/disaster-recovery.adoc[disaster recovery guide] for those situations.

modules/ROOT/pages/clustering/disaster-recovery.adoc

@@ -153,7 +153,7 @@ Once the `system` database is verified available, and all servers are online, th
 The steps here aim to make the unavailable databases available.
 
 . If you have previously dropped databases as part of this guide, re-create each one from backup.
-See the xref:manage-databases/configuration.adoc#manage-databases-administration[Administrative commands] section for more information on how to create a database.
+See the xref:database-administration/standard-databases/manage-databases.adoc[Manage databases] section for more information on how to create a database.
 . Run `SHOW DATABASES`.
 If all databases are in desired states on all servers (`requestedStatus`=`currentStatus`), disaster recovery is complete.
 // . For each database that remains unavailable, refer to <<unavailable-databases, Managing unavailable databases in a cluster>>.

modules/ROOT/pages/clustering/setup/analytics-cluster.adoc

@@ -268,6 +268,6 @@ If you want to follow along with the startup, you can see the messages in xref:c
 == Running analytic queries
 
 If running large normal Cypher queries, it is possible to use server tags to identify the large servers, and a routing policy to direct the read queries towards those servers.
-See xref:clustering/clustering-advanced/multi-data-center-routing.adoc[here] for more details.
+See xref:clustering/clustering-advanced/multi-data-center-routing.adoc[Multi-data center routing] for more details.
 
 If using GDS, follow the guidance in link:https://neo4j.com/docs/graph-data-science/current/production-deployment/neo4j-cluster/[Neo4j Graph Data Science Library Manual -> GDS with Neo4j cluster].