[docdb] Invalidate YCQL system.partitions cache on create table #17683
Assignees
Labels
2.14 Backport Required
2.16 Backport Required
2.18 Backport Required
area/docdb
YugabyteDB core features
kind/bug
This issue is a bug
priority/medium
Medium priority issue
Comments
yugabyte-ci
added
kind/bug
sanketkedia
added a commit
that referenced
this issue
Jun 21, 2023
…tion Summary: Adding gflag `invalidate_yql_partitions_cache_on_create_table` that controls if we invalidate the cache on ycql table creation. This ensures that a new table will be seen immediately in system.partitions since the next query or next bg refresh would do a full rebuild of the cache. Introducing states to YQLPartitionsVTable to make logic easier to follow, now there are INVALID, INVALID_BUT_REBUILDING, and VALID states that determine what to return. When invalidating on table creation, we just need to modify this atomic state as opposed to grabbing the entire mutex. Also refactoring some of the generate on changes code to make it simpler. Also setting the default for system.partitions to use the background thread by default with these gflags changes: ``` partitions_vtable_cache_refresh_secs: 0 -> 30 generate_partitions_vtable_on_changes: true -> false ``` Jira: DB-6793 Test Plan: ``` ybd --gtest_filter CppCassandraDriverTest.YQLPartitionsVtableCacheRefresh -n 50 ``` Reviewers: bogdan, slingam, sergei, jhe Reviewed By: sergei Subscribers: ybase Differential Revision: https://phorge.dev.yugabyte.com/D26038
dr0pdb
pushed a commit
to dr0pdb/yugabyte-db
that referenced
this issue
Jul 6, 2023
…ble creation Summary: Adding gflag `invalidate_yql_partitions_cache_on_create_table` that controls if we invalidate the cache on ycql table creation. This ensures that a new table will be seen immediately in system.partitions since the next query or next bg refresh would do a full rebuild of the cache. Introducing states to YQLPartitionsVTable to make logic easier to follow, now there are INVALID, INVALID_BUT_REBUILDING, and VALID states that determine what to return. When invalidating on table creation, we just need to modify this atomic state as opposed to grabbing the entire mutex. Also refactoring some of the generate on changes code to make it simpler. Also setting the default for system.partitions to use the background thread by default with these gflags changes: ``` partitions_vtable_cache_refresh_secs: 0 -> 30 generate_partitions_vtable_on_changes: true -> false ``` Jira: DB-6793 Test Plan: ``` ybd --gtest_filter CppCassandraDriverTest.YQLPartitionsVtableCacheRefresh -n 50 ``` Reviewers: bogdan, slingam, sergei, jhe Reviewed By: sergei Subscribers: ybase Differential Revision: https://phorge.dev.yugabyte.com/D26038
sanketkedia
added a commit
that referenced
this issue
Jul 17, 2023
…e on table creation Summary: Original commit: 776f368 / D26038 Adding gflag `invalidate_yql_partitions_cache_on_create_table` that controls if we invalidate the cache on ycql table creation. This ensures that a new table will be seen immediately in system.partitions since the next query or next bg refresh would do a full rebuild of the cache. Introducing states to YQLPartitionsVTable to make logic easier to follow, now there are INVALID, INVALID_BUT_REBUILDING, and VALID states that determine what to return. When invalidating on table creation, we just need to modify this atomic state as opposed to grabbing the entire mutex. Also refactoring some of the generate on changes code to make it simpler. Also setting the default for system.partitions to use the background thread by default with these gflags changes: ``` partitions_vtable_cache_refresh_secs: 0 -> 30 generate_partitions_vtable_on_changes: true -> false ``` Jira: DB-6793 Test Plan: ``` ybd --gtest_filter CppCassandraDriverTest.YQLPartitionsVtableCacheRefresh -n 50 ``` Reviewers: bogdan, slingam, sergei, jhe Reviewed By: jhe Subscribers: ybase Differential Revision: https://phorge.dev.yugabyte.com/D26719
sanketkedia
added a commit
that referenced
this issue
Jul 17, 2023
…e on table creation Summary: Original commit: 776f368 / D26038 Adding gflag `invalidate_yql_partitions_cache_on_create_table` that controls if we invalidate the cache on ycql table creation. This ensures that a new table will be seen immediately in system.partitions since the next query or next bg refresh would do a full rebuild of the cache. Introducing states to YQLPartitionsVTable to make logic easier to follow, now there are INVALID, INVALID_BUT_REBUILDING, and VALID states that determine what to return. When invalidating on table creation, we just need to modify this atomic state as opposed to grabbing the entire mutex. Also refactoring some of the generate on changes code to make it simpler. Also setting the default for system.partitions to use the background thread by default with these gflags changes: ``` partitions_vtable_cache_refresh_secs: 0 -> 30 generate_partitions_vtable_on_changes: true -> false ``` Jira: DB-6793 Test Plan: ``` ybd --gtest_filter CppCassandraDriverTest.YQLPartitionsVtableCacheRefresh -n 50 ``` Reviewers: bogdan, slingam, sergei, jhe Reviewed By: jhe Subscribers: ybase Differential Revision: https://phorge.dev.yugabyte.com/D26721
sanketkedia
added a commit
that referenced
this issue
Jul 17, 2023
…e on table creation Summary: Original commit: 776f368 / D26038 Adding gflag `invalidate_yql_partitions_cache_on_create_table` that controls if we invalidate the cache on ycql table creation. This ensures that a new table will be seen immediately in system.partitions since the next query or next bg refresh would do a full rebuild of the cache. Introducing states to YQLPartitionsVTable to make logic easier to follow, now there are INVALID, INVALID_BUT_REBUILDING, and VALID states that determine what to return. When invalidating on table creation, we just need to modify this atomic state as opposed to grabbing the entire mutex. Also refactoring some of the generate on changes code to make it simpler. Also setting the default for system.partitions to use the background thread by default with these gflags changes: ``` partitions_vtable_cache_refresh_secs: 0 -> 30 generate_partitions_vtable_on_changes: true -> false ``` Jira: DB-6793 Test Plan: ``` ybd --gtest_filter CppCassandraDriverTest.YQLPartitionsVtableCacheRefresh -n 50 ``` Reviewers: bogdan, slingam, sergei, jhe Reviewed By: jhe Subscribers: ybase Differential Revision: https://phorge.dev.yugabyte.com/D26722
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Jira Link: DB-6793
As part of enabling
partitions_vtable_cache_refresh_secswe need to fix the perf issue during table creates.During table creates with the bg thread cache refresh, the driver can get a stale cache read which does not contain the new table, thus causing us to make an extra network hop to find the tablet leader.
One easy way to fix this is to invalidate the cache at the end of create table - this will force the first
select * from system.partitionsor bg thread update (whichever happens first) to fully refresh the cache and include the new table.The text was updated successfully, but these errors were encountered: