MySQL Backup Best practice - mysql

I have a Mysql server which is running on linux box (Azure cloud). It has huge datas and many schemas, i want to take backup of each database separately. I had a shell scripts which basically runs mysqldump to take backup of each database and zip it. But the problem is it takes too much of time and also it locks the running system, I basically don't want to stop my system for backing up as i take backup every two days. Can you please suggest the best way to achieve my backup very fast and without interrupting the running system. By the way my Mysql server is not a Enterprise edition.

Related

Test a MySQL restore on same server

I've got a third-party application that uses MySQL as a backed. The next version will have support for our backup system, but before we upgrade we would like to take a backup. Catch 22! I am not a DBA, and our DBA staff isn't familiar with MySQL, so I'm pretty much on my own. Our server has lots of space and CPU cycles, so I would like to test the restore on that machine, without overwriting the production data. So my question is, should I install another instance of MySQL on the same computer in a different location, or is there a way to restore my data to an alternate database on the existing server?
If you are not familiar with MySQL. The preferable option would be to install MySQL on another machine, ideally with the same OS and test your restore there. It's free to install and any extra time taken to install MySQL (About 15 minutes with the Wizard) far outweighs the effort it would take to restore your live system if you make a mistake and break it.
If that is not an option and you really do want to restore on the same machine. Then your question has already been answered and voted for on stackoverflow. Multiple MySQL instances on a single machine
Your quite right that a backup isn't worth a tinker's curse unless you know you can restore it.
I would like think I know what I'm doing with a MySQL database, and in theory its possible to test the restore of a MySQL database, but not an entire MySQL instance on an existing machine. But personally I would be doing this very carefully and only as a an absolute last resort. There's just too much to go wrong.
MySQL will run on all sorts of operating systems, and with very little overhead (if you so configure it). Setting up a test machine is so easy, you also need a very good reason not to set up a new instance to test the backup on.

Backup MySQL on Apple time machine

not sure its a stack overflow question
I have a Mac and am hosting a Apache MySQL server on it using MAMP Pro. If I back up my data on the time machine, is MySQL database also backed up or do I have to create mysqldump and backup up as a cron job? In case of a crash do I do a normal restore in case it can be backed up on time machine.
Thanks
Make a regular dump with MySQL dump or use another specific database back-up tool. A copy of the data folder is not ok.
MySQL dump will really read the data and can be checked. It is not always true that all data is written completely to the data file and lockings give issues.
If you have a specific time of back-up just run a cron before that moment and verify whether it is safe and finished. MySQL will take care of lockings, changes, transactions etc.
Always, read always, verify your back-up with a restore test.

Automatic Replica Database of mySql database for backup?

I have mysql database in my web project. I need to create a replica of my mysql database for backup.
My web interface interacts directly with one database, i need that other backup database to get automatically updated whenever there are some changes in main or master database.
How can I automate this process of backup database ?
You will have to run a cron periodically to check for changes. If there is a change, then you can get a backup of your database.
For example:
You can run a cron every 5 minutes(depending on how often you need a backup) and check if the latest record was added in the last 5 minutes. If yes, run the mysqldump command to get the backup.
Typically you create master/slave setup. Periodically you take the slave down and make a copy of the database using rsync. Alternatively, you can leave the slave up and do a mysqldump, but that takes a lot longer to restore.

Remote backup of MySQL database

Our Java server application logs data to a SQL database, which may or may not be on the same machine. Currently we use MS SQL Server, and we're now porting to MySQL. A user configures database backup parameters on our app server, e.g. time of day to run a backup, and the app server executes SQL Server's BACKUP DATABASE command at the appropriate time, via a sproc. It does incremental backups daily and full backups weekly.
MySQL lacks an equivalent feature to tell the database from a client connection to back itself up. Options we're considering are:
Create a UDF to shell out to mysqldump (or copy database files), which can be called from our app server via a sproc. Essentially we'd be implementing a version of BACKUP DATABASE for MySQL.
Create a service to run on the MySQL box that can get the backup settings from the app server and run mysqldump (or file copy) locally.
Create a backup sproc to mimic mysqldump, e.g. SHOW CREATE TABLES and SELECT INTO OUTFILE for each table.
Setting up a cron job, Perl script, third-party app or other tricks that'd work great in a data center aren't preferred; this is a shrink-wrap package that needs to be pretty robust and hands off.
Database sizes can range from roughly 10MB to 10GB.
I'm aware of the binary logs for the incremental piece. I figure the general solution will probably apply to them as well, if we decide to use them.
This is all on Windows 2003 32-bit or 2008R2 64-bit, MySQL 5.1.
The UDF option seems the best to me. The UDF Repository (http://www.mysqludf.org/) has mysqludf_sys, which may be all we need, but I thought I'd ask for opinions since after extensive googling it doesn't seem like others have reached the same conclusion, or maybe our needs are just out of the ordinary. Our app is the only thing in MySQL, so I'm not worried about other users having access to our UDF.
Any solutions I'm overlooking? Any experience with using UDFs in such a way?
Thanks,
Eric
For this an other reasons we decided to collocate our application with the database, so this problem became moot.

Quickly copying a production database to development environment (SQL Server)

Often I need to pull the production database of some project to my local sql server to add features, test out stuff etc.
Today my procedure is to create a backup on the production server, somehow get that to my local machine - and then create a new database locally and restore the backup on top of that.
It is a pain, and takes more time than I like - and I would like to think, there must be a better way.
I have access via SQL Server Management Studio to the production database - isn't there an easier way, that requires fewer manual steps?
How do you do it?
Can't think of a quicker way using SQL Sever Management Studio. I'd recommend SQL Compare from Red Gate for synchronising the schema, SQL Data Compare can sync the data, but it's not quick for large databases over the internet.
You can use SSIS and copy objects between these environments, assuming you have a direct connection to the production server.
Another way, it's a must to make regular backups of the production databases, a simple maintenance plan can make a full backup at night, by example. If this is the case here, just request an early backup to the administrators and then mount it into your environment.
One more way, because production data disclosure can involve legal issues, you can just extract the database schema and then use testing data to make any development. This is also the fastest way to get a database.
A new option is to clone the database. Red Gate SQL Clone is one solution, and Windocks provides SQL Server containers with built-in DB cloning support. Full disclosure, I work for Windocks.
Backup and Restore is slow for my databases, so what I do is:
1. Detach production database
2. Copy files to my dev machine
3. Attach database to dev server.
but no body should work on the production database.
My backup procedure is similar - I am detaching the database and archive the files, it is faster than backing up.