I'm almost certain about the answer, but the situation is so critical that I have to ask this question even though I'm %99 sure about the answer.
Someone in our office made a backup of a MySQL database and he restored it on a wrong destination database overwriting everything on that destination (The schema of both databases were the same). According to the structure of the MySQL backup files I know that the restore operation drops all the tables first and then creates them and fills them up with the backed up data. The question is does the restore module keeps the old data anywhere? Is there anyway of retrieving any of the old data? (logs?.. etc.)
Only if you have replicated slaves, or you used to, and have binary logs. Even then you'd need an old copy of the database you can restore, and to configure replication again.
Related
I am looking into migrating my MySQL DB to Azure Database for MySQL https://azure.microsoft.com/en-us/services/mysql/. It currently resides on a server hosted by another company. The DB is about 100 GB. (It worries me that Azure uses the term "relatively large" for 1GB.)
Is there a way to migrate the DB without any or little (a few hours, max) downtime? I obviously can't do a dump and load as the downtime could be days. Their documentation seems to be for syncing with a MySQL server that is already on a MS server.
Is there a way to export the data out of MS Azure if I later want to use something else, again without significant downtime?
Another approach: Use Azure Data Factory to copy the data from your MySQL source to your Azure DB. Set up a sync procedure that updates your Azure Database with new rows. Sync, take MYSQL db offline, sync once more and switch to the Azure DB.
See Microsoft online help
Don't underestimate the complexity of this migration.
With 100GB, it's a good guess that most rows in your tables don't get UPDATEd or DELETEd.
For my suggestion here to work, you will need a way to
SELECT * FROM table WHERE (the rows are new or updated since a certain date)
Some INSERT-only tables will have autoincrementing ID values. In this case you can figure out the ID cutoff value between old and new. Other tables may be UPDATEd. Unless those table have timestamps saying when they were updated, you'll have a challenge figuring it out. You need to understand your data to do that. It's OK if your WHERE (new or updated) operation takes some extra rows that are older. It's NOT OK if it misses INSERTed or UPDATEd rows.
Once you know how to do this for each large table, you can start migrating.
Mass Migration Keeping your old system online and active, you can use mysqldump to migrate your data to the new server. You can take as long as you require to do it. Read this for some suggestions. getting Lost connection to mysql when using mysqldump even with max_allowed_packet parameter
Then, you'll have a stale copy of the data on the new server. Make sure the indexes are correctly built. You may want to use OPTIMIZE TABLE on the newly loaded tables.
Update Migration You can then use your WHERE (the rows are new or updated) queries to migrate the rows that have changed since you migrated the whole table. Again, you can take as long as you want to do this, keeping your old system online. It should take much less time than your first migration, because it will handle far fewer rows.
Final Migration, offline Finally, you can take your system offline and migrate the remaining rows, the ones that changed since your last migration. And migrate your small tables in their entirety, again. Then start your new system.
Yeah but, you say, how will I know I did it right?
For best results, you should script your migration steps, and use the scripts. That way your final migration step will go quickly.
You could rehearse this process on a local server on your premises. While 100GiB is big for a database, it's not an outrageous amount of disk space on a desktop or server-room machine.
Save the very large extracted files from your mass migration step so you can re-use them when you flub your first attempts to load them. That way you'll save the repeated extraction load on your old system.
You should stand up a staging copy of your migrated database (at your new cloud provider) and test it with a staging copy of your application. You may be able to do this with a small subset of your rows. But do test your final migration step with this copy to make sure it works.
Be prepared for a fast rollback to the old system if the new one goes wrong .
AND, maybe this is an opportunity to purge out some old data before you migrate. This kind of migration is difficult enough that you could make a business case for extracting and then deleting old rows from your old server, before you start migrating.
One of our associate has deleted the database as well as the replica is there is a way to recover the database.
Not without a backup. Binary logs are only used to recover from the last backup up to a certain point in time. They can not be used to roll back some statements.
I have to synchronize two databases, one is locatet in Germany the other one in China. Since the datatransfer from our Server in Germany to the Chinese one is to slow to Transfer the whole Database, I have to transfer only the changed or updated tables of the Database. Is there any way to instantly dump a changed, updated or created tables into a .sql file That I can then Transfer to China?
I'm very new to the whole World of mysql and databases, so ive yet only tried to dump it and insert the tables manualy witch just works fine.
Is it possible to automate this command only for updated, changed or created databases in a script or just with a mysql command?
mysqldump -u [your_username] -p[your_password] [Database]TableOfTheDatabase > OnlyOneTable.sql
Thanks for your help
Doing this manually is probably the wrong way. I guess you are looking for replication of one master-server to one or multiple slaves. This will automatically apply all the transactions to the slave(s).
Just keep in mind, that the default replication will be unencrypted and therefore you should use a secure tunnel (vpn) between master and slave.
Also keep in mind, that there is some lag between master and slave state (can be minutes or even hours on big transactions).
As the title states, I accidently emptied tables in the wrong database. I did not export the database before I did this (stupid me). Is there anyway to restore the database to a previous date/version, so that I may obtain the emptied data back?
There is no way to recover deleted data if you didn't make any backups. You could try to check the logs, but I doubt you will find anything. You have to be careful when handling important data.
Sorry for you, but you should automate your mysql backup (in this case you lose at worst one day of data). I use this script to do that : https://sourceforge.net/projects/automysqlbackup/
HTH
An important table in one of my clients databases has been totally corrupted. All of our backups are woefully out of date. Is there any sort of restore point or something? Does IIS have any restore points?
EDIT: Excuse me, not corrupted, overwritten. Bytewise it's fine, values just overwritten with garbage data.
Have you tried REPAIR TABLE? If so, then you are probably out of luck. IIS doesn't backup MySQL data, nor does MySQL do it on its own. So, if your only backups are outdated, you may be up the creek.