MySQL raises warning 3010 when a trigger definition lacks the CREATED attribute that stores its creation timestamp.
ER_WARN_TRIGGER_DOESNT_HAVE_CREATED (Error 3010) warns that a trigger was created before MySQL stored the CREATED timestamp. Recreate the trigger with CREATE TRIGGER or ALTER TRIGGER to add the missing CREATED attribute and silence the warning.
ER_WARN_TRIGGER_DOESNT_HAVE_CREATED
MySQL error 3010 appears as ER_WARN_TRIGGER_DOESNT_HAVE_CREATED and states Trigger db.table.trigger_name does not have CREATED attribute. The server is alerting you that the trigger definition in INFORMATION_SCHEMA.TRIGGERS lacks the CREATED column that stores the timestamp of when the trigger was first created.
This warning was introduced in MySQL 5.7.2 during improvements to trigger metadata. Triggers created before that version, or copied from dumps produced by older servers, may miss the new attribute. The code still executes, but MySQL flags it so you can refresh the metadata.
Most occurrences trace back to legacy triggers created on MySQL versions prior to 5.7.2 when the CREATED column did not exist. After an upgrade, the server imports the trigger definition but marks the missing field.
The warning also surfaces when you restore a dump generated with --skip-timestamps or when you manually insert rows into mysql.trigger without the created field. Any trigger lacking the attribute will cause the notice at startup or during SHOW TRIGGERS.
The definitive fix is to recreate or alter each affected trigger so MySQL writes a fresh definition that includes the CREATED timestamp. Use CREATE OR REPLACE TRIGGER (MySQL 8.0) or DROP TRIGGER followed by CREATE TRIGGER on earlier versions.
Always script the original trigger body before dropping it. Galaxy users can select the trigger in the sidebar, copy its definition, and let the AI copilot regenerate the CREATE statement with proper metadata.
During an in-place upgrade, the server logs dozens of warnings for old triggers. Generate a script with SHOW CREATE TRIGGER, then recreate them in a rolling fashion to avoid downtime.
When restoring a logical backup, pass the --triggers option to mysqldump on a 5.7+ server so the dump includes CREATED values. Importing that file eliminates the warning.
Always create triggers on a server that matches or exceeds the production version. Store DDL in version control and recreate objects after major upgrades.
Automate nightly checks: SELECT TRIGGER_NAME FROM INFORMATION_SCHEMA.TRIGGERS WHERE CREATED IS NULL. Galaxy can schedule this query and alert the team when any new trigger lacks metadata.
Error 1359: TRG_ALREADY_EXISTS occurs when creating a duplicate trigger - drop or rename the existing trigger first.
Error 1360: TRG_DOES_NOT_EXIST happens on DROP TRIGGER if the trigger name is wrong - verify the schema and name.
Error 1235: ER_UNSUPORTED_ACTION_ON_INSTANCE warns when attempting unsupported trigger operations on a read-only replica - run DDL on the primary node.
Older servers did not store the CREATED column, so upgrading surfaces the warning.
mysqldump generated with older versions or with --skip-timestamps omits the CREATED field.
Direct manipulation of the mysql system tables can leave NULL created values.
Raised when a CREATE TRIGGER statement tries to use an existing trigger name on the same table and timing.
Thrown when DROP TRIGGER cannot find the specified trigger in the given schema.
Appears when DDL for triggers or routines runs on a read-only or replica server.
No, it is a warning only. The trigger continues to fire, but MySQL advises you to refresh its metadata.
You can, but recreating the trigger removes log noise and ensures forward compatibility with future MySQL versions.
Recreating is instant if done during low traffic. Wrap the process in a transaction where supported to minimize impact.
Galaxy surfaces warnings in the results pane, auto-generates CREATE TRIGGER scripts, and saves them in version-controlled collections for easy redeployment.
.avif)
.avif){kind=logo}
