@@ -9,6 +9,49 @@ upgrading to ArangoDB 3.12, and adjust any client programs if necessary.
9
9
10
10
The following incompatible changes have been made in ArangoDB 3.12:
11
11
12
+ ## Little-endian on-disk key format for the RocksDB storage engine
13
+
14
+ ArangoDB 3.12 does not support the little-endian on-disk key for the RocksDB
15
+ storage engine anymore.
16
+
17
+ The little-endian on-disk key format was used for deployments that were created
18
+ with either ArangoDB 3.2 or 3.3 when using the RocksDB storage engine.
19
+ Since ArangoDB 3.4, a big-endian on-disk key format is used for the RocksDB
20
+ storage engine, which is more performant than the little-endian format.
21
+
22
+ Deployments that were set up with the RocksDB storage engine using ArangoDB 3.2
23
+ or 3.3 and that have been upgraded since then still use the old format.
24
+ This should not affect many users because the default storage engine in ArangoDB
25
+ 3.2 and 3.3 was the MMFiles storage engine.
26
+ Furthermore, deployments that have been recreated from a dump using arangodump
27
+ since ArangoDB 3.4 are not affected because restoring a dump into a fresh
28
+ deployment also makes ArangoDB use the big-endian on-disk format.
29
+
30
+ ArangoDB 3.11 logs a warning message during startup when the little-endian
31
+ on-disk format is in use, but it still supports using the little-endian key format
32
+ for almost all operations, with the following exceptions:
33
+ - Parallel index creation is disabled when the little-endian key format is used.
34
+ Indexes are always created using a single thread.
35
+ - The experimental version of arangodump (invocable via the ` --use-experimental-dump `
36
+ startup option) does not work. You can still use the traditional
37
+ arangodump version, which is the default anyway.
38
+
39
+ ArangoDB 3.12 and later refuse to start when detecting that the little-endian
40
+ on-disk is in use, so users that still use this format
41
+ ** must migrate to the big-endian on-disk key format before upgrading to 3.12** .
42
+
43
+ The migration can be performed as follows:
44
+
45
+ 1 . Create a full logical backup of the database using [ arangodump] ( programs-arangodump.html )
46
+ 2 . Stop the database servers in the deployment
47
+ 3 . Wipe the existing database directories
48
+ 4 . Restart the servers in the deployment
49
+ 5 . Restore the logical dump into the deployment using arangodump
50
+
51
+ It is not sufficient to take a hot backup of a little-endian deployment and
52
+ restore it because when restoring a hot backup, the original database format is
53
+ restored as it was at time of the backup.
54
+
12
55
## In-memory cache subsystem
13
56
14
57
By default, the in-memory cache subsystem uses up to 95% of its configured
0 commit comments