-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
partially addressed by #3627. can be optimised further |
This issue seems to be accentuated when using the 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
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
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 |
…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
…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
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.
The text was updated successfully, but these errors were encountered: