Overview of Lock-Free Schema Change

Scenarios

In high-concurrency environments, executing DDL operations on database tables often leads to performance bottlenecks due to table locking, which affect normal business operations. TaurusDB integrates the gh-ost to provide lock-free schema changes, allowing DDL operations to run without locking the original tables' data. This reduces business impact while ensuring data consistency and integrity through transaction management.

Usage Recommendations

• Perform lock-free schema changes during off-peak hours.
• Avoid using session variables to modify environmental parameters (such as the session-level parameter time_zone) during the change process.
• Avoid executing long-running transactions on the application side during the change process.
• Avoid reducing column constraints, lengths, type ranges, or precision in the target table after the change (such as shortening VARCHAR length, downgrading integer ranges, reducing DECIMAL precision, or changing NULL to NOT NULL when null values exist), as this can cause data truncation, numeric overflow, or data loss.

Constraints

• Change SQL statements must use the ALTER TABLE syntax. For details, see the official documentation for ALTER TABLE Statement.
• This feature is supported only for TaurusDB Enterprise Edition cluster instances. Ensure that the instance, primary node, and read replicas are all running properly before the change.
• Each task supports a maximum of 10 ALTER TABLE statements on different tables. Each statement must end with a semicolon (;). Multiple ALTER TABLE statements cannot modify the same table.
• The integrated gh-ost version (v1.1.4) does not support MySQL's native INSTANT algorithm. If you want to perform a lock-free schema change using it, connect to the database and execute the statements directly.
• Target databases/tables must meet the following requirements.

  Table 1 Target database/table constraints

  Category	Constraints
  Table type	Temporary tables, system tables, and views are not supported.
  Storage engine and character set	The storage engine must be InnoDB. Tables using the latin1 character set are not supported.
  Table structure	Partitioned tables are not supported. Tables without a primary key are not supported. Primary key columns cannot be of the JSON, FLOAT, or BINARY type. SET columns and virtual columns are not supported.
  Foreign key and trigger	The target table cannot contain foreign keys or be referenced by foreign keys in other tables. The target table cannot contain triggers.
  Column and index	Changing the table's character set or collation is not supported. Changing the table's storage engine is not supported. Adding, deleting, or modifying full-text or spatial indexes is not supported.
  Operation	Renaming, dropping, modifying, or adding primary keys is not supported. Renaming tables is not supported. Tables named ~{tablename}_ghc or ~{tablename}_gho cannot exist in the target database. Operations such as TRUNCATE TABLE, DROP TABLE, and clearing tables are not supported. Renaming columns or modifying any columns with FIRST or AFTER clauses to adjust physical column order is not supported.