I have an ERP that is requesting instances of e-commerce to be created.
These instances are basically clones of the master on a same server.
So I have master DB (currently a dump file) and master code gz.
Through various scripts clone is created and installed.
Everything else is fast except db import from dump.
Plus when there is a request for, say, 50 instances simultaneously, it isn't realistic to import all these databases.
The question is:
Is there any other efficient tool to import a database other then mysql db < file.sql?
Any binary formats?
The only solution I can think about is to use a script to create 100 db clones in advance one buy one, and then when 50 new db's are requested, just rename existing clones.
You can recreate the database on the fly without exporting to a file and importing back, this will eliminate parsing a .SQL dump file back to mysql:
mysqldbcopy --source=root:root#localhost \
--destination=root:root#localhost world:world_clone
https://dev.mysql.com/doc/mysql-utilities/1.5/en/utils-task-clone-db.html
Currently i have a test server 'X' which has many databases with data in it.I want to copy this data to another server ie 'Y'.Both are on the same mysql version.I read posts regarding the same.I know how to create a sql file and run it.But is there any other quick way without creating sql files for all databases.Should i use replication?is replication applicable in my scenario because there is no master/slave configratn here.
You can use below 2 approaches-
master/Slave: very less downtime hardly 1 to 10 minutes. As your slave catch the master then you can migrate your site/app to new server.
Binary Copy: You can copy all binary files from your mysql data directory and move to new server data directory. It will take time to copy and move your date from one server to another server.
Note: before binary copy you need to take a full dump backup so in case of any issue you are not loosing your data.
I have a PostgreSQL database with 4-5 tables (some of those have more than 20 million rows). i have to replicate this entire database onto another machine. However, there I have MySQL (and for some reason cannot install PostgreSQL) on that machine.
The database is static and is not updated or refreshed. No need to sync between the databases once replication is done. So basically, I am trying to backup the data.
There is a utility called pg_dump which will dump the contents onto a file. I can zip and ftp this onto the other server. However, I do not have psql on the other machine to reload this into a database. Is there a possibility that mysql might parse and decode this file into a consistent database?
Postgres is version 9.1.9 and mysql is version 5.5.32-0ubuntu0.12.04.1.
Is there any other simple way to do this without installing any services?
Depends on what you consider "simple". Since it's only a small number of tables, the way I'd do it is like this:
dump individual tables with pg_dump -t table_name --column-inserts
edit the individual files, change the schema definitions to be compatible with mysql (e.g. using auto_increment instead of serial, etc. : like this: http://www.xach.com/aolserver/mysql-to-postgresql.html only in reverse)
load the files into the mysql utility like you would any other mysql script.
If the files are too large for step #2, use the -s and -a arguments to pg_dump to dump the data and the schema separately, then edit only the schema file and load both files in mysql.
I've got a database (all MyISAM tables) and the machine where MySQL was running is no longer bootable. However, we have all the MySQL data files from the data directory. How can I restore the data from the MYD and FRM files, or whatever other files I should be looking at in the data directory?
I've been doing some searching on this and it sounds like for MyISAM I should just be able to copy the database subdirectory from the old MySQL data directory to the new MySQL data directory. However, that's not working for me. A database with the name of the database I'm trying to recover shows up in the list of databases in phpMyAdmin, but all the tables show "in use" and have no information (e.g., number of rows, number of bytes, column information, etc.). Any operation on those tables (e.g., SELECT * FROM {table}, REPAIR {table}, CHECK {table}) returns a "no such table" error.
One of the tools I ran across in my search is DBACentral by MicroOLAP. It's got component that's supposed to restore data from FRM/MYD files, but when I tried to run it, it didn't list any tables that it could recover from my FRM/MYD files.
This is on a developer workstation that's running Vista Business 32bit. MySQL version is 5.0.27. After fixing the machine, I went and got the exact same version of MySQL (v5.0.27), thinking that if I'm just going to drop in the binary data files I should do it with the same version of MySQL. It still didn't work.
Any insights would be greatly appreciated... thanks!
-Josh
Install the same version of mysql.
Remove mysql directory from data directory of the server and copy it from the crashed server. This is the key element
copy directory of database you want to recover into data directory of new server
start mysql.
switch to mysql database: USE mysql; and run REPAIR TABLE <table name> on every table.
Do the same with database you want to recover
tip: make sure the 2 directories have the same permissions like data directory
If you did not save mysql database (mysql directory in your old server's data dir, then you can try to:
create database with the same name as database you want to recover.
Then you can create each table (it would be good to use the same structure - you'd have bigger chance of recovery).
then stop mysql server and delete files from database directory and overwrite them with files from old server
start mysql and repair each table.
I wound up giving up. I think the answer is that, with my particular version of MySQL, this doesn't work. Hopefully things have improved since then.
The title is self explanatory. Is there a way of directly doing such kind of importing?
The .BAK files from SQL server are in Microsoft Tape Format (MTF) ref: http://www.fpns.net/willy/msbackup.htm
The bak file will probably contain the LDF and MDF files that SQL server uses to store the database.
You will need to use SQL server to extract these. SQL Server Express is free and will do the job.
So, install SQL Server Express edition, and open the SQL Server Powershell. There execute sqlcmd -S <COMPUTERNAME>\SQLExpress (whilst logged in as administrator)
then issue the following command.
restore filelistonly from disk='c:\temp\mydbName-2009-09-29-v10.bak';
GO
This will list the contents of the backup - what you need is the first fields that tell you the logical names - one will be the actual database and the other the log file.
RESTORE DATABASE mydbName FROM disk='c:\temp\mydbName-2009-09-29-v10.bak'
WITH
MOVE 'mydbName' TO 'c:\temp\mydbName_data.mdf',
MOVE 'mydbName_log' TO 'c:\temp\mydbName_data.ldf';
GO
At this point you have extracted the database - then install Microsoft's "Sql Web Data Administrator". together with this export tool and you will have an SQL script that contains the database.
MySql have an application to import db from microsoft sql.
Steps:
Open MySql Workbench
Click on "Database Migration" (if it do not appear you have to install it from MySql update)
Follow the Migration Task List using the simple Wizard.
I did not manage to find a way to do it directly.
Instead I imported the bak file into SQL Server 2008 Express, and then used MySQL Migration Toolkit.
Worked like a charm!
In this problem, the answer is not updated in a timely. So it's happy to say that in 2020 Migrating to MsSQL into MySQL is that much easy. An online converter like RebaseData will do your job with one click. You can just upload your .bak file which is from MsSQL and convert it into .sql format which is readable to MySQL.
Additional note: This can not only convert your .bak files but also this site is for all types of Database migrations that you want.
Although my MySQL background is limited, I don't think you have much luck doing that. However, you should be able to migrate over all of your data by restoring the db to a MSSQL server, then creating a SSIS or DTS package to send your tables and data to the MySQL server.
hope this helps
I highly doubt it. You might want to use DTS/SSIS to do this as Levi says. One think that you might want to do is start the process without actually importing the data. Just do enough to get the basic table structures together. Then you are going to want to change around the resulting table structure, because whatever structure tat will likely be created will be shaky at best.
You might also have to take this a step further and create a staging area that takes in all the data first n a string (varchar) form. Then you can create a script that does validation and conversion to get it into the "real" database, because the two databases don't always work well together, especially when dealing with dates.
The method I used included part of Richard Harrison's method:
So, install SQL Server 2008 Express
edition,
This requires the download of the Web Platform Installer "wpilauncher_n.exe"
Once you have this installed click on the database selection ( you are also required to download Frameworks and Runtimes)
After instalation go to the windows command prompt and:
use sqlcmd -S \SQLExpress (whilst
logged in as administrator)
then issue the following command.
restore filelistonly from
disk='c:\temp\mydbName-2009-09-29-v10.bak';
GO This will list the contents of the
backup - what you need is the first
fields that tell you the logical names
- one will be the actual database and the other the log file.
RESTORE DATABASE mydbName FROM
disk='c:\temp\mydbName-2009-09-29-v10.bak' WITH MOVE 'mydbName' TO
'c:\temp\mydbName_data.mdf', MOVE
'mydbName_log' TO
'c:\temp\mydbName_data.ldf'; GO
I fired up Web Platform Installer and from the what's new tab I installed SQL Server Management Studio and browsed the db to make sure the data was there...
At that point i tried the tool included with MSSQL "SQL Import and Export Wizard" but the result of the csv dump only included the column names...
So instead I just exported results of queries like "select * from users" from the SQL Server Management Studio
SQL Server databases are very Microsoft proprietary. Two options I can think of are:
Dump the database in CSV, XML or similar format that you'd then load into MySQL.
Setup ODBC connection to MySQL and then using DTS transport the data. As Charles Graham has suggested, you may need to build the tables before doing this. But that's as easy as a cut and paste from SQL Enterprise Manager windows to the corresponding MySQL window.
For those attempting Richard's solution above, here are some additional information that might help navigate common errors:
1) When running restore filelistonly you may get Operating system error 5(Access is denied). If that's the case, open SQL Server Configuration Manager and change the login for SQLEXPRESS to a user that has local write privileges.
2) #"This will list the contents of the backup - what you need is the first fields that tell you the logical names" - if your file lists more than two headers you will need to also account for what to do with those files in the RESTORE DATABASE command. If you don't indicate what to do with files beyond the database and the log, the system will apparently try to use the attributes listed in the .bak file. Restoring a file from someone else's environment will produce a 'The path has invalid attributes. It needs to be a directory' (as the path in question doesn't exist on your machine).
Simply providing a MOVE statement resolves this problem.
In my case there was a third FTData type file. The MOVE command I added:
MOVE 'mydbName_log' TO 'c:\temp\mydbName_data.ldf',
MOVE 'sysft_...' TO 'c:\temp\other';
in my case I actually had to make a new directory for the third file. Initially I tried to send it to the same folder as the .mdf file but that produced a 'failed to initialize correctly' error on the third FTData file when I executed the restore.
The .bak file from SQL Server is specific to that database dialect, and not compatible with MySQL.
Try using etlalchemy to migrate your SQL Server database into MySQL. It is an open-sourced tool that I created to facilitate easy migrations between different RDBMS's.
Quick installation and examples are provided here on the github page, and a more detailed explanation of the project's origins can be found here.