Restoring mysql 5.6 dump to mysql 8 - mysql

Is it safe to restore a dump taken from mysql 5.6 aws rds instance to mysql 8 aws rds instance? Is there any incompatibilities we should worry about?
Thank you.

I faced below problem when restoring a dump from MySQL 5.7.16 to MySQL 8.0.28-0ubuntu0.20.04.3
ERROR 1231 (42000) at line 45316: Variable 'sql_mode' can't be set to
the value of 'NO_AUTO_CREATE_USER'
The solution that I used ;
sed -i 's/NO_AUTO_CREATE_USER//' my_file.sql
Refrence
Maybe you might face another problem
You should read Server and Status Variables and Options Added, Deprecated, or Removed in MySQL 8.0

Related

Restoring database after reinstallation of MySQL

I had to reinstall MySQL some time ago, before doing it I had moved /var/lib/mysql/mydatabase to another directory to be able to restore it after installation of MySQL.
After I installed MySQL I moved back this directory. When I go to mysql console and use
SHOW DATABASES;
it returns list of databases and 'mydatabase' is among the list.
When I switch to using 'mydatabase' and use
SHOW TABLES;
it shows the list of tables, but when I do any SELECT command I get this error:
ERROR 1146 (42S02): Table 'mydatabase.mytable1' doesn't exist
From the very beginning - was it enough to backup only /var/lib/mysql/< DATABASE_NAME > to restore database data or have I missed something? If yes then what I could try to fix this issue with 'table doesn't exist'?
MySQL version is 5.7, OS is Ubuntu 16.04
MySQL 5.7 default storage Engine is InnoDB. This stores the data in ibdata,ib_logfile0, and ib_logfile1. If you haven't backed up these files then you cannot restore the data.
It is suggestible that instead of moving your database files we should use mysqldump utility.
It is better to use innodb-file-per-table which can store InnoDB tables in a .ibd file per tables.

mySQL replication - 5.5 master to 5.7 slave and phpmyadmin.pma_recent errors

I have set up mySQL replication between two servers.
The master is running Ubuntu 14.04 with MySQL 5.5 and phpMyAdmin 4.0.10
The slave is running Ubuntu 16.04 with MySQL 5.7 and phpMyAdmin 4.5.4
I thought everything was running OK but checked the slave status the next day to find it had stopped with the error: Error 'Table 'phpmyadmin.pma_recent' doesn't exist' on query.
I have checked and the table does exist on both servers but the names differ slightly. The master is pma_recent (single underscore) and the slave is pma__recent (double underscore).
I have specified the databases I want replicating and didn't include the phpmyadmin database so I'm not sure why this would be causing a problem.
Can these tables be renamed? Would I need to change the config to point to the renamed tables?
Thanks in advance.

MySQL Import 4GB+ SQL on MySQL 5.6

I’m trying to import a 4GB+ SQL to MySQL 5.6 (64-bit) on Windows 7 (64-bit)
The problem is I after a few seconds (), get this message:
ERROR 2006 (HY000) at line 204: MySQL server has gone away
It does import, but it only the first 3 tables (the first 2 and the 3rd table just the structure.
I’ve been trying this command:
mysql -u root -p firedb < C:\database_2013-11-12.sql
I tried a lot of things I could find here on stackoverflow with no success yet:
[mysqld]
innodb_file_per_table
max_allowed_packet=2048M
wait_timeout=3600
net_read_timeout=3600
net_buffer_length=3600
The SQL file was created on “MySQL 5.1.72-2-log (Debian)” using this command:
mysqldump -u root -p --all-databases
I have also tried setting --max_allowed_packet when running the command like this:
mysql --max_allowed_packet=2048M -u root -p --all-databases
The Documentation states:
The most common reason for the MySQL server has gone away error is
that the server timed out and closed the connection.
By default, the server closes the connection after eight hours if
nothing has happened. You can change the time limit by setting the
wait_timeout variable when you start mysqld. See Section 5.1.4,
“Server System Variables”.
If you have a script, you just have to issue the query again for the
client to do an automatic reconnection. This assumes that you have
automatic reconnection in the client enabled (which is the default for
the mysql command-line client).
So i would start with increasing the timeout.
And if this does not help read int he attached documentation link for the rest of reasons for server has gone away error.

How to import MYSQL Dump into Amazon RDS

I just logged into my EC2 via Putty on Windows and I got into my RDS instance and into one database I had created. Then I try to import a SQL dump from my machine with the following code which results into an error.
mysql> source C:\Users\guru\Downloads\latest.sql;
ERROR:
Unknown command '\U'.
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'source C:\Users' at line 1
ERROR:
Unknown command '\D'.
ERROR:
Unknown command '\l'.
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'uru\Downloads\latest.sql' at line 1
The file exists in my Windows machine. Please help me resolve the error.
As datasage mentioned, you would probably be better off working from your EC2 -> RDS instances. If you really want to work from your local machine, though:
Install MySQL for Windows: http://dev.mysql.com/downloads/mysql/
Add the parent directory of mysql.exe (the mysql command line tool) to your path environment variable.
Try the following in the command prompt. You could use powershell also, but you would need to wrap this statement in cmd /c "mysql etc..." because powershell handles redirection a little differently.
mysql -u myUser --password=myPass -h rdsEndpoint myDB < C:\Users\guru\Downloads\latest.sql
This procedure would also be useful to know if you have need for a Windows EC2 instance.
As an aside: extracting data from RDS to your local machine can get pricey, especially as your database grows. If you're just doing this as a backup solution, then you may want to look into Snapshots or automated backups. If you are doing this to replicate your RDS environment you could also transfer your data directly from RDS to your EC2 instances, which is free if both instances are in the same availability zone.
I found a very simple and user friendly solution: Downloaded SQLyog https://www.webyog.com and fed in my ssh details for my ec2 and my MYSQL log in details. I ended up accessing a my database using this GUI tool that has all the options for importing and exporting data as easy as on localhost/phpmyadmin

Restoring dump file after MySQL server migration from 5.1.51 to 5.5.10 throws error 1064

On a Windows 7 machine running MySQL server 5.1.51 (both 64bit), before migrating to 5.5.10, I made a backup of my entire database using MySQL Administrator. After installing 5.5.10, I tried to restore the dump file but it throws one error:
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE = MyISAM DEFAULT CHARSET latin1 COLLATE latin1_german1_ci ; SELECT co_n' at line 9"
I tried restore through several MySQL applications (Workbench, SQLYog) and the command line, but all throw the same error. It also throws several warnings that are however not displayed.
Two questions:
Of course, can you help me resolve this issue? Do I have to edit the sql dump file in some way? That's cumbersome though, since it's over 3GB. I thought I had followed all the steps with respect to upgrading mentioned in the MySQL documentation, so now I am a bit frustrated and scared of data loss.
When restoring from the command line, how can I make mysql.exe log all warnings and errors to a text file?
OBSERVATION #1
MySQL provides upgrade scripts when migrating data from a previous major release. I usually do not use them. Here is what I do whenever I migrate from one major release to another:
mysqldump all databases except the mysql schema. The mysql schema from major release to major release is different.
Start with a fresh install of MySQL 5.5.10
Load all databases from the mysqldumps (except mysql) in MySQL 5.5.10
Now what about the mysql schema? You can dump it in a very special way.
This is what I do for Linux to dump the mysql schema from MySQL 5.1.51:
mysql -h... -u... -p... --skip-column-names -A -e"SELECT CONCAT('SHOW GRANTS FOR ''',user,'''#''',host,''';') FROM mysql.user WHERE user<>''" | mysql -h... -u... -p... --skip-column-names -A | sed 's/$/;/g' > MySQLGrants51.sql
This will produce all the SQL GRANT commands to recreate the users and permissions.
Since you are using Windows, you can do this:
mysql -h... -u... -p... --skip-column-names -A -e"SELECT CONCAT('SHOW GRANTS FOR ''',user,'''#''',host,''';') FROM mysql.user WHERE user<>''" | mysql -h... -u... -p... --skip-column-names -A > C:\MySQLGrants51.sql
You would have to edit C:\MySQLGrants51.sql in notepad so that every line the file ends with a semicolon(;)
Now go into MySQL 5.5.10's client and run
source C:\MySQLGrants51.sql
OBSERVATION #2
"ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE = MyISAM DEFAULT CHARSET latin1 COLLATE latin1_german1_ci ;
This error message has 'TYPE = MyISAM'. Shouldn't that read 'ENGINE = MyISAM' ?
What you need to do, is repeat the dump, using the "mysqldump" tool. This is the only tool which is capable of making non-useless dumps. Other (particularly GUI) tools TRY, but they fail, because they aren't sufficiently well-tested, particularly in this kind of scenario.
Bin your dump, and make a new one using mysqldump. Use the version of mysqldump from 5.5, for preference.