You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
.. Configure which attribute to search for by adding the following lines to the _neo4j.conf_ file (replacing `myattribute` with the actual attribute name):
. Verify that the value of the returned membership attribute is a group that is mapped to a role in `dbms.security.ldap.authorization.group_to_role_mapping`.
Copy file name to clipboardExpand all lines: modules/ROOT/pages/clustering/databases.adoc
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -268,8 +268,8 @@ Neo4j 5.24 introduces the xref:procedures.adoc#procedure_dbms_cluster_recreateDa
268
268
* To change the database store to a specified backup, while keeping all the associated privileges for the database.
269
269
270
270
* To make your database write-available again after it has been lost (for example, due to a disaster).
271
-
// See xref:clustering/disaster-recovery.adoc[] for more information.
272
-
271
+
See xref:clustering/disaster-recovery.adoc[Disaster recovery] for more information.
272
+
273
273
[CAUTION]
274
274
====
275
275
The recreate procedure works only for real user databases and not for composite databases, or the `system` database.
@@ -468,7 +468,7 @@ SHOW DATABASE foo;
468
468
=== Seed from URI
469
469
470
470
This method seeds all servers with an identical seed from an external source, specified by the URI.
471
-
The seed can either be a full backup, a differential backup (xref:clustering/databases.adoc#cloud-seed-provider[`CloudSeedProvider`] or a dump from an existing database.
471
+
The seed can either be a full backup, a differential backup (xref:clustering/databases.adoc#cloud-seed-provider[`CloudSeedProvider`], or a dump from an existing database.
472
472
The sources of seeds are called _seed providers_.
473
473
474
474
The mechanism is pluggable, allowing new sources of seeds to be supported (see link:https://www.neo4j.com/docs/java-reference/current/extending-neo4j/project-setup/#extending-neo4j-plugin-seed-provider[Java Reference -> Implement custom seed providers] for more information).
Copy file name to clipboardExpand all lines: modules/ROOT/pages/database-administration/standard-databases/delete-databases.adoc
+7-2Lines changed: 7 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -85,12 +85,17 @@ By appending `DUMP DATA` to the command `DROP DATABASE`, you can create a dump o
85
85
DROP DATABASE movies DUMP DATA
86
86
----
87
87
88
-
These dumps are equivalent to those produced by xref:backup-restore/offline-backup.adoc[`neo4j-admin database dump`] and can be similarly restored using the xref:backup-restore/restore-dump.adoc[`neo4j-admin database load`] command.
89
-
90
88
In Neo4j, dumps can be stored in the directory specified by the xref:configuration/configuration-settings.adoc#config_server.directories.dumps.root[`server.directories.dumps.root`] setting (by default, the path for storing dumps is xref:configuration/file-locations.adoc#data[`<neo4j-home>/data/dumps`]).
89
+
You can use dumps to create databases through the xref:clustering/databases.adoc#cluster-seed-uri[Seed from URI approach].
91
90
92
91
The option `DESTROY DATA` explicitly requests the default behavior of the command.
93
92
93
+
[NOTE]
94
+
====
95
+
The dumps produced by `DUMP DATA` are equivalent to those produced by xref:backup-restore/offline-backup.adoc[`neo4j-admin database dump`].
96
+
You can also restore them using the xref:backup-restore/restore-dump.adoc[`neo4j-admin database load`] command.
97
+
====
98
+
94
99
[[delete-existing-db-with-dump]]
95
100
=== Delete a database with `IF{nbsp}EXISTS` and `DUMP DATA`/`DESTROY DATA`
Copy file name to clipboardExpand all lines: modules/ROOT/pages/database-administration/standard-databases/errors.adoc
+22-52Lines changed: 22 additions & 52 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -160,74 +160,44 @@ It produces a database dump that can be further examined and potentially repaire
160
160
[[quarantine]]
161
161
== Quarantined databases
162
162
163
-
There are two ways to get a database into a `quarantined` state:
164
-
165
-
* By using the xref:procedures.adoc#procedure_dbms_quarantineDatabase[`dbms.quarantineDatabase`] procedure locally to isolate a specific database.
166
-
The procedure must be executed on the instance whose copy of the database you want to quarantine.
167
-
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.
168
-
The quarantine state renders the database inaccessible on that instance and prevents its state from being changed, for example, with the `START DATABASE` command.
169
-
+
170
-
[NOTE]
171
-
====
172
-
If running in a cluster, database management commands such as `START DATABASE foo` will still take effect on the instances which have *not* quarantined `foo`.
173
-
====
174
-
175
-
* When a database encounters a severe error during its normal run, which prevents it from a further operation, Neo4j stops that database and brings it into a `quarantined` state.
163
+
When a database encounters a severe error during its normal run, which prevents it from a further operation, Neo4j stops that database and brings it into a `quarantined` state.
176
164
Meaning, it is not possible to restart it with a simple `START DATABASE` command.
177
-
You have to execute `CALL dbms.quarantineDatabase(databaseName, false)` on the instance with the failing database in order to lift the quarantine.
165
+
You have to run `CALL dbms.unquarantineDatabase(server, database, operation)` to lift the quarantine, specifying as `server` the instance with the failing database.
178
166
179
-
After lifting the quarantine, the instance will automatically try to bring the database to the desired state.
167
+
The `dbms.unquarantineDatabase()` procedure is introduced in Neo4j 2025.01 to replace the now-deprecated xref:procedures.adoc#procedure_dbms_quarantineDatabase[`dbms.quarantineDatabase`()].
180
168
181
-
[NOTE]
182
-
====
183
-
It is recommended to run the quarantine procedure over the `bolt://` protocol rather than `neo4j://`, which may route requests to unexpected instances.
184
-
====
169
+
After lifting the quarantine, the instance will automatically try to bring the database to the desired state.
| `databaseName` | String | The name of the database that will be put into or removed from quarantine.
196
-
| `setStatus` | Boolean | `true` for placing the database into quarantine; `false` for lifting the quarantine.
197
-
| `reason` | String | (Optional) The reason for placing the database in quarantine.
180
+
| `server` | String | The identifier of the server where the quarantine for database will be lifted.
181
+
| `database` | String | The name of the database that will be put into or removed from quarantine.
182
+
| `operation` | String | Optional operation to apply while lifting the quarantine.
198
183
|===
199
184
200
-
*Returns:*
185
+
The possible values for the optional operation are:
201
186
202
-
[options="header"]
203
-
|===
204
-
| Name | Type | Description
205
-
| `databaseName` | String | The name of the database.
206
-
| `quarantined` | String | Actual state.
207
-
| `result` | String | Result of the last operation.
208
-
The result contains the user, the time, and the reason for the quarantine.
209
-
|===
187
+
* `keepStateKeepStore` -- do nothing; leave store and cluster state as they are.
188
+
* `replaceStateKeepStore` -- join as a new member, clearing the current cluster state but keeping the store.
189
+
* `replaceStateReplaceStore` -- join as a new member, clearing both the current cluster state and the store.
210
190
211
-
[NOTE]
212
-
====
213
-
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.
214
-
====
191
+
If you choose to clear the current cluster state, the server will try to join as a new member,
192
+
but this joining can succeed if and only if there is a majority of old members "letting" the new members in.
193
+
Let's assume our cluster has a topology with three primaries.
194
+
If there is only one server in `QUARANTINED` mode, then it is safe to choose `replaceStateKeepStore` or `replaceStateReplaceStore`.
195
+
If there are two servers in `QUARANTINED` mode, then you should not use concurrently `replaceStateKeepStore` or `replaceStateReplaceStore` for both servers because there would be no majority to let them in.
3 row available after 100 ms, consumed after another 6 ms
230
-
----
231
201
232
202
.Check if a database is quarantined
233
203
[source, cypher]
@@ -251,7 +221,7 @@ neo4j@system> SHOW DATABASE foo;
251
221
====
252
222
A `quarantined` state is persisted for user databases.
253
223
This means that if a database is quarantined, it will remain so even if that Neo4j instance is restarted.
254
-
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.
224
+
You can remove it only by running the xref:procedures.adoc#procedure_dbms_unquarantineDatabase[`dbms.unquarantineDatabase()`] procedure.
255
225
256
226
The one exception to this rule is for the built-in `system` database.
257
227
Any quarantine for that database is removed automatically after instance restart.
The recommended best practices and methods for building efficient Docker images can be found at link:https://docs.docker.com/develop/develop-images/dockerfile_best-practices/[the Docker documentation -> Best practices for writing Dockerfiles].
| `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.
640
+
| `timeoutMilliseconds` | `INTEGER` | Specifies the maximum wait time for replication before marking it unsuccessful. Default value is 1000 milliseconds.
| `database` | `STRING` | The database for which a status check entry was replicated.
643
+
| `serverId` | `STRING` | The UUID of the server, which did or did not participate in a successful replication of the status check entry.
644
+
| `serverName` | `STRING` | The friendly name of the server, or its UUID if no name is set.
645
+
| `address` | `STRING` | The address of the Bolt port for the server.
646
+
| `replicationSuccessful` | `BOOLEAN` | Indicates if the server (on which the procedure is run) can replicate a transaction.
647
+
| `memberStatus` | `STRING` | The status of each primary member.
648
+
| `recognisedLeader` | `STRING` | The server id of the perceived leader of each primary member.
649
+
| `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.
650
+
| `requester` | `BOOLEAN` | Whether a server is the requester or not.
651
+
| `error` | `STRING` | Contains any error message if present. An example of an error is that one or more of the requested databases do not exist on the requester.
652
652
| *Mode* 3+| DBMS
653
653
|===
654
654
@@ -1056,7 +1056,7 @@ For more information, see the link:{neo4j-docs-base-uri}/cypher-manual/{page-ver
@@ -1076,6 +1076,43 @@ For more information, see the link:{neo4j-docs-base-uri}/cypher-manual/{page-ver
1076
1076
| *Mode* 3+| DBMS
1077
1077
|===
1078
1078
1079
+
[NOTE]
1080
+
====
1081
+
It is recommended to use <<procedure_dbms_unquarantineDatabase,`dbms.unquarantineDatabase()`>> over `dbms.quarantineDatabase()` due to its improvements and new features (see the `operation` option ).
1082
+
// The deprecated `dbms.quarantineDatabase()` procedure is available in Cypher 5, but not in Cypher 25.
| `server` | `STRING` | The identifier of the server where the quarantine for database will be lifted.
1096
+
| `database` | `STRING` | The name of the database for the quarantine will be lifted.
1097
+
| `operation` | `STRING` | Optional operation to apply while lifting the quarantine.
1098
+
| *Mode* 3+| DBMS
1099
+
|===
1100
+
1101
+
[NOTE]
1102
+
====
1103
+
The possible values for the optional operation are:
1104
+
1105
+
* `keepStateKeepStore` -- do nothing; leave store and cluster state as they are.
1106
+
* `replaceStateKeepStore` -- join as a new member, clearing the current cluster state but keeping the store.
1107
+
* `replaceStateReplaceStore` -- join as a new member, clearing both the current cluster state and the store.
1108
+
1109
+
If you choose to clear the current cluster state, the server will try to join as a new member,
1110
+
but this joining can succeed if and only if there is a majority of old members "letting" the new members in.
1111
+
Let's assume our cluster has a topology with three primaries.
1112
+
If there is only one server in `QUARANTINED` mode, then it is safe to choose `replaceStateKeepStore` or `replaceStateReplaceStore`.
1113
+
If there are two servers in `QUARANTINED` mode, then you should not use concurrently `replaceStateKeepStore` or `replaceStateReplaceStore` for both servers because there would be no majority to let them in.
0 commit comments