I'm taking a backup from a standalone database using the following command:
mysqldump -u <user> -p --databases <some databases> --no-create-info --no-create-db --skip-triggers --single-transaction --compress --order-by-primary > data.sql
When I'm importing the data into a MySQL Group Replication, I get this error:
ERROR 3098 (HY000) at line 2150: The table does not comply with the requirements by an xternal plugin.
The last line that the restore ran was: alter table disable keys and the error stopped appearing when the alter table enable keys.
Managed to figure it out.
One of the MySQL GroupReplication requirements is to have a Primary Key for each table. Unlike Standalone Mysql that doesn't require it.
I took the data from a Standalone Mysql and tried to import it into a Group Replication.
As I find out, only 1 table didn't have a Primary Key so the import always failed on that table with that error.
Related
We have a cron that does a full dump of the MySQL5 server, and in tests of restore on a empty instance, it restores all bases, including mysql with mysql.user carrying users and permissions together.
In MySQL8 because mysql base is system, the --add-drop-database and --all-databases attributes conflict giving an error in the restore "ERROR 3552 (HY000) at line 19044: Access to system schema 'mysql' is rejected.", as it is not allowed to drop the mysql base.
Has anyone managed to get around this situation and bring users and privileges together in MySQL8 in same dumpfile?
This is the command i run to dump:
mysqldump --add-drop-database --flush-logs --single-transaction --ignore-table=mysql.innodb_index_stats --ignore-table=mysql.innodb_table_stats --quick --all-databases --triggers --routines --events -u root --password='senha' -P 3306 -h 1.1.1.1 | bzip2 > /tmp/backup.sql.bz2
The problematic SQL:
/*!40000 DROP DATABASE IF EXISTS `mysql`*/;
The best way to walk around this, just open the dump SQL file, delete this SQL,
if the file is too big, use sed.
I ran into this same scenario. I dumped a broken instance with all databases and using add-drop-statement to try and save the data, but when I went to restore it I was blocked. You can no longer drop the mysql system database.
My database backup was something like 150gb, and opening it manually was not an option (a shame as i could tell by doing head -n 50 backup.sql that the problematic statement was within the first few lines).
the statement to remove was
/*!40000 DROP DATABASE IF EXISTS `mysql`*/;
and the sed command for me was:
sed -i 's/\/\*!40000 DROP DATABASE IF EXISTS `mysql`\*\/;/ /g' backup.sql
I would paste the statement into an empty text file first, and run the command to confirm that it actually works. This way you don't waste a ton of time on the execution of a very large backup file -- as there's a chance with your version of sed, or OS, that it might resolve the regular expression differently.
ERROR 3554 (HY000) at line 318: Access to system table 'mysql.innodb_index_stats' is rejected.
Operation failed with exitcode 1
11:27:20 Import of C:\Users\VELOXSHOP\Downloads\dumpfilename.sql has finished with 1 errors
How do I allow acess to that table?
You'll need to make a new dump/backup of your old database, this time remove those innodb tables from your target. You can do this by using --ignore-table parameter on the command line:
mysqldump -u root -p --all-databases --ignore-table=mysql.innodb_index_stats --ignore-table=mysql.innodb_table_stats > dump.sql
Then you should be able to restore your backup on the new database using the command below:
mysql -u root -p < dump.sql
You can also circumvent this error using the --force option which causes mysql client to continue despite errors.
Try to add -f to your command like so:
mysql -u root -p -f < dump.sql
-f means --force.
This did the trick for me!
It seems to be restricted in Mysql 8. Remove the insert statement from the sql file. You may have to use sed if the file is very large
https://stackoverflow.com/a/26379517/1106420
https://bugs.mysql.com/bug.php?id=92675
That is a MySQL system table and it's unlikely that you should be inserting records into it directly. MySQL should update the table when it calculates new statistics for indexes when thresholds pass.
Inspect line 318 and figure out why it's trying to insert into that table.
Let's say I have created a MySQL database (in an encapsulated local development environment):
$ mysql -uroot -proot -e "create database FOO"
And imported an SQL dump:
$ mysql -uroot -proot FOO < /var/tmp/BAR.sql
And now I simply re-import a newer dump from the same source:
$ mysql -uroot -proot FOO < /var/tmp/FUBAR.sql
Questions: Is this a reliable method to simply import the newest data? Will existing tables simply be overwritten? As far as I can inspect it seems to be no problem. Or should I always better drop the database first, recreate it and then import the newer dump?
Depends on the dump file. If it has DROP TABLE IF EXISTS and CREATE TABLE statements, it will overwrite tables. But it can also do any other thing SQL allows you to do - alter tables, only insert data, etc.
I see nothing unreliable in that.
I have database A. I issue this command against it:
mysqldump --host=localhost -uroot -p"mypassword" my_db_name > file.sql
now I take this file to machine B, running mysql too. I create a database:
create database newdb;
I then:
mysql --host=localhost -uroot -proot newdb < file.sql
My problem is that not all tables that exist in file.sql are created in the new database! I clearly see CREATE TABLES users in the content of the file.sql followed by thousands of INSERT calls for content in that table.
But users table is never created in the new database. I am completely lost as to why.
If you have foreign keys, the tables might be created in the wrong order and since the constraints can't be created, creating the table fails. Try adding SET FOREIGN_KEY_CHECKS=0 in the beginning of the dump and SET FOREIGN_KEY_CHECKS=0 at the end.
Delete whole newdb database;
Restart mysqld;
Run mysqlcheck --repair --all-databases -u root -p root on machine B;
Create newdb again (or maybe call it newdb2 just to be sure);
Delete file.sql on machine B, copy file.sql again from machine A and import by mysql --host=localhost -uroot -proot newdb < file.sql;
Run SHOW engine innodb STATUS; and or show table status and analyze results.
Copy a CREATE TABLE that failed to work. In the commandline tool "mysql", paste that. What messages, if any do you get? Does it create the table?
Please provide that CREATE for us; there may be some odd clues.
Also provide SHOW VARIABLES LIKE '%enforce%';
I currently using mysqldump command as follows
mysqldump -u username -p -h hostName database tableName > dump.sql
and it fails with emitting the following error
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `table_name` at row: 1652788
Is there any other way (perhaps a parameter to mysqldump or etc) for exporting large MySQL tables?
You can add a parameter --single-transaction to the mysql dump command if you are using innodb engine. This will eliminate locks on the table and possible connection timeouts.
Also, ensure that you have given sufficient values for max packet size, and innodb lock wait timeout