MySQL Administrator Backups: "Compatibility Mode", What Exactly is this doing? - mysql

In Mysql Administrator, when doing backups, what exactly is "Compatibility Mode"?
I'm trying to bridge backups generated by webmin with the upload tool available inside mysql administrator. My data already has a couple of inconsistencies (ticks, commas, etc, I think) I just wont try to kink out (they might just reappear in the future anyways). These kinks generate errors when I try to restore out of my backups.
Now, if I generate backups from webmin, and then use MySQL administrator to restore them, they fail. But if I generate the backups using MySQL Administrator AND tick "Compatibility Mode", then head over to MySQL administrator (another instance) and restore... it works!
According to MySQL, "Compatibility Mode" is;
Compatibility mode creates backup files that are compatible with older versions of MySQL Administrator.
Webmin, on the other hand, gives me the following options for compatibility:
ANSI
MySQL 3.2.3
MySQL 4.0
PostgreSQL
Oracle
Microsoft SQL
DB2
MaxDB
Which would you say is a best fit? My data set is very large, so it would take quite some time to experiment one by one (specially whence thinking might beat brute-forcing it).
Edit: seems like it's doing ANSI, but i'm not 100% on it.

Compatibility mode - the mode that helps you create exports compabible with different versions of MYSQL or other databases.
You see, some versions of MySQL had different commands that were used in various versions. So what compatibility mode allows you to do is take a database and export the SQL to be compatible with another version of MySQL. Thus, you may want to upgrade your MySQL 3 server to 4 - this compatibility mode allows for the export your database or individual tables to create a SQL file that can import into a MySQL 4 version server (should work in 5 also).
I use webmin, also, and run MySQL 5. I use compatibility mode for MySQL 4.... I steer clear of any of the other ones, because I'm not running those other databases.
As far as the MySQL commands that were different between MySQL 3.x and 4.x, I believe there were changes in regards to how CURRENT_TIMESTAMP is translated from MySQL 3 to 4, and also MySQL 3 doesn't support charsets, according to this forum post here: http://www.phpbuilder.com/board/showthread.php?t=10330692

Related

Will mysql version change affect migration?

I want to transfer my Ruby on Rails project to another platform.
Currently my RDS is running over mySQL 5.5 which is discontinued, will it be ok to utilize mySQL 5.7 instead and will database migration be affected?
What could be consequences?
Mysql does not support direct upgrade skipping versions, so you'll have to upgrade in steps: 5.5->5.6->5.7, and then, maybe, 8 (actually, sometimes for simple databases a 5.5->5.7 jump might work, but it is not guaranteed and you may loose data).
make a backup
You need to have compatible mysql2 gem version (fresh enough)
See MySQL changes(5.6 and 5.7) and corresponding upgrade guides to:
make your app compatible (replace deprecated/removed features, adapt for new defaults etc.)
migrate data and mysql itself (if your database is big or under constant load, logical dumping+loading might not be acceptable), usually it involves upgrading to most recent patch version and then jumping to next version, sometimes running mysql migration tool
plan for a downtime (in worst case - a backup restore)
To minimize downtime - you can make use of mysql's ability to create a mixed-version cluster (add 5.6 slave to your present 5.5 master, then promote in to master, and so on)

MySQL to Oracle DB Migration

I have a task to Migrate MySQL DB to Oracle (its my requirement) i tried to Migrate using SQL developer as defined in below link.
https://www.packtpub.com/books/content/migrating-mysql-table-using-oracle-sql-developer-15
As the DB is huge, the constraints are not copied properly from MySQL to Oracle, i need to define/alter/add constraints explicitly, which is time consuming (SQL developer migrates data 300rec/min from mysql to Oracle) & the entire procedure, views, functions is need to re write.
How can i ensure that data has migrated properly or not.?
Is this is a right approach to migrate?
Should i move to any tool which helps to Migrate? If yes please suggest the tool..!!
Or it is the right thing to Move from MySQL to Oracle.
Thanks in Advance.
No specific answer, but some genaral thoughts based on my experiences with migration.
I've found that there normally isn't one tool that does the whole migration job well, and by whole job I mean:
Fast
Handles all data types, scenarios
And that is from Oracle to Oracle!!
Last project we tried Oracle Golden Gate, and found there were issues with that.
We always end up with a hybrid approach, somethings like:
Extract all DDL manually and pre-create objects - there are weaknesses in the stagndard tools that confound them when extracting DDL, e.g. we found 10g expdp did not handle some quirky PLSQL well, so we resorted to extracting this ourselves.
Some tables work well with SQL Loader, others with GG, others (rare) with a custom extract and load process. We had over 3,500 tables and identified about 100 that worked better done as SQLLoader rather than GG. When I say better I mean with data handling and speed of migration. We created different groups of processing each group having a different method.
Once we have an overall hybrid scheme that works, we tune, mainly by splitting that task into parallel processes, both the export and import side.
All my migrations have been big projects where we have shifted from one Oracle system/server to another, always with the target being a newer version of OS and Oracle.
So, I would imagine that migration between non-Oracle and Oracle will through up even more challenges, and probably not as trivial as imply clicking a few buttons in SQL*Developer.
You may find the expected content from the SQL developer documentation at the Oracle website.
There are migration information available for all Microsoft Access users, MySQL users, Microsoft SQL Server and Sybase Adaptive Server users.
You can also download the tutorial in forms of PDF (best for offline viewing and printing), ePub (best for most mobile devices) and Mobi (best for Amazon Kindle devices).
Recently, I have successfully migrated the MySQL database to Oracle database. Below are detail steps:
Operating System: Desktop Ubuntu local and Desktop Ubuntu on amazon aws
Please Note: Here I am using aws desktop ubuntu server because my mysql
database was pretty big. In my case there were 800 tables, 200 views,
procedures, triggers, and functions. The total size of the database was almost
20GB. In case of small database I would recommend to use local ubuntu server.
Tools Used: SQL Developer, VNCServer, Remote Desktop Client, JAVA 8, Third Party MySql JDBC Driver
1. Setup ec2 ubuntu desktop server : https://www.youtube.com/watch?v=ljvgwmJCUjw
2. Install SQL Developer on #1
Download the SQL Developer package from this link :
http://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/index.html
Accept the license agreement and download "Other Platforms" for ubuntu.
Install the SQL developer package as the following.
sudo apt-get install sqldeveloper-package debhelper openjdk-7-jdk
openjdk-7-jre icedtea-7-plugin
Now all that you need to do is to run the command (you might have a
different version)
make-sqldeveloper-package sqldeveloper-4.1.3.20.78-no-jre.zip
This will generate a debian package that you can use to install SQL developer.
Now install the resulting .deb package using the command (Your deb
might have a different version too)
sudo dpkg -i sqldeveloper_4.1.3.20.78+0.2.4-1_all.deb
In my case, I have used java 8.
3. Once you have done with your SQL developer installation on your newly created ec2 instance with VNCServer then all you need to do is to connect to that ec2 instance with the Remote Desktop Client by default available in your ubuntu local machine.
Use IP:1 with user/pass setup for VNCServer in #1
You can see the remote ec2 ubuntu desktop server. You have to grab the keyboard inputs from the Remote Desktop tool if you want to tab inside the remote server.
Once you get connected with the remote client, open SQL Developer from the terminal or from the explorer.
sqldeveloper
Follow the migration steps provided by Oracle corporation:
http://www.oracle.com/technetwork/database/migration/mysql-093223.html
Please Note: While following the migration steps provided by the
oracle they will ask for the destination database connection i.e. oracle
database connection. This is not the database where your MySQL
database will be migrated. Instead, this database connection will
be used for the migration process. Your database connection user
must have user and database create privileges. Once your connection
have user create privilege, then migration process automatically create
the corresponding database user in Oracle database[if you have mysql_test_db in MySQL
database, same mysql_test_db will be created in Oracle db too].
I recently used sqline's tool http://www.sqlines.com/cmd to convert a dump from mysql in the form of an .sql script to an (almost) Oracle-compatible sql script.
sqlines31113\sqlines.exe -s=mysql -t=oracle "-in=$infile"
I just had to (semi-manually) fix some things in the output and then I could run it on my oracle database.

MySQL Back Up and Restore

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.

Migration from SQL Server to MySQL

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()

Reasons for migrating from MySQL 5.0 to 5.1

I'm using a rather busy MySQL 5.0 database. What are the main reasons for me to migrate to MySQL 5.1? Does it worth the trouble?
I use VS2008/.NET 3.5
Servers run as a MySQL cluster on Windows 2008 servers.
Thank you for your answers so far. To be more specific - I'm looking for answers such as the one by Quanssnoi, listing the features most important to him, rather than links to MySQL feature lists, which I of course read. Thanks.
Top reasons for me would be partitioning and XPath support.
For me the most important new feature was row-based replication.
Here's a list of new features in MySQL 5.1: What's New in MySQL 5.1 If you're not going to take advantage of these new features, and you have a production system running on MySQL 5.0, then moving to MySQL 5.1 might not be worth the trouble.
MySQL 6.0 (which is still in Alpha stage), on the other hand, brings a slew of new features including utf16 and utf32 support, and a new storage engine called Falcon.
I've noticed that DB dumps and loading of dumps works much better in 5.1 (5.0 has issues with those backwards compatibility comments). Notice I'm not referring to schema Backup, but dumps (different things).