-
Notifications
You must be signed in to change notification settings - Fork 99
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
MySQL 8: use low lock_wait_timeout with workspace=temp-schema
This commit adjusts DDL calls in workspace=temp-schema to use a session-level lock_wait_timeout=5 (seconds) if the database is running MySQL 8. This is a safety precaution in case cross-schema foreign keys are present. MySQL 8 made some changes to foreign key metadata locking, which means the workspace DDL is not fully isolated from other workloads/queries' metadata locking if cross-schema foreign keys are in use. Background: MySQL and MariaDB use metadata locking (MDL) to ensure table structure does not change while transactions are already in-progress. Generally, read and write queries obtain shared MDL on any table mentioned in the query. DDL requires an exclusive lock; it queues behind any in-progress transactions, but in front of any other new pending transactions that come in after the DDL. The lock_wait_timeout session variable controls how long a query will wait to obtain a metadata lock before timing out. However, this variable has extremely high defaults: 1 year in MySQL, or 1 day in MariaDB 10.2+. This means that in the event of pending/queued metadata locking, by default the observed effect will appear to be a complete stall of the affected queries. Ordinarily, Skeema's default setting of workspace=temp-schema is isolated from the metadata locking of other workloads/queries, since it uses a dedicated database schema (_skeema_tmp by default) for performing all operations. In other words, DDL performed in _skeema_tmp wouldn't interact with metadata locking of things outside of _skeema_tmp. MySQL 8's change: In MySQL 8, metadata locking is also extended to the "parent" side of a foreign key (FK) constraint. This means that if you create a table with an FK (which is always specified on the "child" side), this DDL will be affected by any MDL on the "parent" (referenced) side table as well. If there's already a slow transaction querying a table, and you attempt to execute a CREATE TABLE with a child-side FK referencing this parent table, the CREATE TABLE will block until the slow transaction completes. Not only that, but all subsequent queries (of any type!) on the parent table will now block as well, since they are queued behind the blocked CREATE TABLE. Impact in Skeema (MySQL 8 + cross-schema FKs + workspace=temp-schema): In Skeema, this MySQL 8 change can be problematic whenever cross-schema FKs are in-use: that is, the child and parent tables are located in different schemas. Skeema's workspace model operates on one schema at a time, running the *.sql CREATEs in a temporary location so that they can be introspected from information_schema. With cross-schema FKs, this means the "parent" side is a real non-workspace table. Previously, this had no harmful impact. But with MySQL 8 extending MDL to the parent, it can be prone to the stall situations described above. Note that same-schema FKs are unaffected by this problem in Skeema, since both sides of the FK will be in the workspace (e.g. _skeema_tmp), so there's no exposure to MDL conflicts with "real" application/service query workloads. Also note that workspace=docker is unaffected by this problem, since it moves workspace operations to an isolated ephemeral containerized database. And since workspace operations use session-level foreign_key_checks=0, it isn't a problem if the parent side schema or table of a cross-schema FK simply does not exist at all in the containerized database. The improvement in this commit: Whenever using workspace=temp-schema in MySQL 8, this commit now applies a session-level lock_wait_timeout=5 to DDL operations in workspaces, with up to one retry per DDL. This means that in the case of a single slow transaction on the parent side of a cross-schema FK, the maximum stall time should be about 10 seconds, rather than 1 year. Skeema will emit an error and move on to the next subdir in this situation, which is non-ideal, but still much preferable to a long stall requiring manual query-killing. Even so, MySQL 8 users with cross-schema foreign key constraints should consider using workspace=docker whenever possible, to ensure full isolation of metadata locks. Additional workspace options may be introduced in the future to provide other alternatives; for example see #94 which will be prioritized in the coming months.
- Loading branch information
Showing
12 changed files
with
308 additions
and
64 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.