I trying to migrate my Expression Engine site from one sever to another.
I was using MySQL version 5.1 but on my new server I’m using version 5.5.
I've just copied over the Database from the Data Directory on the old server to the new and my site wouldn't function correctly.
When I restore my Database with a MySQL Dump file from the old server, the site works.
Is there an issue with copying and pasting a MySQL database from one server to another and why is the MySQL Dump restore not effected by the same issue?
I'm trying to use this information to provide a good backup solution.
The dump and restore method works because the dump file is basically just a bunch of "CREATE TABLE" and "INSERT" Statements. The dump and restore rebuilds the database from scratch using basic SQL statements. Copy and pasting doesn't work because you are moving between different versions of the database with different data formats. If you are moving between machines with the same version of MySQL and the same configuration, then simply copying the data directory can work, assuming you do it properly. Using the dump / restore method is the most reliable way, but is often very time consuming on large (think 50 GB or even much larger) databases.
The best backup solution is to dump the SQL rather than copying files.
mysqldump utility provides a full dump of all of the data that is compatible (IIRC) all the way down to MySQL 4.0 using it's conditional statements.
I have a feeling that the reason copying data directories between 5.1 and 5.5 is because the engines may have changed the way that they store their data. I had an issue like this related to InnoDB and it was a pain in the behind. Long story short I never got the data back and unfortunately didn't have an SQL Dump (the hard drive failed!).
Anyway at the end of the day, mysqldump is the best tool to use as it creates compatible SQL statements which should work across a whole plethora of MySQL Versions, both past and future.
I haven't looked into the details, but the MySQL data files are binary files and may not be directly compatible between versions. The files produced by MySQLdump are simply a list of SQL instructions to recreate the database, so they will be more compatible between versions, though not necessarily backwards compatible, so you may have trouble going from 5.5 -> 5.1 if you ever had to.
Related
I have an error with Xampp where it will not connect to my database. I have had this error several times in the past and no solutions have helped. I find that uninstalling and reinstalling ends up being the fastest method, however, by doing so I lose my database tables. As I have no access to the default export and import functions, I was wondering how I transfer the tables across.
Last time, I copied and pasted these files into the same directory when I reinstalled Xampp and the tables transferred but the data within did not. The tables had also lost some functionality as well.
If anyone has any methods to do this I will greatly appreciate it.
The best way to backup and restore your data is to dump the database to an SQL file. You can use the provided mysqldump tool for that, which is the best tool for the job.
Copying the entire MySQL "datadir" (which is probably one level up from the screenshot you've posted) and completely replacing one of your new stopped MySQL instance will probably work, but is not reliable and is not supported. Since there are other files (such as ibdata1) that handle the overall health and functioning of the entire MySQL instance, you can't only copy over individual database directories. Furthermore, you should only do this when the original and replacement MySQL servers/daemons/services are completely stopped because otherwise there are file corruption or concurrency issues.
Since you're running the server on your own computer, you should grant yourself sufficient access to be able to use mysqldump and use that regularly as a backup, since file-level backups of the data directory are not reliable.
I have a Mysql database backup dump file (.sql), and I want to migrate this file directly into Oracle by using sqldeveloper. Will this work?
It won't work. If you do it manually from a dump, you would have to do a lot of data conversion, modify the create table code to work for oracle and so on. It would be a lot of work.
But if you have SQL Developer, it apparently has a process to do precisely that.
Check out that link:
http://www.oracle.com/technetwork/database/migration/mysql-093223.html
I hope that helps.
It cannot be realized in automatic mode, due to different basic syntax of Oracle and MySQL dump files. In addition, Orqcle uses its own RMAN utility for controlling backups and restoration.
A most viable solution is to write a script converting MySQL dump file into the format recognizable by Oracle. I guess these procedures can exist in Internet, available for (free?) downloading.
I need to migrate data from SQL Server 2000 to MySQL. Currently I am using MySQL workbench. Can any one tell how to do this?
If you are searching for a tool MySQL has a tool called "MySQL Migration Toolkit" that can be used to migrate the data from SQL to mysql. But the first thing as mentioned above is to do a backup. The next thing to check would be whether there are any datatypes that cannot be converted?
Exactly, what have you tried? You can quickly migrate data from MSSQL to MySQL if they are in any of the following data file formats:
Paradox (.db)
DBase (.dbf)
Delimited Text (.txt)
Excel (.xls)
XML (.xml)
MS Access Database (.mdb)
ODBC
If its a one-to-one, exact same database architecture on both the new and the old servers, you might want to try using database tools meant to make this an easier process for GUI based administrators. Just go to download.com and find some software that may assist you in that migration, Navicat is a good one. The most important thing is to always BACK IT UP! BACK IT UP! BACK IT UP! Never do anything without mirroring drives and doing whatever it takes to make sure if you don't destroy any data, but if you do you'll have backup copies of it. Also how fast your machines are will be a sizable factor when it comes to migrating very large databases.
All in all you have many options to choose from, yet the most important thing is to back it up! Can't stress that enough, yeah it might seem like meaningless extra work especially on humongous database systems, but trust me, its better to be safe than sorry. Also, I always like rebooting machines prior to making database changes to them, cutting off any connection to the outside world or any processes depending or updating its data. Turning off the ODBC will do much of that for you on Windows as well, but as always better safe than sorry. Many a corruption can be avoided by simply booting the machine and having all data in memory finalized on the active database, before backing it up or appending to it.
Check out etlalchemy. It is a free, open-sourced Python tool capable of migrating between any of the following SQL databases: PostgreSQL, MySQL, Oracle, SQL Server, and SQLite.
To install: pip install etlalchemy
To run:
from etlalchemy import ETLAlchemySource, ETLAlchemyTarget
# Migrate from SQL Server onto MySQL
src = ETLAlchemySource("mssql+pyodbc://user:passwd#DSN_NAME")
tgt = ETLAlchemyTarget("mysql://user:passwd#hostname/dbname",
drop_database=True)
tgt.addSource(src)
tgt.migrate()
I backed up my db with mysqldump from phpMyAdmin. Using MySQL 5.0.22. Made no changes to database file. Import fails. Found many instances of extra spaces using notepad, but now cannot find any other such extraneous spaces. Error is 1064.
Any suggestions on how to import file properly?
Thanks.
I encountered problems with mysql dumps of entire databases including views. So now I dump the tables and data as a separate dump, and export the views, stored routines and functions separately. I restore the tables first then the views etc.
Having come from MS SQL Server and Oracle I would like to know if there are any totally reliable tools out there for MySQL database backups and restores.
You have done several things wrong here
Using PHPMyAdmin for anything critical, especially backups. It is not production-ready, in my experience. Feel free to use it for unimportant read-only work on noncritical servers however.
Editing mysqldump files with notepad (or any other editor). Despite appearances, mysql dump files are not text files and should not be edited with any editor. They contain binary data which is not valid in most character encodings, and therefore can probably not be loaded/saved without introducing errors.
Make a fresh dump using mysqldump, which is the only reliable way of making them, and import that. Do not edit mysql dump files using notepad or any other text tool (this includes the likes of grep, sed etc).
If you need to edit a mysql dump file, then restore it into another (i.e. non-production) database instance, make the necessary changes using SQL commands and re-dump the database. This may be slow but it's reliable.
I needed to re-install my computer but I didn't think about exporting the data from mysql 5.
How do I get the data from the old installation into the new installation, is this just copying the data directory or do I have to take other steps to get to the data?
For MyISAM tables you can generally get away with copying them across. (Whilst the server's stopped, obviously.) For InnoDB, it can work, but you'll have to have the same basic block size settings. If you can use the same major version of MySQL and the same my.cnf you stand a good chance of having it work.
Afterwards it's a good idea to ensure the tables are rebuilt (eg. using ALTER TABLE), and make a note to mysqldump properly next time because none of this is supported or guaranteed to work!
I would export your data as a sql file from mysql (ie: with phpmyadmin) and then import it into the new installation. Your db should be built and filled with data pretty easily.
You said that you "didn't think about exporting the data". Does that mean you don't have access to the old installation any more?