I prefer using MySQL workbench. It's much more easier & user friendly than the command line way.
It provides a simple GUI.
MySQL workbench or SQL Yog.
These are the steps that I did:
- Install MySQL Workbench.
- In AWS console, there must be a security group for your RDS instance. Add an inbound rule to that group for allowing connections from your machine. It's simple. Add your IP-address.
- Open MySQL workbench, Add a new connection.
- Give the connection a name you prefer.
- Choose connection method- Standard TCP/IP
- Enter your RDS endpoint in the field of Hostname.
- Port:3306
- Username: master username (the one which which you created during the creation of your RDS instance)
- Password: master password
- Click Test Connection to check your connection.
- If connection is successful, click OK.
- Open the connection.
- you will see your database there.
- Now you can export your mysqldump file to this database. Go to-> Server. Click Data Import.
- You can check whether the data has been migrated by simply opening a blank SQL file & typing in basic SQL commands like use database,
select * from table;
That's it. Viola.
My company has TDE encryption enabled for some of our databases. The
password that the master key was encrypted by for one of our servers
is lost. We do have the backup .key file, however, the password it was
encrypted with is lost too.
We also have the certificate backed up, but those passwords are lost
as well.
So you know the backup cert/DMK files are now useless. I would IMMEDIATELY take new backups and save the passwords. This way you can restore older backup files should anything happen. I would also backup the SMK as that's the only means you have to decrypting the DMK/Cert at this moment.
The original backup files (master key, cert) are still in existence
and those encryption passwords are available for previous servers
these DBs lived on.
I'm assuming the keys haven't been rotated per your comment. If this is the case you are most likely able to restore these to a test server and restore your TDE enabled databases to said test server without issue. If this is the case, you could re-use these keys assuming nothing else is relying on the DMK/Cert in your current instance.
Since TDE works through the SMK (and not by passwords) you're currently "at risk". Sure, it's running but who knows when or if something will happen. I stated before, take new backups.
The most straight forward approach would be to remove TDE from the databases on that instance, remove the cert, and remove the DMK (After backing them up first). Then proceed to create the DMK/Cert/TDE enabled. It's going to be disk and cpu intensive for a bit (depending on the size of database and hardware/disk/etc). Backup the new DMK/Cert with a guarded password.
Best Answer
The encryption is done at the file/disk level. From this page, emphasis mine:
Also to highlight exactly what is encrypted, we have this quote:
To answer your question about confirming that the RDS is encrypted, because you do not have access to the OS that RDS runs on the only method you have is to verify the backups/snapshots are encrypted.
To download a snapshot, you can use the console (or the rds-copy-db-snapshot tool).
The keys used to encrypt/decrypt them should be found in the KMS section of the console.