Data Recovery in Mysql
First You have to restore your backup file which was taken at time A , then
you have to read all MySQL binary logs using mysql utility mysqlbinlog.

For example, if your log files were numbered 1 to 49 before the backup and logs 50 to 52 were written after the backup,you will need to process logs 50 to 52 after restoring the backup. If your binary logs are named with a prefix of bin, the log processing command looks like this:

shell&gt; mysqlbinlog bin.000050 bin.000051 bin.000052 | mysql


All the binary log files that you want to process should be handled in a single mysqlbinlog command. There may be inter-file dependencies that will not be satisfied if you process them separately.

If a given binary log file was in the middle of being written during backup, you must extract from it only the part that was written after the backup, plus all log files written after that. Also, if you accidentally drop a table (or database, or some other act that causes data corruption), then you want to restore your backup and the incremental activity in binary logs. 

If you do not want to re-execute the dropped table, you can run everything up to the bad command by capturing the binary log file only up to that point. To handle partial-file extraction, mysqlbinlog supports options that enable you to specify the time or log position at which to begin extracting log contents: 

The --start-position option can be used to specify extraction beginning at a given log position.

After restoring a backup file, use the position numbers to process the binary log file. For example, you would use commands something like these:

mysqlbinlog --start-position=23456 binlog.000004 | mysql -uroot -p