Box schema downgrade

[alyapunov]

PM link

Now there's a function box.schema.upgrade which make changes in DB so it becomes compliant to binary version. Now this function is called automatically at certain cases.

The idea is to improve this mechanism:

• Allow to pass a certain version to box.schema.upgrade (the latest by default).
• List all possible versions in box.schema.upgrade_list.
• Allow to downgrade at least down to 2.8 using box.schema.downgrade.

Note that downgrade, for example, from 2.10 to 2.8 must be run on 2.10 binary.

In some cases downgrade function will need to make snapshot or perhaps immediately stop tarantool process if it's needed.

[Totktonada]

Is it possible that some user's persistent object depends on a system object that was created during an upgrade? If so, we should detect this situation, discard the downgrade request and print the list of such user's objects (possibly with an instruction how to delete them).

[alyapunov]

Is it possible that some user's persistent object depends on a system object that was created during an upgrade? If so, we should detect this situation, discard the downgrade request and print the list of such user's objects (possibly with an instruction how to delete them).

It seems that in that case the system object must be impossible to remove and the downgrade process will naturally fall with fine readable error.

[Totktonada]

I looked at the 2.10 and 2.11 upgrade scripts that we have now:

tarantool/src/box/lua/upgrade.lua

Lines 1215 to 1242 in 302d91c

	--------------------------------------------------------------------------------
	-- Tarantool 2.10.1
	--------------------------------------------------------------------------------
	local function grant_rw_access_on__session_settings_to_role_public()
	local _priv = box.space[box.schema.PRIV_ID]
	log.info("grant read,write access on _session_settings space to public role")
	_priv:insert({ADMIN, PUBLIC, 'space', box.schema.SESSION_SETTINGS_ID,
	box.priv.R + box.priv.W})
	end
	local function upgrade_to_2_10_1()
	grant_rw_access_on__session_settings_to_role_public()
	end
	--------------------------------------------------------------------------------
	--------------------------------------------------------------------------------
	-- Tarantool 2.11.0
	--------------------------------------------------------------------------------
	local function revoke_write_access_on__collation_from_role_public()
	local _priv = box.space[box.schema.PRIV_ID]
	log.info("revoke write access on _collation space from public role")
	_priv:delete{PUBLIC, 'space', box.schema.COLLATION_ID}
	end
	local function upgrade_to_2_11_0()
	revoke_write_access_on__collation_from_role_public()
	end
	--------------------------------------------------------------------------------

Those upgrade scripts were introduced in 18eae24 and b771a5b.

It's interesting. My question is whether we should revert effects of those upgrades at downgrade. IOW, what is the goal of the downgrade call:

• Work in a replicaset with instances of an older tarantool version and allow to downgrade this particular instance to the older version.
• Imitate older version behavior as much as possible.

The latter doesn't seems meaningful, to be honest. We anyway run the new runtime.

The present upgrades looks really as just bugfixes. It seems that it is not worth to revert them at the downgrade call (if the upgrades allow an older tarantool version to bootstrap from the new snapshot and work correctly, we need to check it).

Any thoughts?

[Totktonada]

In the message above I missed 2.9.1 upgrade script:

tarantool/src/box/lua/upgrade.lua

Lines 1197 to 1213 in 302d91c

	--------------------------------------------------------------------------------
	-- Tarantool 2.9.1
	--------------------------------------------------------------------------------
	local function remove_sql_builtin_functions_from_func()
	local _func = box.space._func
	local _priv = box.space._priv
	for _, v in _func:pairs() do
	if v.language == "SQL_BUILTIN" then
	_priv:delete({2, 'function', v.id})
	_func:delete({v.id})
	end
	end
	end
	local function upgrade_to_2_9_1()
	remove_sql_builtin_functions_from_func()
	end

It seems, it really requires a downgrade counterpart.

We'll also add a new upgrade script in PR #7704, which, as I see, also will require a downgrade one.

[Totktonada]

Also a new upgrade script will be added in PR #7789, but I wouldn't revert it in the downgrade scripts.