neo4j · renetapopova · Nov 22, 2024 · Sep 17, 2024 · Sep 18, 2024 · Sep 19, 2024
diff --git a/modules/ROOT/content-nav.adoc b/modules/ROOT/content-nav.adoc
@@ -125,6 +125,7 @@
 *** 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-administration/routing-decisions.adoc[]
 
 * xref:database-internals/index.adoc[]
 ** xref:database-internals/transaction-management.adoc[]
@@ -236,6 +237,8 @@
 *** xref:tools/neo4j-admin/validate-config.adoc[]
 ** xref:tools/cypher-shell.adoc[]
 
+* xref:procedures.adoc[]
+
 * xref:tutorial/index.adoc[]
 //** xref:tutorial/local-causal-cluster.adoc[]
 //** xref:tutorial/causal-backup-restore-db.adoc[]
@@ -246,10 +249,6 @@
 ** xref:tutorial/tutorial-immutable-privileges.adoc[]
 ** xref:tutorial/tutorial-clustering-docker.adoc[]
 
-* Appendix
-** xref:reference/procedures.adoc[]
-** xref:routing-decisions.adoc[]
-
 // ** xref:clustering-advanced/index.adoc[]
 // *** xref:clustering-advanced/lifecycle.adoc[]
 // *** xref:clustering-advanced/multi-data-center/index.adoc[]

diff --git a/modules/ROOT/pages/authentication-authorization/ldap-integration.adoc b/modules/ROOT/pages/authentication-authorization/ldap-integration.adoc
@@ -65,7 +65,7 @@ this LDAP group will fail authentication, even if their credentials are correct.
 |===
 
 All settings are defined at server startup time in the default configuration file _xref:configuration/neo4j-conf.adoc[neo4j.conf]_ or can be modified at
-runtime using xref:reference/procedures.adoc#procedure_dbms_setconfigvalue[`dbms.setConfigValue()`].
+runtime using xref:procedures.adoc#procedure_dbms_setconfigvalue[`dbms.setConfigValue()`].
 
 
 [[auth-ldap-configure-provider]]

diff --git a/modules/ROOT/pages/clustering/databases.adoc b/modules/ROOT/pages/clustering/databases.adoc
@@ -145,9 +145,9 @@ By default, a newly created database has both read and write access.
 
 To relieve the load of a specific server(s), you can use one of the following procedures to deallocate databases causing the pressure from the server(s):
 
-* xref:reference/procedures.adoc#procedure_dbms_cluster_deallocateDatabaseFromServer[`dbms.cluster.deallocateDatabaseFromServer("server-name", "database-name")`]
-* xref:reference/procedures.adoc#procedure_dbms_cluster_deallocateDatabaseFromServers[`dbms.cluster.deallocateDatabaseFromServers(["server-name1", "server-name2"\], "database-name")`]
-* xref:reference/procedures.adoc#procedure_dbms_cluster_deallocateNumberOfDatabases[`dbms.cluster.deallocateNumberOfDatabases("server-name", number)`]
+* xref:procedures.adoc#procedure_dbms_cluster_deallocateDatabaseFromServer[`dbms.cluster.deallocateDatabaseFromServer("server-name", "database-name")`]
+* xref:procedures.adoc#procedure_dbms_cluster_deallocateDatabaseFromServers[`dbms.cluster.deallocateDatabaseFromServers(["server-name1", "server-name2"\], "database-name")`]
+* xref:procedures.adoc#procedure_dbms_cluster_deallocateNumberOfDatabases[`dbms.cluster.deallocateNumberOfDatabases("server-name", number)`]
 
 [NOTE]
 ====
@@ -200,7 +200,7 @@ To rebalance all database allocations across the cluster, for example, because y
 [[reallocate-databases-procedure]]
 === Reallocate databases using a procedure
 
-You can use the procedure xref:reference/procedures.adoc#procedure_dbms_cluster_reallocateDatabase[`dbms.cluster.reallocateDatabase`] to rebalance a specific database across the cluster, or xref:reference/procedures.adoc#procedure_dbms_cluster_reallocateNumberOfDatabases[`dbms.cluster.reallocateNumberOfDatabases`] to rebalance a number of database allocations across the cluster and relieve overloaded servers.
+You can use the procedure xref:procedures.adoc#procedure_dbms_cluster_reallocateDatabase[`dbms.cluster.reallocateDatabase`] to rebalance a specific database across the cluster, or xref:procedures.adoc#procedure_dbms_cluster_reallocateNumberOfDatabases[`dbms.cluster.reallocateNumberOfDatabases`] to rebalance a number of database allocations across the cluster and relieve overloaded servers.
 Note that if the cluster is already balanced, no reallocations will happen when running these procedures.
 These procedures do not require a server name and can be executed with or without a dry run.
 
@@ -240,7 +240,7 @@ This command can also be used with `DRYRUN` to preview the new allocation of dat
 [CAUTION]
 ====
 `REALLOCATE DATABASES` on a large cluster with many databases has the potential to move a lot of allocations at once, which might stress the cluster.
-Consider starting with more limited reallocations, such as xref:reference/procedures.adoc#procedure_dbms_cluster_reallocateNumberOfDatabases[`dbms.cluster.reallocateNumberOfDatabases`] with a small number, and let the databases complete their reallocation before calling it again, until no more reallocations are necessary.
+Consider starting with more limited reallocations, such as xref:procedures.adoc#procedure_dbms_cluster_reallocateNumberOfDatabases[`dbms.cluster.reallocateNumberOfDatabases`] with a small number, and let the databases complete their reallocation before calling it again, until no more reallocations are necessary.
 ====
 
 [NOTE]
@@ -263,13 +263,13 @@ neo4j@neo4j> DRYRUN REALLOCATE DATABASES;
 [[recreate-databases]]
 == Recreate a database
 
-Neo4j 5.24 introduces the xref:reference/procedures.adoc#procedure_dbms_cluster_recreateDatabase[`dbms.cluster.recreateDatabase()`] procedure, which allows you:
+Neo4j 5.24 introduces the xref:procedures.adoc#procedure_dbms_cluster_recreateDatabase[`dbms.cluster.recreateDatabase()`] procedure, which allows you:
 
 * To change the database store to a specified backup, while keeping all the associated privileges for the database.
 
 * To make your database write-available again after it has been lost (for example, due to a disaster).
 // See xref:clustering/disaster-recovery.adoc[] for more information.
- 
+
 [CAUTION]
 ====
 The recreate procedure works only for real user databases and not for composite databases, or the `system` database.
@@ -338,7 +338,7 @@ If not used stores were more up to date than the used ones, this results in data
 
 You can specify a set of available servers.
 The stores on all allocations will be synchronized to the most up-to-date store from the defined servers.
-The number of defined servers cannot exceed the number of total allocations in the desired topology. 
+The number of defined servers cannot exceed the number of total allocations in the desired topology.
 
 [source, shell]
 ----
@@ -375,7 +375,7 @@ There is an option to define a new topology when recreating a database.
 This can be beneficial during a disaster, if enough servers are not available to recreate the database with the original topology.
 When altering the total number of allocations down during a recreation, it is important to remember that the number of seeding servers cannot exceed the number of total allocations of the database.
 This also holds true when using recreate with an empty list of seeders.
-If there are more available servers in the cluster hosting the database than the number of new allocations, the recreation will fail. 
+If there are more available servers in the cluster hosting the database than the number of new allocations, the recreation will fail.
 
 [source, shell]
 ----
@@ -664,7 +664,7 @@ If not set, there are no mode constraints on the server.
 [[cluster-default-database]]
 == Change the default database
 
-You can use the procedure xref:reference/procedures.adoc#procedure_dbms_setDefaultDatabase[`dbms.setDefaultDatabase("newDefaultDatabaseName")`] to change the default database for a DBMS.
+You can use the procedure xref:procedures.adoc#procedure_dbms_setDefaultDatabase[`dbms.setDefaultDatabase("newDefaultDatabaseName")`] to change the default database for a DBMS.
 
 . Ensure that the database to be set as default exists, otherwise create it using the command `CREATE DATABASE <database-name>`.
 . Show the name and status of the current default database by using the command `SHOW DEFAULT DATABASE`.

diff --git a/modules/ROOT/pages/clustering/monitoring/status-check.adoc b/modules/ROOT/pages/clustering/monitoring/status-check.adoc
@@ -4,8 +4,8 @@
 [[monitoring-replication]]
 = Monitor replication status
 
-Neo4j 5.24 introduces the xref:reference/procedures.adoc#procedure_dbms_cluster_statusCheck[`dbms.cluster.statusCheck()`] procedure to monitor the ability to replicate in clustered databases.
-
+Neo4j 5.24 introduces the xref:procedures.adoc#procedure_dbms_cluster_statusCheck[`dbms.cluster.statusCheck()`] procedure, which can be used to monitor the ability to replicate in clustered databases.
+In most cases this means a clustered database is write available.
 The procedure identifies which members of a clustered database are up-to-date and can participate in successful replication.
 Therefore, it is useful in determining the fault tolerance of a clustered database.
 Additionally, you can use the procedure to identify the leader of a clustered database within the cluster.
@@ -37,7 +37,7 @@ CALL dbms.cluster.statusCheck(databases :: LIST<STRING>, timeoutMilliseconds = n
 | databases           | List<String> | Databases for which the status check should run.
 Providing an empty list runs the status check for all *clustered* databases on that server, i.e. it does not run on singles or secondaries.
 | timeoutMilliseconds | Integer | How long to allow for replication, before returning it was unsuccessful.
-Default value is 1000 milliseconds. 
+Default value is 1000 milliseconds.
 |===
 
 [status-check-return-arguments]
@@ -55,10 +55,10 @@ The procedure returns a row for all primary members of all the requested databas
 | replicationSuccessful | Boolean      | Indicates if the server (on which the procedure is run) can replicate a transaction.
 | memberStatus          | String       | The status of each primary member.
 | recognisedLeader      | String       | The server id of the perceived leader of each primary member.
-| recognisedLeaderTerm  | Integer      | The term of the perceived leader of each primary member. 
+| recognisedLeaderTerm  | Integer      | The term of the perceived leader of each primary member.
 If the members report different leaders, the one with the highest term should be trusted.
 | requester             | Boolean      | Whether a server is the requester or not.
-| error                 | String       | Contains the error message if one is present. 
+| error                 | String       | Contains the error message if one is present.
 An example of an error is that one or more of the requested databases do not exist on the requester.
 |===
 

diff --git a/modules/ROOT/pages/clustering/servers.adoc b/modules/ROOT/pages/clustering/servers.adoc
@@ -277,7 +277,7 @@ neo4j@neo4j> ENABLE SERVER '25a7efc7-d063-44b8-bdee-f23357f89f01' OPTIONS
 The `allowedDatabases` and `deniedDatabases` are mutually exclusive and if both are specified, an error is returned.
 
 Optionally, it is possible to automatically enable free servers by setting the xref:configuration/configuration-settings.adoc#config_initial.dbms.automatically_enable_free_servers[`initial.dbms.automatically_enable_free_servers`] to `true`.
-This can be changed after startup using the xref:reference/procedures.adoc#procedure_dbms_cluster_setAutomaticallyEnableFreeServers[`dbms.cluster.setAutomaticallyEnableFreeServers`] procedure.
+This can be changed after startup using the xref:procedures.adoc#procedure_dbms_cluster_setAutomaticallyEnableFreeServers[`dbms.cluster.setAutomaticallyEnableFreeServers`] procedure.
 
 Server `tags` are used during database allocation and when configuring load balancing and replication policies.
 They cannot contain duplicates, so `tags:['eu', 'eu']` will return an error.

diff --git a/modules/ROOT/pages/clustering/settings.adoc b/modules/ROOT/pages/clustering/settings.adoc
@@ -20,7 +20,7 @@ This server always only hosts those databases in `SECONDARY` mode.
 
 | xref:configuration/configuration-settings.adoc#config_initial.dbms.automatically_enable_free_servers[`initial.dbms.automatically_enable_free_servers`]
 | This setting allows for auto-enable of servers in the `FREE` state.
-After startup, it can be changed with the xref:reference/procedures.adoc#procedure_dbms_cluster_setAutomaticallyEnableFreeServers[`dbms.cluster.setAutomaticallyEnableFreeServers`] procedure.
+After startup, it can be changed with the xref:procedures.adoc#procedure_dbms_cluster_setAutomaticallyEnableFreeServers[`dbms.cluster.setAutomaticallyEnableFreeServers`] procedure.
 
 | xref:configuration/configuration-settings.adoc#config_server.cluster.system_database_mode[`server.cluster.system_database_mode`]
 | Every cluster member hosts the `system` database.

diff --git a/modules/ROOT/pages/clustering/setup/deploy.adoc b/modules/ROOT/pages/clustering/setup/deploy.adoc
@@ -46,9 +46,9 @@ If not specified, it defaults to zero hostings in secondary mode.
 [NOTE]
 ====
 Any setting with the `initial` prefix is only effective on the first startup of the DBMS.
-Changing the default number of primaries and secondaries dynamically can only be done with the xref:reference/procedures.adoc#procedure_dbms_setDefaultAllocationNumbers[`dbms.setDefaultAllocationNumbers`] procedure.
+Changing the default number of primaries and secondaries dynamically can only be done with the xref:procedures.adoc#procedure_dbms_setDefaultAllocationNumbers[`dbms.setDefaultAllocationNumbers`] procedure.
 See xref:clustering/databases.adoc#_create_database[`CREATE DATABASE`] for more information.
-To view the current default settings, use the xref:reference/procedures.adoc#procedure_dbms_showTopologyGraphConfig[`dbms.showTopologyGraphConfig`] procedure.
+To view the current default settings, use the xref:procedures.adoc#procedure_dbms_showTopologyGraphConfig[`dbms.showTopologyGraphConfig`] procedure.
 ====
 
 

diff --git a/modules/ROOT/pages/routing-decisions.adoc → ...ase-administration/routing-decisions.adoc b/modules/ROOT/pages/routing-decisions.adoc → ...ase-administration/routing-decisions.adoc
@@ -1,13 +1,11 @@
-[appendix]
 [role=enterprise-edition]
-[[appendix-routing-decisions]]
+[[routing-decisions]]
 = Query routing decisions
 :description: This page describes in detail how queries are routed to databases for execution.
 
 Query routing is the process of deciding which Cypher executor (database) should be used and at which physical location the query should be executed.
 Every query that arrives at a Neo4j server, over the bolt protocol from a driver, undergoes the process described here.
 
-[[appendix-routing-decisions-tree]]
 == Routing decision tree
 
 Before the query is executed, these are the decisions taken during query routing stage:
@@ -52,6 +50,5 @@ Step 5: Open a transaction::
 Step 6: Execute query::
 * Execute the query in the open transaction.
 
-[[appendix-routing-decisions-tree-illustrated]]
 == Illustrated routing decision tree
 image::routing-decisions.svg[width=800, title="Illustrated routing decision tree"]
diff --git a/modules/ROOT/pages/database-administration/standard-databases/errors.adoc b/modules/ROOT/pages/database-administration/standard-databases/errors.adoc
@@ -162,7 +162,7 @@ It produces a database dump that can be further examined and potentially repaire
 
 There are two ways to get a database into a `quarantined` state:
 
-* By using the xref:reference/procedures.adoc#procedure_dbms_quarantineDatabase[`dbms.quarantineDatabase`] procedure locally to isolate a specific database.
+* By using the xref:procedures.adoc#procedure_dbms_quarantineDatabase[`dbms.quarantineDatabase`] procedure locally to isolate a specific database.
 The procedure must be executed on the instance whose copy of the database you want to quarantine.
 A reason for that can be, for example, when a database is unable to start on a given instance due to a file system permissions issue with the volume where the database is located or when a recently started database begins to log errors.
 The quarantine state renders the database inaccessible on that instance and prevents its state from being changed, for example, with the `START DATABASE` command.
@@ -210,7 +210,7 @@ The result contains the user, the time, and the reason for the quarantine.
 
 [NOTE]
 ====
-The `dbms.quarantineDatabase` procedure replaces xref:reference/procedures.adoc#procedure_dbms_cluster_quarantinedatabase[`dbms.cluster.quarantineDatabase`], which has been deprecated in Neo4j 4.3 and will be removed with the next major version.
+The `dbms.quarantineDatabase` procedure replaces xref:procedures.adoc#procedure_dbms_cluster_quarantinedatabase[`dbms.cluster.quarantineDatabase`], which has been deprecated in Neo4j 4.3 and will be removed with the next major version.
 ====
 
 .Quarantine a database
@@ -251,7 +251,7 @@ neo4j@system> SHOW DATABASE foo;
 ====
 A `quarantined` state is persisted for user databases.
 This means that if a database is quarantined, it will remain so even if that Neo4j instance is restarted.
-You can remove it only by running the xref:reference/procedures.adoc#procedure_dbms_quarantineDatabase[`dbms.quarantineDatabase`] procedure on the instance where the quarantined database is located, passing `false` for the `setStatus` parameter.
+You can remove it only by running the xref:procedures.adoc#procedure_dbms_quarantineDatabase[`dbms.quarantineDatabase`] procedure on the instance where the quarantined database is located, passing `false` for the `setStatus` parameter.
 
 The one exception to this rule is for the built-in `system` database.
 Any quarantine for that database is removed automatically after instance restart.

diff --git a/modules/ROOT/pages/database-internals/transaction-logs.adoc b/modules/ROOT/pages/database-internals/transaction-logs.adoc
@@ -85,7 +85,7 @@ Old transaction logs cannot be safely archived or removed by external jobs since
 Log pruning is called only after checkpoint completion to ensure at least one checkpoint and points to a valid place in the transaction log data.
 In reality, this means that all transaction logs created between checkpoints are kept for some time, and only after a checkpoint, the pruning strategy removes them.
 For more details on how to speed up checkpointing, see xref:database-internals/checkpointing.adoc#transaction-logging-log-pruning[Configure log pruning].
-To force a checkpoint, run the procedure xref:reference/procedures.adoc#procedure_db_checkpoint[`CALL db.checkpoint()`].
+To force a checkpoint, run the procedure xref:procedures.adoc#procedure_db_checkpoint[`CALL db.checkpoint()`].
 +
 [NOTE]
 ====

diff --git a/modules/ROOT/pages/monitoring/logging.adoc b/modules/ROOT/pages/monitoring/logging.adoc
@@ -1009,7 +1009,7 @@ The last two parenthesis `{}` `{}` are for the query parameters and `txMetaData`
 [[attach-metadata-tx]]
 === Attach metadata to a transaction
 
-You can attach metadata to a transaction and have it printed in the query log using the built-in procedure xref:reference/procedures.adoc#procedure_tx_setmetadata[`tx.setMetaData`].
+You can attach metadata to a transaction and have it printed in the query log using the built-in procedure xref:procedures.adoc#procedure_tx_setmetadata[`tx.setMetaData`].
 
 [NOTE]
 ====
@@ -1035,7 +1035,7 @@ Every graph app should follow a convention for passing metadata with the queries
 
 This is typically done programmatically but can also be used with the Neo4j dev tools. +
 In general, you start a transaction on a user database and attach a list of metadata to it by calling `tx.setMetaData`.
-You can also use the procedure xref:reference/procedures.adoc#procedure_tx_getmetadata[`CALL tx.getMetaData()`] to show the metadata of the current transaction.
+You can also use the procedure xref:procedures.adoc#procedure_tx_getmetadata[`CALL tx.getMetaData()`] to show the metadata of the current transaction.
 These examples use the MovieGraph dataset from the link:https://neo4j.com/docs/browser-manual/current/visual-tour/#guides[Neo4j Browser guide].
 
 .Using `cypher-shell`, attach metadata to a transaction

diff --git a/modules/ROOT/pages/performance/index-configuration.adoc b/modules/ROOT/pages/performance/index-configuration.adoc
@@ -142,7 +142,7 @@ A full description of how to create and use full-text indexes is provided in the
 === Configuring a full-text index
 
 The following options are available for configuring full-text indexes.
-For a complete list of Neo4j procedures, see xref:reference/procedures/[].
+For a complete list of Neo4j procedures, see xref:procedures.adoc#_index_management[Procedures].
 
 `db.index.fulltext.default_analyzer`::
 The name of the default analyzer when creating a new Full-text index.

diff --git a/modules/ROOT/pages/performance/space-reuse.adoc b/modules/ROOT/pages/performance/space-reuse.adoc
@@ -106,7 +106,7 @@ neo4j@neo4j> MATCH (n:testnode1) RETURN ID(n) as ID order by ID limit 5;
 5 rows available after 171 ms, consumed after another 84 ms
 ----
 +
-. Run xref:reference/procedures.adoc#procedure_db_checkpoint[`call db.checkpoint()`] procedure to force a checkpoint.
+. Run xref:procedures.adoc#procedure_db_checkpoint[`call db.checkpoint()`] procedure to force a checkpoint.
 +
 [source, shell]
 ----