mirror of
https://github.com/scylladb/scylladb.git
synced 2026-05-12 19:02:12 +00:00
b1465291cf
After upgrade from 1.7 to 2.0, nodes will record a per-table schema version which matches that on 1.7 to support the rolling upgrade. Any later schema change (after the upgrade is done) will drop this record from affected tables so that the per-table schema version is recalculated. If nodes perform a schema pull (they detect schema mismatch), then the merge will affect all tables and will wipe the per-table schema version record from all tables, even if their schema did not change. If then only some nodes get restarted, the restarted nodes will load tables with the new (recalculated) per-table schema version, while not restarted nodes will still use the 1.7 per-table schema version. Until all nodes are restarted, writes or reads between nodes from different groups will involve a needless exchange of schema definition. This will manifest in logs with repeated messages indicating schema merge with no effect, triggered by writes: database - Schema version changed to 85ab46cd-771d-36c9-bc37-db6d61bfa31f database - Schema version changed to 85ab46cd-771d-36c9-bc37-db6d61bfa31f database - Schema version changed to 85ab46cd-771d-36c9-bc37-db6d61bfa31f The sync will be performed if the receiving shard forgets the foreign version, which happens if it doesn't process any request referencing it for more than 1 second. This may impact latency of writes and reads. The fix is to treat schema changes which drop the 1.7 per-table schema version marker as an alter, which will switch in-memory data structures to use the new per-table schema version immediately, without the need for a restart. Fixes #3394 Tests: - dtest: schema_test.py, schema_management_test.py - reproduced and validated the fix with run_upgrade_tests.sh from git@github.com:tgrabiec/scylla-dtest.git - unit (release) Message-Id: <1524764211-12868-1-git-send-email-tgrabiec@scylladb.com>