Gh 587 describe tarantool migration #640
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fix bugs Add upgrade schema test for luatest Add test Fix test Fix bugs and style fix Fix remarks Delete unnecessary file Fix bugs Add compitibility.upgrade_schema for CI Fix test Add changelog
DHorrible
force-pushed
the
gh-587-describe-tarantool-migration
branch
from
b163ae8
to
e834154
Compare
olegrok
added a commit
that referenced
this pull request
Mar 20, 2020
This patch introduces new type of test - "upgrade". The main idea - try to bootstrap server with old schema version then this changes should be applied to all replicas in replicaset. We significant chnage from existing integration tests - we try to do this using prepeared snaps and wals. Need for #640
olegrok
added a commit
that referenced
this pull request
Mar 20, 2020
This patch introduces automatic schema upgrade. The main idea to apply box.schema.upgrade on the leader instance. We can't do it on each instance - it lead to replication conflicts. We can't delegate it to users becouse a bug: "Space 277 doesn't exist" (tarantool/tarantool#4691) still is not resolved. Closes #640
olegrok
added a commit
that referenced
this pull request
Mar 20, 2020
This patch introduces new type of test - "upgrade". The main idea - try to bootstrap server with old schema version then this changes should be applied to all replicas in replicaset. We significant chnage from existing integration tests - we try to do this using prepeared snaps and wals. Need for #640
olegrok
added a commit
that referenced
this pull request
Mar 20, 2020
This patch introduces automatic schema upgrade. The main idea to apply box.schema.upgrade on the leader instance. We can't do it on each instance - it lead to replication conflicts. We can't delegate it to users becouse a bug: "Space 277 doesn't exist" (tarantool/tarantool#4691) still is not resolved. Closes #640
olegrok
added a commit
that referenced
this pull request
Mar 20, 2020
This patch introduces new type of test - "upgrade". The main idea - try to bootstrap server with old schema version then this changes should be applied to all replicas in replicaset. We significant change from existing integration tests - we try to do this using prepared snaps and wals. Need for #640
olegrok
added a commit
that referenced
this pull request
Mar 20, 2020
This patch introduces automatic schema upgrade. The main idea to apply box.schema.upgrade on the leader instance. We can't do it on each instance - it lead to replication conflicts. We can't delegate it to users because a bug: "Space 277 doesn't exist" (tarantool/tarantool#4691) still is not resolved. Closes #640
3 tasks
olegrok
added a commit
that referenced
this pull request
Mar 20, 2020
This patch introduces new type of test - "upgrade". The main idea - try to bootstrap server with old schema version then this changes should be applied to all replicas in replicaset. We significant change from existing integration tests - we try to do this using prepared snaps and wals. Need for #640
olegrok
added a commit
that referenced
this pull request
Mar 20, 2020
This patch introduces automatic schema upgrade. The main idea to apply box.schema.upgrade on the leader instance. We can't do it on each instance - it lead to replication conflicts. We can't delegate it to users because a bug: "Space 277 doesn't exist" (tarantool/tarantool#4691) still is not resolved. Closes #640
olegrok
added a commit
that referenced
this pull request
Mar 20, 2020
This patch introduces automatic schema upgrade. The main idea to apply box.schema.upgrade on the leader instance. We can't do it on each instance - it lead to replication conflicts. We can't delegate it to users because a bug: "Space 277 doesn't exist" (tarantool/tarantool#4691) still is not resolved. Closes #640
olegrok
added a commit
that referenced
this pull request
Mar 22, 2020
This patch introduces automatic schema upgrade. The main idea to apply box.schema.upgrade on the leader instance. We can't do it on each instance - it lead to replication conflicts. We can't delegate it to users because a bug: "Space 277 doesn't exist" (tarantool/tarantool#4691) still is not resolved. Closes #640
olegrok
added a commit
that referenced
this pull request
Mar 23, 2020
This patch introduces new type of test - "upgrade". The main idea - try to bootstrap server with old schema version then this changes should be applied to all replicas in replicaset. We significant change from existing integration tests - we try to do this using prepared snaps and wals. Need for #640
olegrok
added a commit
that referenced
this pull request
Mar 23, 2020
This patch introduces an option - `upgrade_schema` to perform an upgrade procedure if we want to upgrade tarantool version. The main idea to apply box.schema.upgrade on the leader instance. We can't do it on each instance - it lead to replication conflicts if we have 2 or more writable instances. We don't do it automatically to give an ability for user to check that instances works fine with new tarantool version but old schema. This thesis is not relevant just now because of "Space 277 doesn't exist" (tarantool/tarantool#4691). But I hope it will be solved soon. Closes #640
olegrok
added a commit
that referenced
this pull request
Mar 23, 2020
This patch introduces new type of test - "upgrade". The main idea - try to bootstrap server with old schema version then this changes should be applied to all replicas in replicaset. We significant change from existing integration tests - we try to do this using prepared snaps and wals. Need for #640
olegrok
added a commit
that referenced
this pull request
Mar 23, 2020
This patch introduces an option - `upgrade_schema` to perform an upgrade procedure if we want to upgrade tarantool version. The main idea to apply box.schema.upgrade on the leader instance. We can't do it on each instance - it lead to replication conflicts if we have 2 or more writable instances. We don't do it automatically to give an ability for user to check that instances works fine with new tarantool version but old schema. This thesis is not relevant just now because of "Space 277 doesn't exist" (tarantool/tarantool#4691). But I hope it will be solved soon. Closes #640
olegrok
added a commit
that referenced
this pull request
Mar 24, 2020
This patch introduces new type of test - "upgrade". The main idea - try to bootstrap server with old schema version then this changes should be applied to all replicas in replicaset. We significant change from existing integration tests - we try to do this using prepared snaps and wals. Need for #640
olegrok
added a commit
that referenced
this pull request
Mar 24, 2020
This patch introduces an option - `upgrade_schema` to perform an upgrade procedure if we want to upgrade tarantool version. The main idea to apply box.schema.upgrade on the leader instance. We can't do it on each instance - it lead to replication conflicts if we have 2 or more writable instances. We don't do it automatically to give an ability for user to check that instances works fine with new tarantool version but old schema. This thesis is not relevant just now because of "Space 277 doesn't exist" (tarantool/tarantool#4691). But I hope it will be solved soon. Closes #640
rosik
pushed a commit
that referenced
this pull request
Mar 26, 2020
This patch introduces new type of test - "upgrade". The main idea - try to bootstrap server with old schema version then this changes should be applied to all replicas in replicaset. We significant change from existing integration tests - we try to do this using prepared snaps and wals. Need for #640
rosik
pushed a commit
that referenced
this pull request
Mar 26, 2020
This patch introduces an option - `upgrade_schema` to perform an upgrade procedure if we want to upgrade tarantool version. The main idea to apply box.schema.upgrade on the leader instance. We can't do it on each instance - it lead to replication conflicts if we have 2 or more writable instances. We don't do it automatically to give an ability for user to check that instances works fine with new tarantool version but old schema. This thesis is not relevant just now because of "Space 277 doesn't exist" (tarantool/tarantool#4691). But I hope it will be solved soon. Closes #640
|
Closing in favor of #671 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add new option
auto_upgrade_schema(boolen) forcartridge.cfgwhich pass inboot_instance. It is used for upgrade schema to actual tarantool version (only for leader). The option has bean added forargparse.I didn't forget about
Close #587