<p>MySQL error 1602 (ER_TRG_CORRUPTED_FILE) appears when the server detects a damaged .TRG metadata file that stores trigger definitions for a table.</p>
<p>MySQL Error 1602: ER_TRG_CORRUPTED_FILE occurs when a table’s .TRG metadata file is unreadable or inconsistent. Restore the trigger definition by dropping and recreating the trigger or by replacing the corrupted .TRG file with a clean backup to resolve the issue.</p>
Corrupted TRG file for table `%s`.`%s`
Error 1602 signals that MySQL failed to parse the .TRG file holding trigger metadata for a specific table. The server marks the trigger as unusable and blocks DML that relies on it.
Because .TRG files live in the table’s data directory, file-system corruption, interrupted writes, or manual edits can break their internal XML-like structure, leading to this error during startup or any operation that loads triggers.
File-system corruption or unexpected shutdowns can truncate or zero-out .TRG files, leaving invalid markup that MySQL cannot read.
Manual copying of table files between servers without FLUSH TABLES WITH READ LOCK often skips associated .TRG files, causing version mismatches and corruption warnings.
Upgrades or downgrades that change trigger file format can break compatibility if the server reads older files without running mysql_upgrade.
Identify the corrupted .TRG file by reading the error log entry that names the table. Backup the table directory before any changes.
The fastest fix is to drop and recreate each affected trigger, which forces MySQL to generate a fresh .TRG file with correct metadata.
If the trigger definition is lost, recover it from a schema backup, mysqldump file, or the information_schema.triggers table on another replica.
During server startup, error 1602 can prevent the instance from serving traffic. Start MySQL with --skip-grant-tables, rename the corrupted .TRG file, then recreate triggers once the server is online.
When cloning data directories between environments, copy .TRG files along with .frm and .ibd files, or run mysqldump --triggers to keep metadata intact.
Use logical backups such as mysqldump or mysqlpump with --triggers to ensure portable trigger definitions.
Enable crash-safe settings like innodb_flush_log_at_trx_commit = 1 and sync_binlog = 1 to minimize file damage on power loss.
Version-control your trigger DDL in Git and regenerate triggers after deployments with an automated migration tool such as Flyway or Liquibase.
Error 1532 ER_TRG_NO_DEFINER indicates missing DEFINER information in the .TRG file; recreate the trigger with a valid DEFINER to solve it.
Error 1146 ER_NO_SUCH_TABLE appears if the .TRG file references a table that no longer exists; remove the trigger or create the missing table.
Sudden shutdown can interrupt disk writes, leaving partial data in the .TRG file.
Opening and saving .TRG files in a text editor may introduce invalid characters or encoding changes.
Physical backups taken without locking tables might copy data files but skip associated .TRG files.
Running a new MySQL version on old data files without mysql_upgrade can break trigger metadata compatibility.
Raised when the DEFINER user in the .TRG file does not exist. Recreate the trigger with a valid DEFINER.
Occurs if the trigger creation context is invalid. Ensure the character set and collation of the database match those stored in the .TRG file.
Appears when a trigger references a table that has been dropped. Remove or update affected triggers.
Check the MySQL error log; it prints the schema and table name whose TRG file failed to load.
In most cases, no. Recreating the trigger is safer than editing the XML inside the .TRG file.
Yes, mysqldump exports triggers unless --skip-triggers is used. Always keep triggers in backups.
Galaxy versions all trigger creation scripts in shared collections, letting teams quickly redeploy valid DDL to replace corrupted .TRG files.
.avif)
.avif){kind=logo}
