A lesson that I am continually (re)learning is that clarity comes after time has passed. By then the opportunity to undo harm (should it ever have been available) is often long gone. Realizing this either paralyzes you with indecision (I’m often afflicted by this), causes you to be cautious or perhaps encourages throwing caution to the wind. Such are the trials of an observant mind (optimistically speaking).
Life has been busy, very busy. Busy enough that I no longer have even a prayer of being bored. I could kick my childhood self for ever even daring to dream of growing up in a hurry. 😉
Targeting a single database with these options:
mysqldump -u MY_DB_BACKUP_USER -p MY_DB_NAME --add-drop-table --add-drop-database > my_db_name_mmddyyyy.sql
will successfully backup the database, but if you were to restore the database backup file back into a database with a newer schema (additional tables for example) like so:
mysql -u my_db_access_user -p MY_DB_NAME < my_db_name_mmddyyyy.sql
you would end up with a “merged” version of the database that would have new tables from the more recent schema and restored tables from the backup:
I learned this the hard way recently when attempting to restore a database to an earlier version following a failed Redmine 3.0.2 upgrade. While this didn’t break anything (other than maybe a future upgrade attempt that doesn’t properly handle existing tables), it wasn’t what I intended.
Going forward, if I want to backup a single database and have the backup file contain the statement necessary to first drop the database before restoring it (a full restore for example), I’ll need to call the
mysqlbackup command like so:
mysqldump -u MY_DB_BACKUP_USER -p --databases MY_DB_NAME --add-drop-table --add-drop-database > my_db_name_mmddyyyy.sql
--databases statement. If you didn’t know this, I hope it helps you from making the same mistake.
Even when hope is in short supply.
Here’s hoping it is a good one.