Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backfill Index: Minimize rejects due to schema version mismatch. #3284

Closed
amitanandaiyer opened this issue Jan 7, 2020 · 2 comments
Closed
Assignees
Labels
area/docdb YugabyteDB core features

Comments

@amitanandaiyer
Copy link
Contributor

amitanandaiyer commented Jan 7, 2020

If we are in the middle of updating IndexPermission(s) from one state to another, say from INDEX_PERM_DELETE_ONLY to INDEX_PERM_WRITE_AND_DELETE, then the YBClients will be given the older version (INDEX_PERM_DELETE_ONLY) while the permission is updated on all the tablets.

During this time, YBClients talking to the "updated" tablets may be rejected.

One way to address this may be to use a 8-step approach instead of a 4-step approach and allow the tservers to accept either of the 2 consecutive schema numbers.

Another way to get around this would be to pre-allocate the version numbers for the multiple stages of the Index creation; and allow tservers to accept versions that are newer than it's current version. This is only safe if the only change is the update to IndexPermissions -- if there is an update to the schema itself, the tserver must reject mismatched schemas.

@amitanandaiyer
Copy link
Contributor Author

partially addressed by #3627.

can be optimised further

@jaki
Copy link
Contributor

jaki commented Jun 17, 2020

This issue seems to be accentuated when using the TEST_slowdown_backfill_alter_table_rpcs flag.

YCQL:

./bin/yb-ctl create --master_flags 'disable_index_backfill=false,TEST_slowdown_backfill_alter_table_rpcs_ms=10000' --tserver_flags 'disable_index_backfill=false'
CREATE KEYSPACE k;
CREATE TABLE k.hn (
    i int PRIMARY KEY,
    j int)
  WITH
    transactions = { 'enabled' : true };
INSERT INTO k.hn (i, j) VALUES (1, 10);
./bin/ycqlsh --execute 'CREATE INDEX hn_idx ON k.hn (j);' &
while [ "$(jobs | wc -l)" -gt 0 ]; do
  ./bin/ycqlsh --execute 'UPDATE k.hn SET j = j + 100 WHERE i = 1;'
  sleep 0.2s
done

You should see

InvalidRequest: Error from server: code=2200 [Invalid query] message="Wrong Metadata Version

when replicating the DELETE ONLY to WRITE AND DELETE permission (tservers receive the new schema, but master still doesn't fully apply it).

YSQL:

./bin/yb-ctl create --master_flags `ysql_disable_index_backfill=false,TEST_slowdown_backfill_alter_table_rpcs_ms=10000' --tserver_flags 'ysql_disable_index_backfill=false'
CREATE TABLE hn (i int, j int, PRIMARY KEY (i));
INSERT INTO hn (i, j) VALUES (1, 10);
./bin/ysqlsh --command 'CREATE INDEX ON hn (j);' &
while [ "$(jobs | wc -l)" -gt 0 ]; do
  ./bin/ycqlsh --command 'SELECT * FROM hn;'
  sleep 0.2s
done

You should see

ERROR:  Query error: schema version mismatch for table 000030a9000030008000000000004005: 2 != 1

when replicating the DELETE ONLY to WRITE AND DELETE permission (tservers receive the new schema, but master still doesn't fully apply it).

The schema version mismatch is only for DELETE ONLY to WRITE AND DELETE because it goes through the UpdateIndexPermission code path (where the test flag adds sleeps).

amitanandaiyer added a commit that referenced this issue Feb 24, 2021
…lter tables.

Summary:
The idea here is to allow the proxies to get the *newer* schema version
with the information whether it can be accepted by a tserver that has an *older* schema (old by 1 version).
If the only change is a change to an index permission, and the schema part is the same, then we allow the request to be accepted.

To this end, we'd have to add the notion of whether a schema/request is compatible with the previous version.

Note that, for online schema changes, the TServer must never accept a schema version that is *older* than its own version. The change here is to allow it to accept something that is *newer* -- if the request explicitly mentions that it can be accepted.

Test Plan:
Jenkins.

ybd debug --cxx-test integration-tests_cassandra_cpp_driver-test --gtest_filter CppCassandraDriverTest*TestCreateMultipleIndex

Reviewers: jason, alex, mihnea

Reviewed By: mihnea

Subscribers: zyu, ybase

Differential Revision: https://phabricator.dev.yugabyte.com/D8946
polarweasel pushed a commit to lizayugabyte/yugabyte-db that referenced this issue Mar 9, 2021
…during alter tables.

Summary:
The idea here is to allow the proxies to get the *newer* schema version
with the information whether it can be accepted by a tserver that has an *older* schema (old by 1 version).
If the only change is a change to an index permission, and the schema part is the same, then we allow the request to be accepted.

To this end, we'd have to add the notion of whether a schema/request is compatible with the previous version.

Note that, for online schema changes, the TServer must never accept a schema version that is *older* than its own version. The change here is to allow it to accept something that is *newer* -- if the request explicitly mentions that it can be accepted.

Test Plan:
Jenkins.

ybd debug --cxx-test integration-tests_cassandra_cpp_driver-test --gtest_filter CppCassandraDriverTest*TestCreateMultipleIndex

Reviewers: jason, alex, mihnea

Reviewed By: mihnea

Subscribers: zyu, ybase

Differential Revision: https://phabricator.dev.yugabyte.com/D8946
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/docdb YugabyteDB core features
Projects
None yet
Development

No branches or pull requests

3 participants