I am trying to add an index to my mysql database. But it fails due to the disk quota error.
And now my mysql database just use up all 1gb storage because of the failure and I am not sure how can I go back...
So, I decide to backup using mysqldump or rhc backup command and then recreate the database. But they both fail because they need extra spaces...
I am get stucked now and what should I do? Can I request temporarily increase my disk quota to backup the database? Or any suggestion? Thanks
use the rhc app tidy <appname> to clear up some space. Then you can go forward with your changes.
Related
After restarting application I get:
Starting MySQL 5.5 cartridge MySQL server failed to start:
Error writing to temporary file cat:
/var/lib/openshift/.../app-root/logs//mysql.log:
No such file or directoryWarning: Gear
... is using 100.0% of disk quotaFailed
to execute: 'control restart' for
/var/lib/openshift/.../mysql
Also I was trying to stop and start app from rhc commands. The app is not so big to realy fill all of the disk quota. Any advice how to resolve this?
App is working but https://app-name.rhcloud.com/phpmyadmin/ results in
Service Temporarily Unavailable The server is temporarily unable to
service your request due to maintenance downtime or capacity problems.
Please try again later.
You can check my answer here
This usually happen when you app take almost all the space of the quota.
Check all log and temp folder and make the empty if not necessary.
To check how much you are using use quota -s after ssh to the app directory
also for me deleting the content of the app-log folder worked like charm.
Rather than running mysqldump (e.g.) every morning, would it be fine to just rely on the daily server image backups that Rackspace Cloud Servers do? Or, is there a future headache that I'm not seeing?
The concern would be a potentially inconsistent state if any database operation occurred while the backup image was being created. Some of the database transactions may not have been flushed to disk yet, still residing in memory.
Since mysqldump can use the internal state of the database, I'd recommend using a cron job to regularly perform a mysqldump, and then backing up the output of the mysqldump with Cloud Backups.
Something like the following for the cron job:
#!/bin/sh
mysqldump -h DB_HOST -u DB_USER -p'DB_PASSWORD' \
DB_NAME > YOUR_WEB_ROOT/db_backup.sql gzip -f PATH_TO_BACKUPS/db_backup.sql
References:
http://www.rackspace.com/cloud/backup/
http://www.rackspace.com/knowledge_center/article/rackspace-cloud-backup-backing-up-databases
Indeed, the future headache would be trying to restore data that was possibly in an inconstant state when the image was taken.
The problem stems from any files that MySQL had open and writing to at the time of the image. MySQL dump performs a lock to ensure that nothing is being modified while the dump is taking place.
I would recommend using something like Holland Backup as it provides a framework for backing up MySQL.
The benefit of using something like Holland is that you have a bit more control over the process. For example, you can control when to purge out older backups that are no longer needed.
Holland also does a check to make sure you have enough free space to perform a backup.
The default provider is mysqldump, but there are options for other providers such as using XtraBackup.
Rackspace Image is not an ideal way to perform a MySQL backup, Cloud Image is like a snapshot to the entire server! You'd have to use Rackspace Cloud Backup instead, not a Cloud Image. However, Holland Backup is a good way to perform scheduled backup using Cron Jobs.
all,
I use mysqldump to backup mysql cluster data with 10 million lines data daily. Recently, our cluster is crashed after a update, then we restore the .sql file generated by mysqldump. When restoring the database, we got key duplication errors/problem, and then I use "-f" to force the restore process. And finally, the restore process completed and all tables is back. Some tables are smaller, we think that is because the duplicate lines are ignored.
But recently, we find some data is missing, it seems that some duplicated data dose not restored correctly.
May I know whether there is a nice way to avoid this in restore process or how to check whether we have duplication before mysqldump?
Couple of suggestions - take a look at the errors that are generated when not using the force option and see if you can figure out how to fix the root cause. Using the force option allows the restore to continue after the error but the failed rows will still be lost.
Is there a reason why you're using mysqldump rather than the backup command within ndb_mgm - which is an online operation? If using the native Cluster (on-line!) backup then you use the ndb_restore command to restore your data.
I use the following rsync command to backup my MySQL data to a machine within the LAN network. It works as expected.
rsync -avz /mysql/ root:PassWord#192.168.50.180:: /root/testme/
I just want to make sure that this is the correct way to use rsync.
I will also like to know if the 5 minute crontab entry for this will work.
don't use the root user of the remote machine for this. In fact, never directly connect to the root user, that's a major security risk. In this case, simply create a new user with few privileges that may only write to the backup location
Don't use a password for this connection, but instead use public-key authentication
Make sure that MySQL is not running when you do this, or you can easily get a corrupt backup.
Use mysqldump to create a dump of your database while MySQL is running. You can then safely copy that dump.
I find a better way of doing backups of MySQL is to use the replication facility.
set up you backup machine as a slave of your master. Each transaction is then automatically mirrored.
You can also shut down the slave and perform a full backup to tape from it. When you restart the slave it synchronises with the master again.
I don't really know about your rsync command, but I am not sure this is the right/best way to make backup with MySQL ; you should probably take a look at this page of the manual : 6.1. Database Backups
DB backups are not necessarily as simple as one might think, considering problems suchs as locks, delayed write, and whatever optimizations MySQL can do with its data... Especially if your tables are not using the MyISAM engine.
About the "5 minutes crontab" : you are doing this backup every five minutes ? If your data is that sensible, you should probably think about something else, like replication to another server, to always have an up-to-date copy.
The databases are prohibitively large (> 400MB), so dump > SCP > source is proving to be hours and hours work.
Is there an easier way? Can I connect to the DB directly and import from the new server?
You can simply copy the whole /data folder.
Have a look at High Performance MySQL - transferring large files
Use can use ssh to directly pipe your data over the Internet. First set up SSH keys for password-less login. Next, try something like this:
$ mysqldump -u db_user -p some_database | gzip | ssh someuser#newserver 'gzip -d | mysql -u db_user --password=db_pass some_database'
Notes:
The basic idea is that you are just dumping standard output straight into a command on the other side, which SSH is perfect for.
If you don't need encryption then you can use netcat but it's probably not worth it
The SQL text data goes over the wire compressed!
Obviously, change db_user to user user and some_database to your database. someuser is the (Linux) system user, not the MySQL user.
You will also have to use --password the long way because having mysql prompt you will be a lot of headache.
You could setup a MySQL slave replication and let MySQL copy the data, and then make the slave the new master
400M is really not a large database; transferring it to another machine will only take a few minutes over a 100Mbit network. If you do not have 100M networks between your machines, you are in a big trouble!
If they are running the exact same version of MySQL and have identical (or similar ENOUGH) my.cnf and you just want a copy of the entire data, it is safe to copy the server's entire data directory across (while both instances are stopped, obviously). You'll need to delete the data directory of the target machine first of course, but you probably don't care about that.
Backup/restore is usually slowed down by the restoration having to rebuild the table structure, rather than the file copy. By copying the data files directly, you avoid this (subject to the limitations stated above).
If you are migrating a server:
The dump files can be very large so it is better to compress it before sending or use the -C flag of scp. Our methodology of transfering files is to create a full dump, in which the incremental logs are flushed (use --master-data=2 --flush logs, please check you don't mess any slave hosts if you have them). Then we copy the dump and play it. Afterwards we flush the logs again (mysqladmin flush-logs), take the recent incremental log (which shouldn't be very large) and play only it. Keep doing it until the last incremental log is very small so that you can stop the database on the original machine, copy the last incremental log and then play it - it should take only a few minutes.
If you just want to copy data from one server to another:
mysqldump -C --host=oldhost --user=xxx --database=yyy -p | mysql -C --host=newhost --user=aaa -p
You will need to set the db users correctly and provide access to external hosts.
try importing the dump on the new server using mysql console, not an auxiliar software
I have no experience with doing this with mysql, but to me it seems the bottleneck is transferring the actual data?
4oo MB isnt that much. But if dump -> SCP is slow, i dont think connecting to the db server from the remove box would be any faster?
I'd suggest dumping, compressing, then copying over network or burning to disk and manually transfering the data.
Compressing such a dump will most likely give you quite good compression rate since, most likely , theres a lot of repeptetive data.
If you are only copying all the databases of the server, copy the entire /data directory.
If you are just copying one or more databases and adding them to an existing mysql server:
create the empty database in the new server, set up the permissions for users etc.
copy the folder for the database in /data/databasename to the new server /data/databasename
I like to use BigDump: Staggered Mysql Dump Importer after Exporting my database from the old server.
http://www.ozerov.de/bigdump/
One thing to note though, if you don't set the export options (namely the maximum length of created queries) respective to the load your new server can handle, it'll just fail and you will have to try again with different parameters. Personally, I set mine to about 25,000, but that's just me. Test it out a bit and you'll get the hang of it.