The best answer is that you should have a backup of your database. With that, you should restore your database on another disk volume. Use the binary logs to do point-in-time recovery.
If you don't have a backup, you might be able to make one, or at least a backup of most of the data.
Restart the MySQL Service with innodb_force_recovery=6 (see https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html)
Try to do a read-only dump of all data. Try to save it to another disk, not the one with your bad sectors.
mysqldump --single-transaction mydatabase | gzip -c > /tmp/dump.sql.gz
Hope that the pages for your tables don't hit the bad sectors. If they do, then try to dump individual tables. Once you reach the table(s) that hit the bad sectors, you can dump partial tables using mysqldump --where ... (see documentation for mysqldump).
Once you get the database recovered, replace the bad disks in your server. Don't try to reuse disks that have gone bad. It's not worth the risk. Just recycle them.
Good luck.
Re your comment:
I've dealt with this situation once. It's a long shot, but it worked for me once.
What I did was copy leave the mysqld shut down, and try to copy the ibdata1 file using the shell:
dd bs=16k if=ibdata1 of=ibdata1.part1
STOP. If you don't know what the dd command does, go read up on it. http://man7.org/linux/man-pages/man1/dd.1.html
InnoDB pages are 16k by default, so that's the block size to use. This command will reach the pages that are stored on bad sectors, and you'll get I/O errors. Then you try to skip past the bad parts and continue.
dd bs=16k if=ibdata1 of=ibdata1.part3 skip=327
If that hits another bad page, skip another page.
dd bs=16k if=ibdata1 of=ibdata1.part3 skip=328
Keep incrementing the skip count until you stop getting I/O errors. This will mean you got past the bad pages. Calculate how many pages you had to skip. Notice I numbered this "part3" because you'll need to fill in the gap with a part2 of dead data.
Eventually you'll have two files, ibdata1.part1 and ibdata.part2. On the occasion I used this technique, I only needed two parts, because all the bad blocks were localized into one consecutive sequence of three database pages. If you have multiple bad spots, you might need multiple "parts" to this file. Keep track of the number of bad pages between each part.
Then you need to fill in the gap(s) before reconstructing a new file.
dd bs=16k if=/dev/null of=ibdata1.part2 count=4
The count of 3 obviously depends on your results from skipping bad pages. The count of pages might not correspond to the number of bad blocks you found with badblocks, multiple bad blocks might occur within the same InnoDB page.
Once you're all done with this, assemble them:
mv ibdata1 ibdata1.bad
cat ibdata1.part* > ibdata1
chown mysql:mysql ibdata1
Now start up MySQL Service with innodb_force_recovery=6. Try to dump the database as I described earlier.
This might work if the bad pages didn't contain crucial data. For example, if the bad pages were storing secondary indexes, which won't need to be touched during mysqldump. But this is entirely a matter of luck.
If this doesn't work, then your database is not recoverable as far as I know. Sorry to hear about your loss. You might try to engage a data recovery service like https://recovery.twindb.com/
You'll know from this experience that you need to make regular backups.
