MySQL Workbench 5.2.41 introduced the new Migration Wizard module. This module allows you to easily and quickly migrate databases from various RDBMS products to MySQL. As of Workbench 5.2.44 you can migrate databases from Microsoft SQL Server, PostgreSQL and Sybase Adaptive Server Enterprise. It also provides for generic migrations, i.e. migrations from other RDBMSes that are not explicitely supported, provided that they have a well behaved ODBC driver. More on this in an upcoming post…
Additionally, you can use the Migration Wizard to perform MySQL to MySQL database migrations, which can be used for tasks such as copying a database across servers or migrating data across different versions of MySQL.
We have already described in a previous post how to use the Migration Wizard to migrate a Microsoft SQL Server database to MySQL. In this post we are going to migrate a PostgreSQL database to MySQL using the Migration Wizard.
So lets get our hands dirty and run through the Migration Wizard in order to migrate a PostgreSQL database to MySQL. In the rest of this post I assume that you have:
- A running PostgreSQL instance in which you have proper access to the database you want to migrate. (I’ll call this database from now on the source database). I have a PostgreSQL instance running in a computer (an Ubuntu 12.04 box) in my local network. I have installed on top of it the Pagila Sample Database from pgFoundry. I’m using the standard postgres user, which has full privileges. You can use whatever PostgreSQL version you have at hand, but keep in mind that the Migration Wizard officially supports PostgreSQL 8.0 and newer so older PostgreSQL versions might not work.
- A running MySQL Server instance with proper user access. The Migration Wizard supports MySQL versions from 5.0 onwards so make sure you have a supported version. For this tutorial I’m using MySQL Server 5.5.27 CE installed in the very same Ubuntu PC where PostgreSQL is running.
- MySQL Workbench 5.2.44 or newer. This time I’m going to use Workbench for Linux. I have Workbench running in another computer with Ubuntu 12.10 installed.
Lets start now…
Download, compile (Linux and Mac only) and install a PostgreSQL ODBC driver
You need to install an ODBC driver for PostgreSQL in the machine where you installed MySQL Workbench. Please follow the instructions here.
Open MySQL Workbench and start the Migration Wizard
From the main MySQL Workbench screen you can start the Migration Wizard by clicking on the Database Migration launcher in the Workbench Central panel or through Database > Migrate in the main menu.
A new tab showing the Overview page of the Migration Wizard should appear.
Read carefully the Prerequisites section. You can read there that you need an ODBC driver for your source RDBMS installed. If you have installed the psqlODBC driver as explained in the previous section, you are good to go.
Set up the parameters to connect to your source database
Click on the Start Migration button in the Overview page to advance to the Source Selection page. In this page you need to provide the information about the RDBMS you are migrating, the ODBC driver to use and the parameters for the connection. The name of the ODBC driver is the one you set up when you registered your psqlODBC driver with the driver manager (psqlODBC, for example).
If you open the Database System combo box youll find a list of the supported RDBMSes. Select PostgreSQL from the list. Just below it theres another combo box named Stored Connection. It will list saved connection settings for that RDBMS. You can save connections by marking the checkbox at the bottom of the page and giving them a name of your preference.
The next combo box is for the selection of the Connection Method . This time we are going to select ODBC (manually entered parameters) from the list since we are going to manually type the parameters for our PostgreSQL connection. Other alternatives are ODBC data sources and ODBC connection strings.
Now its the time for putting the parameters for your connection. In the Driver text field, type the ODBC driver name from the previous step (psqlODBC). Fill the remaining parameters (Hostname, Port, Username, Password and Database) with the appropriate values. The psqlODBC driver does not allow to connect without specifying a database name, so make sure you put the name of your database before attempting to connect. At this point you should have something like this:
Click on the Test Connection button to check the connection to your PostgreSQL instance. If you put the right parameters you should see a message reporting a successful connection attempt.
Set up the parameters to connect to your target database
Click on the Next button to move to the Target Selection page. Once there set the parameters to connect to your MySQL Server instance. When you are done click on the Test Connection button and verify that you can successfully connect to it.
Select the schema(ta) to migrate
Click on the Next button to move to the next page. The Migration Wizard will communicate to your PostgreSQL instance to fetch a list of the schemata in your source database.
Verify that all tasks have successfully finished and click on the Next button to move forward. You will be given a list of schemata to select the ones to migrate. The Schema Selection page will look like this:
Select the Pagila sample database from the list and its default schema public. Now look at the options below. A PostgreSQL database is comprised of one catalog and one or more schemata. MySQL only supports one schema in each database (to be more precise, a MySQL database is a schema) so we have to tell the Migration Wizard how to handle the migration of schemata in our source database. We can either keep all of the schemata as they are (the Migration Wizard will create one database per schema), or merge them into a single MySQL database. The two last options are for specifying how the merge should be done: either remove the schema names (the Migration Wizard will handle the possible name colisions thay may appear along the way) or either adding the schema name to the database object names as a prefix. Lets select the second option since we only have one schema and we are not particularly interested in keeping its meaningless public name.
Select the objects to migrate
Move to the next page using the Next button. You should see the reverse engineering of the selected schema in progress. At this point the Migration Wizard is retrieving relevant information about the involved database objects (table names, table columns, primary and foreign keys, indices, triggers, views, etc.). You will be presented a page showing the progress as shown in the image below.
It may take some time, depending on how fast is your connection to the server, your PostgreSQL server load and your local machine load. Wait for it to finish and verify that everything went well. Then move to the next page. In the Source Objects page you will have a list with the objects that were retrieved and are available for migration. It will look like this:
As you can see the Migration Wizard discovered table objects in our source database. If you click on the Show Selection button you will be given the oportunity to select exactly which of them you want to migrate as shown here:
The items in the list to the right are the ones to be migrated. Note how you can use the filter box to easily filter the list (wildcards are allowed there too). By using the arrow buttons you can filter out the objects that you dont want to migrate. At the end, dont forget to clear the filter text box to check the full list of the selected objects. We are going to migrate all of the table objects, so make sure that all of them are in the Objects to Migrate list and that the Migrate Table Objects checkbox is checked. Most of the time youll want to migrate all objects in the schema anyway, so you can just click Next.
Review the proposed migration
Move to the next page. You will see the progress of the migration there. At this point the Migration Wizard is converting the objects you selected into their equivalent objects in MySQL and creating the MySQL code needed to create them in the target server. Let it finish and move to the next page. You might have to wait a little bit before the Manual Editing page is ready but you’ll end up with something like this:
As you can see in the image above there is a combo box named View . By using it you can change the way the migrated database objects are shown. Also take a look at the Show Code and Messages button. If you click on it you can see (and edit!) the generated MySQL code that corresponds to the selected object. Furthermore, you can double click in a row in the object tree and edit the name of the target object. Suppose you want your resultant database to have another name. No problem: double click on the Pagila row and rename it.
An interesting option in the View combo box is the Column Mappings one. It will show you all of the table columns and will let you individually review and fix the mapping of column types, defalt values and other attributes.
Run the resultant MySQL code to create the database objects
Move to the Target Creation Options page. It will look like this:
As you can see there, you are given the options of running the generated code in the target RDBMS (your MySQL instance from the second step) or just dumping it into a SQL script file. Leave it as shown in the image and move to the next page. The migrated PostgreSQL code will be executed in the target MySQL server. You can view its progress in the Create Schemata page:
Once the creation of the schemata and their objects finishes you can move to the Create Target Results page. It will present you a list with the created objects and whether there were errors while creating them. Review it and make sure that everything went OK. It should look like this:
You can still edit the migration code using the code box to the right and save your changes by clicking on the Apply button. Keep in mind that you would still need to recreate the objects with the modified code in order to actually perform the changes. This is done by clicking on the Recreate Objects button. You may need to edit the generated code if its execution failed. You can then manually fix the SQL code and re-execute everything. In this tutorial we are not changing anything, so leave the code as it is and move to the Data Transfer Setup page by clicking on the Next button.
Transfer the data to the MySQL database
The next steps in the Migration Wizard are for the transference of data from the source SQL Server database into your newly created MySQL database. The Data Transfer Setup page allows you to configure this process.
There are two sets of options here. The first one allows you to perform a live transference and/or to dump the data into a batch file that you can run later. The other set of options gives you a way to tune up this process.
Leave the default values for the options in this page as shown in the above image and move to the actual data transference by jumping to the next page. It will take a little while to copy the data. At this point the corresponding progress page will look familiar:
Once it finishes, move to the next page. You will be presented a report page summarizing the whole process:
And that should be it. Click on the Finish button to close the Migration Wizard.
A little verification step
Now that the Pagila database was successfully migrated, let’s see the results. Open an SQL Editor page associated with your MySQL Server instance and query the Pagila database. You can try something like SELECT * FROM pagila.actors. You should get something like this:
By now you should have a pretty good idea of the capabilities of the Migration Wizard and should be ready to use it for your own migrations. The official documentation is also there for you and you can always ask any question in the comments of this post or in the migration official forum. Live long and prosper!
Sergio de la Cruz