sql: Inconsistent zone config behavior when dropping database or table #24179
Assignees
Labels
A-schema-changes
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
Milestone
Comments
a-robinson
added
the
C-bug
knz
changed the title
vivekmenezes
added
A-schema-changes
and removed
A-schema-descriptors
|
to be fixed after #19004 is fixed. Once a job exists for the DROP DATABASE schema change, the job can be used to drop the zone config later. |
craig bot
pushed a commit
that referenced
this issue
Oct 11, 2018
30666: sql: delete db zone config after GC TTL r=eriktrinh a=eriktrinh Previously the database's zone config would be deleted immediately when a DROP DATABASE is initiated, including if there are tables that the drop cascades down to. This causes dropped tables waiting for the GC period without a table zone config to have values from the default config to be applied (which can cause unnecessary data movement). This change removes the database's zone config once all the cascaded table data is completely removed, using the dropped table status in the job details. Fixes #24179. Co-authored-by: Erik Trinh <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As "discovered" in #24154, we handle zone configs differently when dropping partitions/tables/databases.
The behavior when dropping a database is concerning. If (a) there's data in a table in the database (b) the table doesn't have a table-level zone config (c) the database does have a database-level zone config, then dropping the database (e.g.
DROP DATABASE ... CASCADE) has the effect of changing the zone config that applies to the data in the table. Before dropping the database, the databases's zone config applies to the table. After dropping the database, the global.defaultzone config is all that applies to the table.This means that when we drop a database, it can actually cause a lot of rebalancing if the database had different constraints on it than the
.defaultzone. Even if the database was constrained to certain regions for sovereignty reasons, the yet-to-be-GC'ed data will likely get moved elsewhere.For example, I created a 6 node local cluster with 3 nodes in locality
a=1and 3 ina=2. I created a table, split it 20 times, and constrained all its replicas toa=1around 16:07 in the below screenshot. At 16:09 I ranDROP DATABASE ... CASCADEon the database, and suddenly all the data got spread around across both localities because the constraint I had specified no longer existed.There may also be a similar problem with us deleting a table's zone config before all the data has been GC'ed. I'm not an expert in that area, though, so I'll let @benesch speak to that.
The text was updated successfully, but these errors were encountered: