I have one virtual machine (VM_A) that runs one mysql database DB_A schema with 200 rows in his tbl_1. In another virtual machine (VM_B) that runs a copy of the same DB_A schema I have 50 rows in the tbl_1.
I would like to update the DB_B with the data from DB_A.
The tbl_2 holds a foreign key from tbl_1.
I've already made a mysql dump from DB_A to run in DB_B, to be updated.
I do not want to use drop schema, before drop tbl_1.
If I try to run the code in DB_B I will have a error caused by foreign key constarint in tbl_2.
What could be the best approach to update the DB_B in this scenario?
I have already tested this solution but not worked https://dba.stackexchange.com/questions/40046/is-there-a-way-to-truncate-table-that-has-foreign-a-key
https://dba.stackexchange.com/questions/40046/is-there-a-way-to-truncate-table-that-has-foreign-a-key is ms sql-server. in mysql modify your session variables
SET FOREIGN_KEY_CHECKS=0;
Related
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.
Using PySpark, I am updating a MySQL table. The schema has a unique key constraint on multiple three fields.
My Spark job will be running three times a day, since one of the column parts of the unique key is 'date'. I am getting a unique key constraint violation error if I am running a job more than once in a day.
Is there a way from Spark where we can delete the already-existing rows and insert new ones?
I searched the web for the solution, but I could not find any solution.
You should update the table on the database side. My suggestion is to create a temporary table in the MySQL database and the Spark job inserts data to the temporary table with overwrite mode.
Write a MySQL update script for the table with using a temporary table. And add a job chain after the Spark job to run the MySQL update script.
Assuming df.writer is being used, there isn't any UPSert mode currently.
I've tried to execute the following ALTER TABLE statement:
ALTER TABLE `my_table` ADD COLUMN `new_column` LONGTEXT NULL DEFAULT NULL AFTER `old_column`;
During the execution of the script I've got
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
It appears that this left database in inconsistent state, since no new field was added, and when I try to execute the script again, I'm getting this strange error.
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'my_db/#sql-ib520' already exists
I do not have #sql-ib520 table in my database, so to my understanding it must be some temp table created by the MySQL.
Does anyone encountered this error before, and how could I solve it?
Thanx
Edit
I've tried the script suggested by Alex, but I had not worked:
drop table `#mysql50##sql-ib520`;
ERROR 1051 (42S02): Unknown table 'my_db.#mysql50##sql-ib520'
Update
I'm using Amazon RDS with MySQL 5.6.12
I'm using an AWS RDS instance as well, and did a ton of reading on this problem. While I didn't find a great solution, here's how I fixed it by only replacing one table instead of the entire database.
If you run this command:
SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES
you can see the full list of database tables, including the orphaned table, which isn't normally visible. The two problem tables for me were:
ID NAME
407 my_database/#sql-ib379
379 my_database/users
because I was attempting to ALTER my users table when the DB crashed. Now, as mentioned above, I couldn't run any further ALTER TABLE commands because it was trying to create the same temporary table for any subsequent queries. I tried everything to DROP the orphaned table, but with the 'my_database/' part, it didn't seem possible. I also didn't want to drop and recreate my entire database, and I noticed that the orphaned table is referencing an internal ID of the users table (#sql-ib379), so I figured I would just swap it out. Here's a little MySQL script that did the trick for me:
-- temporarily disable foreign key checks
SET foreign_key_checks = 0;
-- replace this line with query to create a structural copy of the users table
-- named users_copy, including foreign keys if you use them
-- copy everything from original table into new table
INSERT INTO `users_copy` SELECT * FROM `users`;
Make sure everything looks ok, and then run:
-- rename the existing table
RENAME TABLE `users` TO `users_backup`;
-- in case the copy process took some time, and there were additional rows added
-- to the original table, grab them and put them into the copy table
INSERT INTO `users_copy` SELECT * FROM `users_backup` WHERE `users_backup`.id > (SELECT MAX(id) FROM `users_copy`);
-- finally, rename the copy table to the original table name
RENAME TABLE `users_copy` TO `users`;
- re-enable foreign key checks
SET foreign_key_checks = 1;
If you are not using foreign keys, you should be good to go now. I would recommend keeping the backup table around for a bit just in case, but once you remove that backup table, it should remove the orphaned table as well. If you are using foreign keys however, it is very important that you update any references to the original table name (in this case, users)! Depending on how you have your foreign keys setup, other tables that were dependent on users will now reference users_backup, which could cause problems with lost data.
Hope this helps.
After all, since I'm using AWS RDS instance, the script recommended by Alex did not work.
MySQL documentation also recommends this script, you can find more info here about orphaned intermediate tables.
For AWS RDS I've found only one post with no solution provided by Amazon staff. You might want to follow this post in case some solution is provided.
So, at the moment, my only solution was to dump the existing database and create a new one.
I'm trying to create some meta-data to extend mysql functionality but I can't create tables in the database INFORMATION_SCHEMA. I thought that I could just create another database and have my metadata in there but I need some foreign keys from my tables to some tables in the INFORMATION_SCHEMA DB. Nevertheless, I get errors when trying to create them. Then I thought I could create a trigger to get notified of changes but since triggers are associated to a table and I can't alter that database, I can't create triggers either.
Specifically I have some tables that references to information_schema.schemata(schema_name) and to information_schema.schemata(columns) and some others. I want to have those foreign key so I can use ON UPDATE CASCADE ON DELETE CASCADE or otherwise I'll have some rows in my tables referencing to nothing and I can't allow that.
I'm using mariaDB 5.5.30 which uses MySql 5.3.
INFORMATION_SCHEMA tables are actually views whose contents is automatically maintained by the MySQL server.
The manual gives more information:
Inside INFORMATION_SCHEMA there are several read-only tables. They
are actually views, not base tables, so there are no files associated
with them, and you cannot set triggers on them. Also, there is no
database directory with that name.
Although you can select INFORMATION_SCHEMA as the default database
with a USE statement, you can only read the contents of tables, not
perform INSERT, UPDATE, or DELETE operations on them.
They are not really views but temporary tables, that's why you don't see folders.
show create view views;
ERROR 1347 (HY000): 'information_schema./tmp/#sql_2ac_0' is not VIEW
Error 1217: Cannot delete or update a parent row: a foreign key constraint fails
SQL Statement: drop table s_a_user.main
i used "rpl -Ris ..." to check the sql dumps, and it's not in there. i queried the information schema, and it's not in there either. i think this is a bug, but i may just not be finding an elusive reference to this table. screenshot below shows all info needed.
http://tinypic.com/r/30lcu2t/6 - they resized it and it's hard to read, but the tables listed are s_a_user.resume, not s_a_user.main, so, in other words, it confirms there is nothing referencing this
==UPDATE==SOLVED==
this is a bug in mysql. "SHOW ENGINE INNODB STATUS" shows the error came from "s_a_mail.topic", which does not even exist [-_-] ...
to solve this: delete all innodb log files, delete the schema, delete the schema's directory, restart mysql with innodb_force_recovery=4 in your my.conf, remove the force recovery, restart mysql again, recreate the database schema, reimport the data backup, restart mysql with innodb_force_recovery=4 AGAIN, take out innodb_force_recovery=4 and restart AGAIN.
this fixes the foreign key problem, but now workbench crashes when accessing the s_a_user schema's tables, so now i get to investigate that... [-_-] i'm about to just build a new database system...
SET FOREIGN_KEY_CHECKS=0; DROP TABLE ´your_table´; SET FOREIGN_KEY_CHECKS=1;
This should help you.
Trick from Rune Kaagaard on this question