I dropped an entire database and am now trying to create a new database of the same name (a modified version of the old one, using an install script in case you are wondering why I am doing this).
The database fails on creation with a foreign key constraint (which is strange as the line of the sql file is way before I add constraints - the last time in the sql file).
Even stranger if I look in "information_schema" in the referential_constraints table I see the constraints still there from the schema I had dropped recently.
I am running MySQL community servers 8.0.22 under macOS Catalina. I have never had this behaviour that a constraint is free floating without an active schema that later invokes itself if you create a schema with that same name (note if I change the database name to any other name the SQL script loads no problem and creates the entire db)
Related
I am trying to migrate a MariaDB database to MySQL. To do this I have created a mysqldump of the MariaDB database and am attempting to import into MySQL. (This is being done with the official docker container mysql:latest).
I am getting the following error when importing into MySQL:
ERROR 3822 (HY000) at line 172: Duplicate check constraint name 'CONSTRAINT_1'.
If I look at the mysqldump file I can see why this is happening. All boolean columns in my database have a constraints that looks something like:
CONSTRAINT `CONSTRAINT_1` CHECK (`bool_col_1` in (0,1))
CONSTRAINT `CONSTRAINT_2` CHECK (`bool_col_2` in (0,1))
CONSTRAINT `CONSTRAINT_3` CHECK (`bool_col_3` in (0,1))
These constraints were not explicitly created by me but implicitly by Flask-SQLAlchemy (I think).
Notice how the constraint names are incremented starting with CONSTRAINT_1. Well the problem is that each table starts incrementing its constraint names starting with CONSTRAINT_1. Thus the error I am seeing gets thrown when trying to create the second table.
I'd like to know how best to solve this while keeping the integrity of my database intact.
Today I failed to delete a record from a table in my database. I tried on both of my database management applications in MAC: MySQL Pro and MySQLWorkbench, but each of them created different error!
MySQL Pro
MySQLWorkbench
For both MySQL Pro and MySQLWorkbench, I am sure that I am log in using primary instance's link (not replica's) with user having DELETE privilege on this database.
Why the same database responds 2 different errors?
What settings should I look at in order to fix this?
I have checked all foreign keys referring to the record ID which I currently want to delete. It looks good.
Then I delete all records in the "child" tables referring to the ID of the record; and go back to delete the record -> it works!
I remember I had once changed a foreign keys from CASCADE for ON DELETE/UPDATE to NULL for ON DELETE/UPDATE, then I rolled back (CASCADE for ON DELETE/UPDATE). Not sure if that is the root cause.
Anyhow, I get my job done and I'd like to confirm that I have been working with the primary Aurora instance since the beginning, not replica.
i want to know if it's possible to drop a table fragment that is not letting me perform a restore with the NDB_RESTORE tool.
When i run the restore, it throws the following error:
Create table db_died_maestro/def/NDB$FKM_3194_0_mae_tipo_reg_evaluacion failed: 721: Schema object with given name already exists
Restore: Failed to restore table: db_died_maestro/def/NDB$FKM_3194_0_mae_tipo_reg_evaluacion ... Exiting
NDBT_ProgramExit: 1 - Failed
I have already drop the DB_DIED_MAESTRO database previous to run the restore, but this fragment is not being dropped along with the database.
I have check that the fragment is in the database catalog using this querys:
*select * from ndbinfo.operations_per_fragment
where fq_name like 'db_died_maestro%'*
query result
And this query:
*select * from ndbinfo.memory_per_fragment
where fq_name like '%FKM_3194_0_mae_tipo_reg_evaluacion'*
query 2 result
This fragment was created on a previous run of the NDB_RESTORE tool. Please help me.
The table is a foreign key 'mock' table (indicated by the name NDB$FKM prefix).
Foreign key mock tables are created transiently in some cases to implement the foreign_key_checks = 0 feature of MySQL. This feature requires storage engines to support unordered creation of tables with partially defined foreign key constraints which can be abritrarily enabled (without revalidation) at a later time.
Foreign key mock tables are normally entirely managed by the Ndb storage engine component of MySQL, and so should not be visible unless there has been a failure or bug of some kind.
If you can share information about activities occurring before this problem then that would help us understand how this happened and whether it can be avoided.
As a workaround it should be possible for you to use the ndb_drop_table utility to drop this table, before re-attempting the failing restore. You may have to escape the $ in the name passed as a command line argument from a shell. Probably you should check for any other NDB$FKM tables in a similar situation.
I'm trying to re-index the category flat data, but I am always met with the same error:
There was a problem with reindexing process. Error Message: SQLSTATE[HY000]: General error: 1005 Can't create table 'xxx.catalog_category_flat_store_6' (errno: 121)
The table doesn't exist, there is a 1 and a 7. Not sure if that makes a difference?
After running the query manually through phpMyAdmin, I am met with the MySQL error 121. I've checked around and this would suggest the names of the foreign keys trying to be created already exist. I've listed all foreign keys in the DB right now, and they don't exist at all.
I've also tried running SHOW ENGINE INNODB STATUS on the DB for more information, but we don't have the rights to view that apparently.
After getting the priv's updated so we could run SHOW INNODB STATUS, we discovered that we already had an existing index that was attempting to be duplicated with this new table. This stemmed from us backing up an older version of the table that was trying to be created. Deleting that copy of the table enabled Magento to re-index properly and solved our problem.
Try logging the sql commands and debug what its trying to do by executing them manually. On the index process, normally there is a command that clears a table, and another to recreate it.
Edit /magentoRoot/lib/Varien/Db/Adapter/Pdo/Mysql.php and change $_debug to true and note the $_debugFile location (should be var/debug/pdo_mysql.log)
Its best to edit the file in vi, have a browser open to reindex JUST the category data, save the file in vi :w! and then run the indexer then change the debug back to false.
Then go read the log. It may help.
I have a closed-source upgrade application which migrates my database from an old format to a new format (creates new tables and migrates data from the old to new tables).
The application crashes with a MySQLIntegrityConstraintViolationException. It doesn't give me the name of the table with the primary key violation or the contents of the broken SQL query.
Is there any MySQL server option that I can switch to give me more troubleshooting information? Maybe the text of the failed query or the name of the primary key constraint which is violated?
You can enable the general log file: http://dev.mysql.com/doc/refman/5.1/en/query-log.html . This way it might be possible to see at which point the server stops processing the queries.
You also can run the MySQL command show processlist to see what queries are being processed at that time.
Also have a look into all other application specific error logs.
A first try could be to disable foreign key checks during migration:
SET foreign_key_checks = 0;
A first guess would be, that the old server supported 0 as Primary Key values, whilst the new one does not.