Incorrect example for setting ssd mode in docs

Using FoundationDB
1

this doc for setting ssd mode says to just run configure ssd after installing fdb.

however testing this with a default install of fdb 7.1 it results in an error.

fdb> configure ssd
ERROR: Storage engine type cannot be changed because storage_migration_type=disabled.
Type `configure perpetual_storage_wiggle=1 storage_migration_type=gradual' to enable gradual migration with the perpetual wiggle, or `configure storage_migration_type=aggressive' for aggressive migration.

the right command seems to be:

fdb> configure storage_migration_type=aggressive ssd
Configuration changed

are the docs in need of updating?

2

Yes, that page is out of date. Prior to FDB 7.1, the only type of storage engine migration available and the default behavior was effectively the ā€œaggressiveā€ mode, which is actually not a good fit for busy production systems. In FDB 7.1, the migration type option was added, disabled by default, so you have to intentionally pick aggressive (the old behavior) or gradual to start a storage migration. The gradual option uses a new feature called the Perpetual Wiggle which will safely remove and re-add storage processes one by one. Documentation for this new feature is here but unfortunately the Configuration page does not mention this in the storage engine section.

Also, I suspect the specific error you are seeing will print for any attempted storage engine change even if the option isnā€™t really a change at all. For example, ssd is internally an alias for ssd-2, so when you configure new ssd to create a database you actually get ssd-2. If you attempt to configure ssd again I would guess you would see an error message because this appears to be a different engine name but no actual migration would occur.

cc: @sfc-gh-xwang

1 Like
3

is there no way to setup mode as ā€˜ssdā€™ in the config file so that the process starts in ssd mode first time itself without needing imperative configuration via the cli?

4

According to the RPM installer sources, it will always create and initialize a new instance with single memory if the cluster file does not already exist:

However, if you spin the docker image instead, it will be uninitialized by default, so you can just use a script to execute fdbcli .... --exec "configure new ssd single" to initialize it instantly to the SSD storage engine.