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.
Related
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.
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.
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.
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.
I have a test database on a separate remote server than my production DB. Every once in awhile, I want to try and test things by uploading a copy of my production DB to my testing DB. Unfortunately, the backup file is now half a gig and I'm having trouble transferring it via FTP or SSH. Is there an easy way that I can use the mysql restore command between servers? Also, is there another way to move over large files that I'm not considering? Half a gig doesn't seem that big, I would imagine that people run into this issue frequently.
Thanks!
Are the servers accessible to each other?
If so, you can just pipe the data from one db to another without using a file.
ex: mysqldump [options] | mysql -h test -u username -ppasswd
0.Please consider whether you really need production data (especially if it contains some sensitive information)
1.The simplest solution is to compress the backup on the source server (usually gzip), transfer it across the wire, then decompress on the target server.
http://www.techiecorner.com/44/how-to-backup-mysql-database-in-command-line-with-compression/
2.If you don't need the exact replica of production data (e.g. you don't need some application logs, errors, some other technical stuff) you can consider creating a backup and restore on a source server to a different DB name, delete all unnecessary data and THEN take a backup that you will use.
3.Restore full backup once on your reference server in your Dev environment and then copy transaction logs only (to replay them on the reference server). Depending on the usage pattern transaction logs may take a lot less space as the whole database.
Mysql allows you to connect to a remote database server to run sql commands. Using this feature, we can pipe the output from mysqldump and ask mysql to connect to the remote database server to populate the new database.
mysqldump -u root -p rootpass SalesDb | mysql --host=185.32.31.96 -C SalesDb
Use an efficient transfer method, rather than ftp.
If you have a dump file created by mysqldump, on the test db server, and you update it every so often. I think you could save time (if not disk space) by using rsync to transfer it. Rsync will use ssh and compress data for the transfer, but I think both the local and remote files should/could be uncompressed.
Rsync will only transfer the changed portion of a file.
It may take some time to decide what, precisely, has changed in a dump file, but the transfer should be quick.
I must admit though, I've never done it with a half-gigabyte dump file.